EUDR GeoJSON Requirements
The European Union Deforestation Regulation (EUDR) requires all economic operators to submit the geolocation of plots of land in GeoJSON format to the EUDR Information System.
This page explains the supported geometry types and the most common GeoJSON file errors.
OpenAtlas validates every plot at registration to ensure your data is compatible with the EUDR Information System.
Geometry Types
| Geometry Type | Description | EUDR Usage | OpenAtlas Handling |
|---|---|---|---|
| Point | A single coordinate pair [lon, lat]. | Allowed for plots smaller than 4 hectares (except cattle). | ✅ Accepted. Expanded into a 4 ha buffer polygon for risk assessment. |
| Polygon | A closed shape with at least 4 coordinates (first = last). | Mandatory for plots larger than 4 hectares. | ✅ Accepted. Validated for closure and no self-intersections. |
| MultiPoint | A set of multiple points. | Supported in the EUDR spec for edge cases, though rarely used in practice. | ⚠️ Not yet supported in OpenAtlas. Planned for consideration in future updates. |
| MultiPolygon | Two or more polygons grouped together. | Supported in the EUDR spec for properties made up of multiple parcels. | ⚠️ Not yet supported in OpenAtlas. Under evaluation for future support. |
| LineString / MultiLineString | Sequences of points forming lines. | Not valid for production place declaration. | ✅ Rejected. |
Common GeoJSON File Errors
The following list is taken from the latest EUDR GeoJSON requirements published by the European Commission.
| # | Error Type | Description | OpenAtlas Handling |
|---|---|---|---|
| 1 | Coordinate lines crossing | Polygons cannot self-intersect (e.g. figure-eight shapes). | ✅ Rejected. |
| 2 | Overlapping sides | Internal overlaps or folds inside polygons are not accepted. | ✅ Rejected. |
| 3 | Doughnut shapes | Holes inside polygons (inner rings). The EUDR system does not accept them and recommends splitting into half-moon polygons. | ⚠️ Currently supported in OpenAtlas. Under evaluation for future validation. |
| 4 | Open polygons | First and last coordinates must be identical to close the shape. | ✅ Rejected. |
| 5 | Invalid geometry types | LineString and MultiLineString are not valid. | ✅ Rejected. |
| 6 | Straight lines | A polygon must enclose an area; straight lines are invalid. | ✅ Rejected. |
| 7 | Duplicate coordinates (rounding) | Points collapse into duplicates when rounded to 6 decimals. | ⚠️ Currently supported in OpenAtlas. Under evaluation for future validation. |
| 8 | File syntax errors | Missing/extra characters such as } or ). | ✅ Rejected. |
| 9 | Invalid property names | Typos or wrong case, e.g. "productionplace" instead of "ProductionPlace". | ✅ Not relevant. Rejected per API schema. |
| 10 | Invalid file format | Only .geojson is accepted. Formats like .pdf or .txt are invalid. | ✅ Not relevant. |
| 11 | Invalid coordinate range | Coordinates must be within latitude ±90 and longitude ±180. | ✅ Rejected. |
| 12 | Invalid ISO2 country code | Producer country must be a valid ISO 3166-1 alpha-2 code. | ✅ Not relevant. |
| 13 | Password protected files | Locked/encrypted files cannot be processed. | ✅ Not relevant. |
| 14 | Data representation issues | Values must be correctly typed (e.g. "Area": 3 not "Area": "3"). Points must be [lon, lat]. | ✅ Not relevant. Rejected per API schema. |
| 15 | Polygons with holes inside | Holes are ignored — only outer boundaries are processed. | ⚠️ Currently supported in OpenAtlas. Under evaluation for future validation. |
| 16 | File size > 25 Mb | Max file size per DDS submission is 25 Mb. | ✅ Not relevant. |
Summary
OpenAtlas validates geometry types and catches common GeoJSON issues before submission.
This ensures all registered plots are compliant with the EUDR Information System, reducing the risk of rejections and saving time in due diligence workflows.
Some geometry cases (such as MultiPoint, MultiPolygon, or inner rings) are treated differently in OpenAtlas compared to the EUDR system.
We are constantly improving our validation logic to better align with regulatory requirements while maintaining flexibility for user workflows.