LearnAll blog articles

EUDR

EUDR geolocation requirements: point or polygon

A practical EUDR GeoJSON checklist: the four-hectare point-versus-polygon rule, coordinate precision, file structure and what validation cannot prove.

Aerial agricultural plots showing a point marker on a small field and a polygon boundary around a larger field

The EUDR does not ask only for a farm name or a country of origin. For an operator’s due-diligence information, it requires the geolocation of every plot of land where the relevant commodity was produced. That location must be precise enough to connect the product to a particular place.

The practical question is whether each production place should be represented by a point or by its full boundary.

The short answer

  • A point can represent a plot of four hectares or less; a polygon is also acceptable.
  • Use a polygon for a plot larger than four hectares.
  • An establishment where cattle are kept may be represented by a single point regardless of area.
  • Coordinates must use latitude and longitude with at least six decimal digits.

Those requirements come from Article 2(28) and Article 9(1)(d) of the current consolidated EUDR text. The point-versus-polygon decision is about the individual plot—not the total size of the supplier’s farm, cooperative or shipment.

This is the standard due-diligence-statement route. Qualifying micro or small primary operators have a separate Article 4a simplified-declaration path, which can allow a postal address instead of plot coordinates. It is a conditional route, not a general small-business exemption; the Commission’s roles and responsibilities guide explains the eligibility conditions.

For the standard due diligence statement route, a cattle establishment may use one point regardless of area; another production plot may use a point or polygon at four hectares or less but requires a polygon when larger

What counts as a plot?

The Regulation defines a plot as land within one real-estate property, recognised by the law of the country of production, with sufficiently homogeneous conditions to evaluate the aggregate risk of deforestation and forest degradation associated with the commodity produced there.

That matters when a supplier manages several fields. One pin placed at the cooperative office does not identify the separate production plots behind the goods. Each plot involved in production needs its own usable location record.

What an EUDR GeoJSON file needs

The European Commission’s EUDR Information System lets operators provide locations on a map, individually or in bulk. For bulk upload, the Commission uses the GeoJSON standard and links its current file description from the official Information System page.

Before relying on a supplier file, check these points:

  1. The top-level object is a FeatureCollection. Each production place is represented as a feature.
  2. The geometry is one of the types accepted for your upload variant. Type II accepts Point, MultiPoint, Polygon and MultiPolygon; Type I also accepts a GeometryCollection whose nested geometries are valid (EUDR GeoJSON File Description v1.5, Type I and Type II geometry tables). A line traced around a field is not a polygon and does not describe an area.
  3. Coordinates use WGS84 decimal degrees. GeoJSON orders a position as [longitude, latitude], which is the reverse of the way people often say coordinates aloud. Longitude runs −180 to 180, latitude −90 to 90.
  4. The geometry matches the four-hectare rule. A point is not enough for a non-cattle plot larger than four hectares — and read the Area default below before you trust a point.
  5. Polygon rings are closed. Under the GeoJSON standard, RFC 7946, the final coordinate in a linear ring repeats the first. The exterior ring also has to enclose a real area: a collinear or zero-area ring is not a production plot.
  6. Country and area properties are usable. For a Type II file, every production place needs ProducerCountry as a valid ISO 3166-1 alpha-2 code; Type I validates the code when it is supplied. Where Area is present it must be a positive number of hectares.
  7. The geometry is valid — and this is where files get rejected, not merely queried. A self-crossing boundary (a “bowtie”) and an interior hole are both blocking errors, not points of style. Neither can be repaired silently: decomposing a bowtie into simple polygons changes the plot’s shape, and removing a hole changes the declared area, so both need a human decision before the file is used.

Two traps that pass a naive check

A point with no Area is not a small plot — it is a four-hectare plot

The Area property is where the four-hectare rule quietly bites. In the EUDR system, a point with no Area property defaults to 4 hectares. So an omitted value is not treated as unknown or as zero; it is treated as sitting exactly on the boundary of the rule. A supplier who leaves Area out of a point representing a twelve-hectare field has not produced an incomplete file — they have produced one that declares something untrue about the land.

The corollary is worth stating plainly: adding a correct Area to a point can turn a file that passed into one that fails, because the omission was doing the work. That is the check functioning, not breaking.

Coordinates are processed at six decimals, and geometry can collapse there

Article 2(28) requires at least six decimal digits, and the current V3 API contract (Business Rule GEO-CORD-10) truncates coordinates to six decimals when it processes them. The consequence is easy to miss: a file is judged on the geometry that survives truncation, not on the geometry as exported.

A tightly-drawn plot whose vertices differ only in the seventh decimal can therefore pass every check as written and fail once truncated — vertices collapse into each other, adjacent duplicates appear, or an exterior ring reduces to zero area. Extra precision beyond six decimals is only a warning; a geometry that collapses at six decimals is an error. Re-check the file at six decimals, not only as your GIS exported it.

Three errors worth checking first

Latitude and longitude are reversed

A supplier may send latitude, longitude, while GeoJSON requires longitude, latitude. Some swapped values remain within valid numeric ranges, so a file can look syntactically plausible while appearing in the wrong place. Always inspect the plot on a map; do not rely on range checks alone.

A boundary is stored as a line

GPS apps often export a walked boundary as a LineString. Closing the visual loop does not automatically turn it into a valid Polygon. The source should be exported as an area geometry, then checked again.

One point represents several production plots

The four-hectare rule does not make one central point a substitute for plot-level geolocation. If a batch combines goods from several production places, the due-diligence information needs the locations of all the plots involved.

What a file check can—and cannot—tell you

A GeoJSON check can establish whether the file has the supported structure, coordinates and geometry needed for the technical geolocation step. It can also repair meaning-preserving issues such as an unclosed ring without moving a vertex.

It does not prove that the goods are deforestation-free or legally produced. It does not complete the operator’s risk assessment or risk-mitigation duties, and it does not submit a due-diligence statement to the EUDR Information System. Those are separate parts of the operator’s due-diligence process.

Check the file before it reaches the portal

Clearlane’s free EUDR GeoJSON validator and repair tool runs in your browser. It checks one file at a time against Clearlane’s cited EUDR geolocation rule profile, shows the plots on a map, records supported repairs and lets you download the repaired GeoJSON. Your file does not leave your browser.

This article is educational guidance, not legal advice or a compliance verdict.