The EUDR GeoJSON format, explained

TRACES accepts plot geolocation as GeoJSON, but not just any GeoJSON: the Commission publishes a specific profile, and files that stray from it are rejected or, worse, accepted with silently mangled data. This guide is the working reference for that profile: structure, geometry rules, the four properties the system reads, and the errors the official documentation itself lists as most common.

The basic shape

A FeatureCollection containing one Feature per plot, each with a geometry and properties, per the standard GeoJSON specification (RFC 7946). Coordinates are WGS84 (EPSG:4326) decimal degrees in [longitude, latitude] order. No other coordinate system is accepted; files in national projections must be reprojected, not relabelled.

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {
        "ProducerName": "Kouassi Cooperative",
        "ProducerCountry": "CI",
        "ProductionPlace": "Plot Adzope A-12",
        "Area": 2.5
      },
      "geometry": { "type": "Point", "coordinates": [-3.863245, 6.107891] }
    }
  ]
}

Geometry types: what is in, what is out

• Accepted: Point, MultiPoint, Polygon, MultiPolygon.
• Rejected: LineString and MultiLineString: a GPS track is not a plot until you close it into a polygon.
• Polygons: at least four positions, ring closed (first position equals last), no self-intersections, and no holes: interior rings are not processed, so a plot with an exclusion zone must be split into two hole-free shapes.
• Points: coordinates must be a single flat pair. A nested pair ([[lon, lat]]) uploads without error and then renders no coordinates at all, one of the profile's documented silent failures.

Six decimals, enforced by truncation

The regulation demands at least six decimal digits (about 11 cm), and the system normalises every coordinate to exactly six: fewer digits are padded, more are cut. The trap hides in the truncation: two vertices that differ only in the seventh decimal collapse into duplicates after rounding, which makes the ring invalid. Pre-round your coordinates to six decimals and deduplicate consecutive vertices before upload, so you validate the file TRACES will actually see. The legal background sits in the geolocation requirements guide.

The four properties that matter

Property names are case-sensitive: producercountry is not ProducerCountry and gets ignored. Anything outside this list is also ignored, harmlessly, which is genuinely useful: keep your own plot identifiers and production dates as extra properties, and one file serves TRACES, satellite screening and your evidence trail at once. For polygons the area is computed from the geometry itself; an Area value on a polygon is ignored.

Size limits and how to fit inside them

Total geolocation payload per DDS is capped at 25 MB, which sounds enormous until a rubber consignment brings fifty thousand plots. The official overflow guidance, in order: strip redundant vertices (two points define a straight fence line, not one every five metres), declare sub-4-hectare plots as points instead of polygons, and if still over, split the consignment across multiple statements and reference them from a final one. Compact serialisation (no pretty-printing) buys another margin; whitespace counts.

The error list, condensed

• Self-intersecting or figure-eight polygons: not processed.
• Unclosed rings, collinear zero-area "polygons", duplicate consecutive vertices: file errors.
• Swapped coordinate order: rejected only when out of range; otherwise your farm quietly lands in the wrong hemisphere. The system does not cross-check coordinates against ProducerCountry; do that check yourself.
• String-typed Area, nested Point coordinates: accepted then silently wrong, the worst class.
• Wrong property casing, invalid country codes, files over 25 MB: errors on upload.

Every one of these is machine-checkable before submission, which is exactly what plotvera's validator does on upload: parse, normalise, repair what is safely repairable, and report what is not. Where the geometry itself comes from is covered in the polygon guide and the smallholder collection playbook; what happens after the file is clean is the TRACES filing walkthrough.