GeoJSON is the format EUDR geolocation files are prepared in, useful when geometry and attributes must travel together, but valid JSON alone is not enough for EUDR evidence work. Feature identity, coordinate order, geometry validity, source-file provenance, producer and batch associations, and the real-world meaning of each boundary still need review before a plot file becomes part of a filing snapshot.
A practical preparation workflow
- 1
Parse the bounded FeatureCollection without executing embedded content.
- 2
Check geometry, coordinate ranges, stable plot identifiers, and source associations.
- 3
Retain the original and export a normalized, versioned GeoJSON result for case review.
Use a FeatureCollection with stable plot identity
A practical EUDR GeoJSON file normally uses a FeatureCollection whose features represent identifiable production locations or plots. Give each feature a stable plot_id and keep the supplier’s original identifier when one exists. Do not rely on array position as identity: features can be reordered during editing or normalization. The business record should also explain which producer, supplier, batch, shipment, or case depends on each feature.
Check longitude, latitude, and geometry structure
GeoJSON coordinates use longitude before latitude. Validate numeric ranges, supported geometry types, polygon ring closure, empty coordinates, duplicate points, and other structural limits before calculating areas or screening a plot. A coordinate within the global numeric range can still be in the wrong country, and a formally closed polygon can still self-intersect or describe the wrong parcel, so structural checks are necessary but bounded.
Preserve the original source and every correction
Store the supplied file before normalizing properties or geometry. Record its hash, source, received time, parser version, warnings, and any resulting feature identifiers. If a reviewer repairs coordinates, splits a feature, or changes an association, create a new version and explain the reason. This makes it possible to reproduce which geometry was screened or included in a Filing Pack.
Separate local validation from external screening
A browser validator can inspect bounded JSON and geometry without uploading the file. Satellite screening is a different operation: it sends a selected supported geometry to an external service and returns indicators that need interpretation. Keep the validated geometry version, screening source, dataset version, time, response, limitations, and human decision connected without treating the screening response as a compliance certificate.
What to check
- FeatureCollection structure
- Supported geometry types
- Coordinate ranges and ring closure
- Stable plot identifiers
A structurally valid file does not prove that coordinates describe the correct production land.
Questions teams ask
What is the minimum useful EUDR GeoJSON structure?
Use a valid FeatureCollection with supported geometry, coordinates in longitude-latitude order, and a stable identifier such as plot_id for every feature, then connect each feature to its source and business context.
Does valid GeoJSON prove the correct production land?
No. Structural validity cannot authenticate the boundary, confirm plot completeness, or establish that it belongs to the intended producer or shipment.
Should I overwrite a supplier’s GeoJSON after repair?
No. Retain the original and save the normalized or repaired geometry as a new version with the reason, tool version, warnings, and reviewer confirmation.
Can I validate GeoJSON without uploading it?
Yes. Filovara’s bounded public structural validator runs in the browser; an external WHISP request occurs only after a separate explicit action.