EUDR plot validation should answer two separate questions: whether the file is technically usable and whether each geometry is connected to the intended production land and business record. Review GeoJSON or converted KML structure, CRS evidence, longitude-latitude order, topology, stable plot identifiers, and supplier or batch associations without turning a clean file into a compliance conclusion.
A practical preparation workflow
- 1
Admit the original GeoJSON, KML, CSV, or other supported source without overwriting it.
- 2
Check CRS evidence, coordinate order, geometry, plot identity, and case associations.
- 3
Confirm any fact-changing repair and export a new, traceable plot version for DDS review.
Validate the file before interpreting the land
Start with deterministic checks that can be repeated: readable structure, declared or supported CRS, coordinate ranges, geometry type, ring closure, self-intersections, duplicate features, and stable plot identifiers. A parser success message is only the first step; it does not show that the boundary belongs to the intended producer or shipment.
- Keep the submitted source file and its hash.
- Record every warning against the affected plot identifier.
- Preserve the validator and rule version used for the result.
Separate reversible cleanup from fact-changing repairs
Closing an unambiguous polygon ring or normalizing a supported file structure is different from swapping coordinate columns, moving a vertex, splitting a plot, or choosing a new CRS. Show the proposed change, its reason, and its effect before a person confirms any repair that could change the real-world claim.
Connect every plot to the DDS evidence chain
A valid geometry becomes useful for filing preparation only when the team can trace it to the relevant supplier, producer, product, batch, and source evidence. Keep unresolved or many-to-many associations visible instead of guessing which plot belongs to a shipment.
- Use one stable plot identifier across source, normalized, and exported files.
- Retain the supplier response or document that supplied the boundary.
- Rerun dependent checks when a plot or association changes.
Produce a reviewable plot-validation report
The report should identify the input version, plot-level checks, warnings, confirmed repairs, remaining limitations, and the exact normalized GeoJSON selected for later review. This gives another reviewer enough context to reproduce the technical result without presenting it as a legal or deforestation verdict.
- Name and hash of the submitted file, plus the validator and rule version.
- A result for each plot ID, with the failed check and reason where applicable.
- Before-and-after geometry for every repair that a reviewer confirmed.
- The selected GeoJSON output, unresolved warnings, and any checks still required.
What to check
- CRS evidence and longitude-latitude order
- Ring closure, self-intersection, and realistic area
- Stable plot IDs and duplicate geometry
- Supplier, product, batch, and case associations
A technically valid plot file cannot establish land ownership, production activity, deforestation status, or EUDR compliance. The responsible business must confirm the real-world boundary and supporting evidence.
Questions teams ask
What should an EUDR plot validator check?
At minimum, check readable structure, CRS evidence, longitude-latitude order, supported geometry, coordinate ranges, ring closure, self-intersections, duplicate or zero-area geometry, stable plot identifiers, and the links to supplier and batch records.
Does valid GeoJSON prove that a plot complies with EUDR?
No. Technical validation cannot authenticate the boundary, prove production activity or dates, establish deforestation status, or make a compliance decision.
When does an EUDR plot need a polygon instead of a point?
The EUDR geolocation rules require polygon coordinates for production plots larger than four hectares. Confirm the applicable product, plot area, legal rule, and source evidence before preparing the geometry.
What should be saved after repairing a plot file?
Keep the original file, the proposed and confirmed change, the reason, reviewer, tool and rule versions, validation result, normalized output, and any downstream checks or exports affected by the repair.