How to Check an EUDR GeoJSON Will Pass Before You Submit: A Step-by-Step Validation Workflow

Every technical rejection in the EU Information System is a rejection that could have happened at your desk three weeks earlier, quietly, for free. That is the whole argument for pre-submission validation: the system's rules are known, the failure modes are known, and checking a file against them takes minutes with tools that cost nothing. What follows is the workflow, in the order that catches the most with the least effort. Run it on every geodata delivery from every supplier, the day it arrives, and the due diligence statement stops being the place where problems are discovered.

Step 1: put it on a map and look

Before any tooling, open the file in a map viewer, geojson.io in a browser or any GIS application. One glance answers the loudest questions: are the plots in the producer country, do they look like fields rather than lines or dust, is anything sitting in the ocean? A file whose cocoa plots render in the Gulf of Guinea has swapped its coordinate order; a file that will not render at all is usually broken JSON or a projected coordinate system. If it does not display correctly in a viewer, it will not fare better in the Information System.

Step 2: check the structure

The file must be valid JSON, a FeatureCollection, with each feature carrying a geometry of type Point, Polygon or MultiPolygon and its properties. Two property details bite in practice: the producer country as a two-letter ISO code, and consistent identifiers so a corrected plot replaces its predecessor instead of duplicating it. One structural rule surprises even GIS people: the system reads outer boundaries only and ignores holes, so an enclave inside a plot must be drawn as a separate polygon, not an interior ring.

Step 3: check the coordinates themselves

Three tests, all scriptable in a few lines or done visually in a GIS. Order: longitude first in every pair. Range: longitudes between minus 180 and 180, latitudes between minus 90 and 90; six and seven digit values mean UTM or a national grid snuck in, and the file needs reprojection to WGS84, not retyping. Precision: six decimal places, roughly 11 centimetres, because truncated coordinates blur the very boundary the filing exists to prove.

Step 4: test geometry validity

This is where self-intersections and closure live. In QGIS, the built-in geometry validity check flags both without a line of code. In Python, two short checks cover it:

import json
from shapely.geometry import shape
from shapely.validation import explain_validity

with open("plots.geojson") as f:
    data = json.load(f)

for i, feat in enumerate(data["features"]):
    geom = feat["geometry"]

    # Closure: the ring must end where it began
    if geom["type"] == "Polygon":
        ring = geom["coordinates"][0]
        if ring[0] != ring[-1]:
            print(f"Feature {i}: ring not closed")

    # Validity: self-intersections and friends
    g = shape(geom)
    if not g.is_valid:
        print(f"Feature {i}: {explain_validity(g)}")

The closure test runs on the raw coordinates deliberately, because geometry libraries politely repair unclosed rings while parsing, which hides exactly the defect you are hunting. The validity test names the problem and its location, which is what your supplier needs to fix the right vertex instead of remapping the plot.

Step 5: crosscheck geometry type against area

Compute each feature's area and compare it with its geometry type: points are only acceptable at 4 hectares and below, and a polygon whose computed area wildly disagrees with the declared plot size deserves a question. One trap here: measuring area directly in latitude and longitude degrees produces nonsense. Reproject to an equal-area projection first, or let QGIS's area calculation handle the ellipsoid for you. Flag every point that should have been a polygon now, while the mapper still remembers the field.

Step 6: check features against each other

Single-feature checks miss the problems that live between plots. Duplicate geometries, the same field submitted under two farmers, and overlapping boundaries, two neighbours each claiming the shared edge plus a strip of the other's land, both undermine traceability and both are detectable with a pairwise intersection pass or a topology checker. Overlaps are best prevented at capture by walking shared boundaries once, together; when they surface later, resolve them with the farmers rather than by silently trimming someone's land in software.

Step 7: weigh the file

The Information System caps a DDS submission at 25 MB, geodata is provided per commodity, and GeoJSON is a heavyweight format. Vertex bloat from second-by-second GPS tracks is the usual offender: simplify with a tolerance of a few metres, which removes redundant points without moving any boundary a reviewer would notice, and split very large supplier sets across statements. A quick vertex count per feature also catches the two-thousand-point rectangle before it multiplies across a whole origin.

Make it a gate, not a chore

The workflow above is seven checks, and six of them automate completely. The operational version looks like this: geodata arrives from a supplier, the checks run, and one of two things happens. A clean report, and the data enters your registry as filing-ready. Or a per-plot error list, plot ID, error type, location, goes straight back upstream the same day, while fixing it is a field visit away rather than a shipment away. Exporters handling thousands of plots run this as a pipeline; a cooperative technician can run it as a morning routine. Either way, the due diligence statement is assembled only from data that has already passed, which is the entire difference between filing with confidence and filing with hope.

Frequently asked questions