A self-intersecting polygon is a plot boundary that crosses itself — a bowtie — and it blocks an EUDR GeoJSON file, because a boundary that crosses itself has no unambiguous inside. The repair that clears it, splitting the shape into separate non-crossing polygons, is also the only common geometry repair that changes the land you are declaring. That is why it should never happen without you looking at it.
Most EUDR file errors have one correct fix and no judgement in them. This one is different. You are not choosing between a broken file and a working file. You are choosing between two different statements about where your commodity was produced.
The short answer
- The European Commission’s EUDR GeoJSON File Description v1.5, linked from the EUDR Information System page, requires polygons to be valid and non-self-intersecting. A crossing boundary is refused.
- Regulation (EU) 2023/1115 (EUDR) asks, in the Article 2 definition of geolocation, for polygons with “sufficient latitude and longitude points to describe the perimeter of each plot of land”. One crossing perimeter does not describe one plot.
- Splitting a bowtie into simple polygons keeps every vertex where it is and reinterprets which side is inside. The enclosed area changes.
- Because the enclosed area changes, the fix is a decision about your declaration, not a formatting tidy-up. Clearlane will not apply it without your confirmation.
- Often the better answer is not to split at all, but to fix the vertex order in the tool that produced the boundary.
Why does a crossing boundary get refused?
Because nothing downstream can work out what you meant.
Draw a rectangle, then swap the order of two adjacent corners before closing the ring. The outline you get looks like a ribbon pinched in the middle. Ask “which part of this is the field?” and there is no answer — the two lobes sit on opposite sides of the crossing point, and the shape gives no way to tell whether one, the other, or both are inside. Area cannot be computed from it. Neither can containment.
The Commission’s EUDR GeoJSON File Description v1.5 states the requirement directly: polygons must be valid and non-self-intersecting. Clearlane’s validator carries that rule as a blocking error, citing that document, with effect from 5 May 2025.
The underlying geometry rule is older and not EUDR-specific. IETF RFC 7946 §3.1.6, the GeoJSON standard the file format follows, defines a linear ring as a closed loop whose last position repeats the first, and rings that do not cross themselves. The File Description builds on that standard rather than replacing it.
Then there is what the Regulation itself asks for. Article 2 of Regulation (EU) 2023/1115 (EUDR) defines geolocation as “the geographical location of a plot of land described by means of latitude and longitude coordinates corresponding to at least one latitude and one longitude point and using at least six decimal digits; for plots of land of more than four hectares used for the production of the relevant commodities other than cattle, this shall be provided using polygons with sufficient latitude and longitude points to describe the perimeter of each plot of land”. Article 9(1)(d) is the information duty that carries it: the geolocation of all plots of land where the relevant commodities were produced, along with the date or time range of production.
Read those two together and the format rule stops looking arbitrary. You are being asked to describe a perimeter. A line that crosses itself is not a perimeter of anything.
What actually puts a bowtie in a file?
Four causes cover almost all of them. These describe how the files get written, not a legal requirement — you can confirm each one by opening a GeoJSON file in a text editor.
Two vertices recorded in the wrong order. The most common by far. Every corner is in the right place; only the sequence is wrong. The map still looks roughly like the field, which is exactly why it survives all the way to a submission queue.
A walk that doubled back. Someone traced the boundary with a handheld GPS, stepped around an obstacle at a corner, and the recorded track crossed its own path. The land is fine. The trace is not.
An editing slip. One vertex got dragged across the boundary in a mapping tool, usually by a few metres, usually invisible at the zoom level someone was working at.
Two parcels merged into one ring. A grower with two adjacent blocks, joined into a single outline instead of two features. Depending on how they were stitched, the join crosses.
There is a fifth worth knowing about, because it makes a file that was fine yesterday fail today. Coordinates are processed to six decimal places. The File Description v1.5 and the Commission’s EUDR Operator API Reference v1.0 for API V3 — rule GEO-CORD-10 — both treat what happens after that truncation as its own check: coordinates must still describe distinct points and a real polygon surface, with no collapsed vertices, no adjacent duplicates and no exterior ring reduced to zero area. A tightly-drawn plot whose vertices differ only in the seventh decimal can pass every check as written and fail once truncated. So a file is worth re-checking at six decimals, not only as exported.
If you want to see which of these is in your file before it reaches anyone official, Clearlane’s free EUDR GeoJSON validator checks the structure, coordinates and geometry in your browser — the file never leaves it — and shows you each finding on a map. It is free and takes about a minute.
Which repairs are safe, and which are your call?
This is the distinction worth internalising, because it explains why one error behaves differently from the others.
Some geometry repairs do not move a single vertex. They add back something that was implied, or restate the same shape in a different convention. Applying them cannot change what you are declaring, so a tool can reasonably do them for you.
Others reinterpret the shape. Those change the area, and the area is part of your statement.
| Repair | Does any vertex move or change meaning? | Whose decision |
|---|---|---|
| Close an open ring | No — the closing pair is added back, repeating the first position | Safe to automate |
| Fix winding direction | No — the same ring, traversed the other way | Safe to automate |
| Split a self-intersecting boundary | The outline is reinterpreted; the enclosed area changes | Yours |
| Remove a hole (interior ring) | The declared area changes | Yours |
Clearlane’s validation engine encodes exactly that split. Closing a ring and correcting winding apply automatically. Splitting a bowtie and stripping holes are the only two repairs flagged as requiring confirmation — you apply them per plot and review the result on a map before downloading anything.
Should you split it, or go back to the source?
Here is the part no validator can decide for you.
Splitting works by keeping all your coordinates and cutting the shape at the crossing point, producing two or more non-crossing polygons that use those same coordinates. Nothing is invented. But notice what that means when the cause was a vertex ordering mistake: the positions were always right, only their sequence was wrong. Splitting accepts the wrong sequence and builds a valid shape out of it. You get a file that passes and a plot that is not the one anybody walked.
That is the trap. A successful repair and a correct plot are not the same outcome.
Go back to the source when:
- The split result does not match the land on the map. Look at it. If the lobes are not where the field is, the answer is in the source data.
- The area after splitting differs from what the grower or the land record says. A meaningful gap is a signal, not a rounding artefact.
- You know the boundary was walked and the walker doubled back at a corner. The crossing is a recording artefact, and re-exporting with the vertex order corrected recovers the real outline.
- The plot is two separate blocks that were stitched into one ring. They should be two features, not one split polygon.
Accept the split when:
- You can see the result on a map and it matches the land you meant to declare.
- The resulting area is what you expect it to be.
- The source file is genuinely unavailable — the supplier is unreachable, the original export is gone — and you are prepared to stand behind the shape you are declaring.
The area point deserves one more line, because it is not cosmetic. Under the Article 2 definition in Regulation (EU) 2023/1115 (EUDR), whether a non-cattle plot needs a polygon at all turns on whether it is larger than four hectares. Size is load-bearing. A repair that changes the area you declare is a repair that touches a threshold in the Regulation, which is a strange thing to let software do quietly.
There is one more reason to keep this in human hands. Article 9(1)(d) asks for the geolocation of all plots of land where the relevant commodities were produced. That is a statement you are making about your own supply chain. Delegating the shape of it to a repair algorithm delegates part of the statement.
What a clean geometry check does not prove
Worth being blunt about, since this is where tools oversell.
Passing the self-intersection check means your polygon is a valid, non-crossing shape with a computable area. That is a format and data-quality result. It is not a finding that the Information System accepted a declaration, that the goods are deforestation-free, that the commodity was legally produced, or that the plot boundary corresponds to the land your supplier actually farms.
A file can be geometrically perfect and describe the wrong field entirely. No validator anywhere can catch that. Which is, in the end, the same reason the split needs your eyes on it.
What Clearlane does here
Clearlane prepares and validates the work behind an EUDR due diligence statement, then hands it off. It runs versioned, deterministic geometry checks that cite the rule they came from, applies meaning-preserving repairs automatically, and holds the two shape-changing repairs — splitting a bowtie, removing a hole — behind your explicit confirmation.
What it does not do: Clearlane does not submit a declaration to the EUDR Information System, does not issue an official reference number, and does not certify that goods are deforestation-free. Risk assessment, risk mitigation and the statement itself stay with you as the operator.
Start where the problem is: check your GeoJSON file against the format rules. It is free, it runs in your browser, and it will show you every crossing boundary in the file with the plot drawn on a map next to it. If you want the full list of blocking checks and what each one means, the EUDR GeoJSON validation errors guide covers all of them, and the rule page for this specific error shows the engine’s own message and citation.
This article is educational guidance. It is not legal advice, an Information System filing, or a compliance verdict.