EUDR GeoJSON Plot Checker

A Due Diligence Statement is rejected for geometry far more often than for anything legal: an unclosed polygon, a coordinate pair the wrong way round, one GPS reading copied across a group of farms. Check the file before TRACES does.

🔒 Your plot data never leaves your browser — the most sensitive file in a DDS.

Read locally, never uploaded.

The errors the Commission itself lists

The EUDR GeoJSON File Description ends with a chapter of common file errors — crossing boundary lines, doughnut shapes, open polygons, LineStrings, collinear points, coordinates that become duplicates once rounded to six decimals, quoted numbers in Area, invalid ISO2 country codes, and the 25 MB submission limit. This tool checks each of them, and names the rule it is applying.

Points stand in for small plots only

A plot of 4 hectares or less may be given as a single point; anything larger needs a boundary. A point with no Area is recorded by the system as 4 hectares — the maximum, not a measurement — so leaving it out is a statement in itself.

Declared area versus measured area

Every polygon here is measured from its own coordinates and shown next to the declared Area. When those two disagree by more than a quarter, the usual cause is a unit mix-up — square metres or acres written into a field that holds hectares — and it can move a plot across the 4-hectare line without anyone noticing.

What this tool does not do

It does not tell you whether a plot is deforested, and it does not check whether coordinates fall inside the country you declared: both need map data this tool deliberately does not carry. On very large boundaries (over 2000 vertices) the self-intersection check is skipped, and the result says so rather than implying it passed.

Every check this tool runs (24 rules)

File structure and syntax

EUDR-S01 The file is not valid JSON

A missing bracket or a trailing comma makes the whole submission unreadable. The Commission lists file syntax errors among the most common causes of rejected geolocation files, and the rejection says nothing about which line broke.

Fix: Re-export from your GIS tool rather than hand-editing, and check the position this tool reports.

EUDR GeoJSON File Description (PDF) ↗

EUDR-S02 Not a GeoJSON FeatureCollection

The EUDR Information System reads a FeatureCollection (or a single Feature). A bare geometry, an array, or a spreadsheet exported with a .json extension parses as JSON and still carries no production places.

Fix: Wrap the features in {"type":"FeatureCollection","features":[…]}.

EUDR GeoJSON File Description (PDF) ↗

EUDR-S03 Geometry type is not accepted

Only Point, MultiPoint, Polygon and MultiPolygon describe a production place. LineString and MultiLineString are named in the specification as types that will not be accepted or processed, and a GeometryCollection is not a production place either.

Fix: Convert lines to the polygon they enclose, or to the point that represents the plot.

EUDR GeoJSON File Description (PDF) ↗

EUDR-S04 Property name is misspelled or in the wrong case

Property names are case sensitive: "productionplace" is not "ProductionPlace", and "geomerty" is not "geometry". The specification lists this among the common errors precisely because the file stays valid JSON — the value is simply ignored.

Fix: Use exactly ProducerName, ProducerCountry, ProductionPlace and Area.

EUDR GeoJSON File Description (PDF) ↗

EUDR-S05 Point coordinates written as an array of arrays

A Point takes one position — [lon, lat] — not a list of positions. The specification calls this out directly: files shaped that way upload without rendering any coordinates at all.

Fix: Write "coordinates": [12.345678, -1.234567] for a Point.

EUDR GeoJSON File Description (PDF) ↗

EUDR-S06 Area is a string instead of a number

"Area": "3" is not "Area": 3. The specification states that a quoted value is not recognised as a number and the area ends up as 0 — which then makes a point stand in for a plot the system believes has no size.

Fix: Remove the quotes so the value is a JSON number.

EUDR GeoJSON File Description (PDF) ↗

EUDR-S07 The file is over the 25 MB submission limit

The system caps an individual DDS submission — including its GeoJSON — at 25 MB. Files pass that limit mostly through over-sampled boundaries: a coordinate every few metres along a straight fence line.

Fix: Simplify straight runs to two points, and use single points for plots of 4 ha or less. The specification also allows splitting into several DDS and merging them by reference.

EUDR GeoJSON File Description (PDF) ↗

Geometry

EUDR-G01 Polygon ring is not closed

Every polygon must come back to where it started: the first and last coordinate pair have to be identical. An open ring is one of the named common errors, and a GIS export that drops the closing pair looks perfectly reasonable on screen.

Fix: Repeat the first coordinate pair as the last one.

EUDR GeoJSON File Description (PDF) ↗

EUDR-G02 Polygon has fewer than four positions

A polygon consists of at least four coordinate pairs — three corners plus the repeat that closes the shape. Three or fewer cannot enclose an area once the closing pair is accounted for.

Fix: Add the missing corners, or use a Point if the plot is 4 ha or less.

EUDR GeoJSON File Description (PDF) ↗

EUDR-G03 Polygon sides cross each other

Figure-eight and bow-tie shapes are listed as not processed. They usually come from a coordinate typed in the wrong order in the middle of a boundary, which is invisible in a table of numbers and obvious on a map.

Fix: Plot the boundary and fix the point that jumps out of sequence.

EUDR GeoJSON File Description (PDF) ↗

EUDR-G04 Polygon has holes

The specification does not support doughnut shapes: only the outer boundary is taken into account, so an inner ring silently changes what area you declared.

Fix: Split the plot into separate polygons — the specification suggests two half-doughnut shapes.

EUDR GeoJSON File Description (PDF) ↗

EUDR-G05 The coordinates form a straight line, not an area

Collinear coordinates are listed among the common errors: the ring closes, the JSON is valid, and the enclosed area is zero. It is what happens when a boundary is recorded along one side of a field only.

Fix: Record the remaining corners of the plot.

EUDR GeoJSON File Description (PDF) ↗

EUDR-G06 Coordinate is outside the valid range

Longitude runs from -180 to 180 and latitude from -90 to 90. Values beyond that are usually metres from a projected coordinate system (UTM, Lambert) that were never converted to WGS 84.

Fix: Convert the data to WGS 84 / EPSG:4326 decimal degrees before exporting.

EUDR GeoJSON File Description (PDF) ↗

EUDR-G07 Longitude and latitude look swapped

GeoJSON positions are [longitude, latitude] — the opposite order to how coordinates are usually read aloud and to what most mapping apps show. When the first number is a plausible latitude and the second is beyond ±90, the pair is certainly reversed; the plot then lands in a different part of the world.

Fix: Swap the pair. If your source data is "lat, lon", swap the whole file.

EUDR GeoJSON File Description (PDF) ↗

EUDR-G08 Coordinates become duplicates once rounded to six decimals

The system rounds to six decimals, so two points that differ only in the seventh decimal collapse into one. The specification gives exactly this example — and a boundary that loses points this way can become an invalid shape.

Fix: Space the boundary points further apart than about 0.1 m, which is what the sixth decimal represents.

EUDR GeoJSON File Description (PDF) ↗

EUDR-G09 Coordinate precision is too coarse to describe a plot

Four decimals of a degree is roughly 11 metres, two decimals roughly 1.1 kilometres. A boundary recorded at that resolution encloses an area that is mostly rounding, and it will not agree with any satellite check of the same plot.

Fix: Export with six decimals, which is what the system keeps.

Source: yaktool engineering threshold, not a figure from the specification: the Commission document states the system rounds coordinates to six decimals, and we warn below five because four decimals is already ~11 m at the equator and two is ~1.1 km — a plot boundary at that resolution is not a plot boundary.

EUDR-G10 Coordinates sit at exactly 0, 0

Longitude 0, latitude 0 is a point in the Atlantic Ocean off Ghana. It is what an empty field becomes when a spreadsheet turns a blank into a zero, and it passes every range check.

Fix: Restore the real coordinates for this plot — the value is missing, not zero.

Source: yaktool engineering rule, not a named error in the Commission document: null-island coordinates are a well-known artefact of empty numeric fields.

EUDR-G11 The same coordinates are used by several plots

Identical geometry across features means one GPS reading was copied for a group of farms. The submission is accepted, the plots are not distinguishable, and the traceability the statement asserts does not exist.

Fix: Collect a reading per plot. If several plots genuinely share a boundary, declare them as one production place.

Source: yaktool engineering rule, not a named error in the Commission document: it comes from the reused-coordinate pattern reported in EUDR data collection.

Area and the 4-hectare rule

EUDR-A01 A plot larger than 4 hectares is given as a point

Points stand in for plots of 4 hectares or less; anything larger has to be a polygon. A point carrying a declared area above the threshold is the clearest possible statement that the wrong geometry was used.

Fix: Provide the boundary as a polygon for this plot.

EUDR GeoJSON File Description (PDF) ↗

EUDR-A02 A point without an Area is treated as 4 hectares

The specification states that when Area is absent for a point, the system sets it to 4 hectares. That is a default, not a measurement — and it is the largest area a point is allowed to represent.

Fix: State the real area if it is smaller, so the declaration says what you know rather than what the system assumed.

EUDR GeoJSON File Description (PDF) ↗

EUDR-A03 Declared area does not match the geometry

The area computed from the polygon differs substantially from the Area property. The usual cause is a unit mix-up — square metres or acres written into a field that holds hectares — and it changes which side of the 4-hectare line the plot falls on.

Fix: Check the unit of the Area value: the system reads hectares.

EUDR GeoJSON File Description (PDF) ↗

Properties

EUDR-P01 ProducerCountry is missing

For the commodity-level file variant the specification requires ProducerCountry on every feature. Without it the plot has coordinates but no declared country of production.

Fix: Add "ProducerCountry" with the ISO2 code of the country of production.

EUDR GeoJSON File Description (PDF) ↗

EUDR-P02 ProducerCountry is not a valid ISO2 code

An invalid ISO 3166-1 alpha-2 code is a named common error. "UK" is the classic one — the registered code for the United Kingdom is GB — and three-letter codes such as BRA are equally rejected.

Fix: Use the two-letter code from ISO 3166-1.

EUDR GeoJSON File Description (PDF) ↗

EUDR-P03 ProductionPlace is missing

The specification recommends providing ProductionPlace to name the production place. Without it, a rejected or queried plot can only be identified by its position in the file.

Fix: Add a name you would recognise in a query six months from now.

EUDR GeoJSON File Description (PDF) ↗

Rules cite the European Commission's EUDR GeoJSON File Description v1.5 (5 May 2025). The Commission's own page for it was unreachable when we last checked, so the link points at the same document published by a national authority; we re-check that quarterly.