EUDR soy geolocation — TRACES-ready, without rejections

Big fields, national grids

Soy plots often arrive as a zipped Shapefile in a projected national coordinate system. DDSpass reads the .prj, reprojects to WGS84 decimal degrees, and repairs the geometry issues — self-intersections, unclosed rings — that TRACES rejects.

Under the 25 MB limit

Detailed field boundaries can push a file over the 25 MB TRACES limit. DDSpass strips collinear points and simplifies boundaries within a 0.5% area guard to bring it under — or gives you the official split instructions if it still won't fit. Nothing is uploaded.

Machine-traced boundaries and the six-decimal limit

A field boundary that came off a guidance display, or was traced from as-applied passes, arrives with thousands of vertices and coordinates written to nine decimal places. TRACES keeps six. Positions that were distinct at nine decimals land on top of each other once rounded, and a ring with repeated positions is what produces the slivers and pinches that make a polygon self-intersecting.

DDSpass rounds to the six decimals the system will actually store, removes the duplicates that rounding creates, then repairs the geometry — so the shape you inspect on screen is the shape TRACES ends up holding, not a tidier version of it.

Straight out of the farm-management system

Boundary and prescription exports leave a farm-management system in whatever format it prefers: a zipped Shapefile, a KML or KMZ from Google Earth, a GPX track, or a sheet of field records. TRACES accepts none of them — its picker takes only .geojson and .json. DDSpass converts all of them, including a zip with one inside.

Field records in a spreadsheet are the common trap. One row per field with a centre latitude, a longitude and a declared hectarage is a point, and a soy field over 4 hectares has to be a mapped boundary (EUDR Art. 2(28)). A point with no Area is silently defaulted by the system to 4 hectares.

If your records already hold the outline, keep it in the sheet: DDSpass reads a WKT or GeoJSON boundary column and builds a real polygon per row — the only way a spreadsheet satisfies the polygon rule.

Many fields, several farms, one declaration

A soy consignment is rarely one field. Once dozens of fields across several farms sit in one file the questions turn organisational: whose land is whose, and is any hectare declared twice? DDSpass groups output by ProducerName and ProducerCountry, so you export one combined file (Type II) or one per producer (Type I).

• The same field traced in two seasons and kept as two features.
• Headlands or pivot corners that overlap the neighbouring field.
• A rented field filed under two different producer names.
• Declared hectares that no longer match the mapped boundary.
• Fields that plot outside the declared country — usually a swapped latitude and longitude, or an ISO2 code that is not valid.

Overlapping and duplicate features are flagged and can be merged in place, with the area recomputed from the merged shape rather than copied from the first field. Nothing is uploaded.

Questions

Is soy in scope for the EUDR?

Yes. Soya is one of the seven EUDR commodities; each plot needs geolocation in the Due Diligence Statement, and plots over 4 ha must be sent as mapped field boundaries.

Can I send soy field boundaries as a spreadsheet?

Yes, if the sheet carries the outline. A row with latitude, longitude and a hectare figure is only a point, and anything over 4 hectares has to be a mapped boundary. Add a WKT or GeoJSON boundary column and DDSpass builds a polygon per row, then exports the GeoJSON TRACES takes.

Why does the calculated area differ from my records?

DDSpass computes area from the geometry, so any gap with your declared figure is visible before you submit. It usually means the boundary was re-traced or simplified, or the record holds a gross farm figure rather than the mapped field. Watch the data type too: an area written as text is read by TRACES as 0 hectares.

One file per farm, or one combined file?

Both are supported. Type II gives one combined file for the whole declaration; Type I splits it by ProducerName and ProducerCountry. Per-producer files are easier when one grower has to resend corrected boundaries, and they are the fallback if a combined export cannot be brought under 25 MB.