Every previous post in this series has dealt with errors that enter geo-data by accident — a missing decimal point, a swapped coordinate axis, a wrong coordinate system. Problems that originate in field conditions, equipment limitations, or data assembly under pressure. Nobody intended for a Guatemalan farm to appear in Bangladesh.
Duplicate polygon detection is different. It deals with a problem that is sometimes accidental and sometimes not — and that is equally problematic either way.
A duplicate polygon is a farm boundary that appears more than once in a supplier's geo-data file, attributed to different farm IDs or different farmers. Two records, one piece of land. The same coordinates submitted twice — or near-identical coordinates submitted for farms that are supposed to be in different locations.
How duplicate polygons enter the data
There are three distinct ways a duplicate polygon can appear in a supplier's geo-data file. They require different responses — which is why distinguishing between them matters.
How common More common than most importers suspect. Under deadline pressure, cooperatives onboarding hundreds of new farmers sometimes use a neighbouring farm's boundary as a placeholder.
How common Frequent in supply chains that have undergone digital transitions or where land tenure is informally shared.
How common Unknown — by design. But the EUDR's five-year audit window means that cross-batch duplicate detection will eventually surface it.
The first two causes are data quality problems. The third is a data integrity problem — and potentially a compliance fraud. A validation tool cannot always determine which cause applies. But it can flag the anomaly, which is the necessary first step regardless of the underlying cause.
What happens to a duplicate polygon in a compliance tool
This is the question that makes duplicate polygon detection more than an administrative concern.
A deforestation compliance tool — whether Osapiens, Satelligence, or any other — runs each submitted polygon against a forest cover baseline map. It calculates whether the polygon overlaps with areas classified as forest in 2020 that have since been lost. It produces a risk score for each farm record.
When two farm records share the same polygon, the tool runs the same check twice. It produces the same result twice. Both farm records receive the same deforestation risk score — because they describe the same piece of land.
If that land is deforestation-free, both records pass. The importer has submitted a DDS that covers two farmers on the basis of one farm's deforestation-free status. The second farmer's actual land has never been checked.
A duplicate polygon does not fail a deforestation check. It passes — and in doing so, it gives a compliance certificate to a farm that was never actually verified.
This is why duplicate polygon detection belongs at the validation stage, not at the deforestation check stage. By the time a compliance tool processes the file, the duplicate has already produced a misleading result. The validation step before submission is the only moment when it can be caught.
The three types of duplication — and how each is detected
Duplicate polygons are not all the same. They vary in how similar the duplicated geometries are, which determines both how easy they are to detect and what they most likely represent.
| Type | Description | Likely cause | Detection method | Complexity |
|---|---|---|---|---|
| Exact duplicate | Coordinate-for-coordinate identical polygon, different Farm ID | Copy-paste error or intentional reuse | Geometry hash comparison — fast, no spatial index needed | Low |
| Near-identical | Same boundary shape, minor coordinate variation (rounding, GPS drift) | Same plot re-surveyed twice, or minor data transformation applied | Hausdorff distance below threshold — requires spatial computation | Medium |
| Overlapping | Two polygons share a significant portion of their area | Boundary digitisation error, or one plot partially covers another | ST_Intersection area as percentage of smaller polygon — PostGIS | Medium |
| Contained | One polygon is entirely inside another | A sub-plot registered as a separate farm, or cooperative boundary submitted as individual farm | ST_Contains — straightforward spatial predicate | Low |
| Translated duplicate | Same shape, different location — shifted by a fixed offset | Coordinate error applied uniformly to all vertices, or intentional repositioning | Shape fingerprint comparison after centroid normalisation | High |
The most important type for EUDR purposes is the exact duplicate — it is the easiest to detect and the most likely to represent either a copy-paste error or intentional reuse. A geometry hash computed from the coordinate sequence produces a fixed-length fingerprint for each polygon. If two farm records produce the same hash, their polygons are identical. No spatial computation required — just a hash comparison across the batch.
What duplicate Farm IDs signal — and why they are different
A duplicate polygon can exist without a duplicate Farm ID — the same geometry attributed to two genuinely different farm identifiers. But the inverse is also important: duplicate Farm IDs without duplicate polygons are a separate anomaly that signals a different problem.
If the same Farm ID appears twice in a file with different polygons, it could mean a farm has been resurveyed and the old boundary was not removed — or that a data entry error has created a phantom second record for a real farmer. If the same Farm ID appears twice with the same polygon, it is almost certainly a processing error that will cause a compliance tool to process the same farm twice.
Both need to be caught before submission. Neither is visible without a cross-record check across the entire batch.
The cross-batch dimension
Single-batch duplicate detection is the first level of the problem. Cross-batch detection is the second — and more significant — level.
A farm polygon that passes a deforestation check in January can be resubmitted in June for a different farmer in a different batch. Within each batch, everything looks clean. Across batches, the same polygon has been used to certify two different farms in two different shipments.
This is the scenario that makes EUDR's five-year document retention requirement most relevant. Competent authorities conducting a retrospective audit can cross-reference DDS submissions over time. A polygon that appears in multiple DDSs attributed to different operators or farms is an anomaly that warrants investigation.
For an importer, this means that duplicate detection is not just a single-file problem. It is a historical data problem — and the window for catching it proactively is the period between submission and audit, which could be years.
A deforestation check answers the question: is this land free from deforestation? It does not answer the question: is this land actually associated with this farmer? Only duplicate detection can answer the second question.
What responsible validation looks like here
Duplicate polygon detection produces one of three outputs depending on what is found.
An exact duplicate — same geometry, different Farm ID — is flagged as a definitive data integrity issue. The supplier is asked to confirm which record is correct and which should be removed or replaced. No auto-correction is attempted, because the correct answer cannot be determined from the data alone.
A significant overlap — two polygons sharing more than a threshold percentage of their combined area — is flagged as a potential overlap, with the percentage of shared area reported. This may be a digitisation error or a genuine boundary dispute. Either way, it requires supplier clarification before submission.
A near-identical geometry — same shape within a small tolerance — is flagged as a suspected duplicate with a similarity score. The supplier is asked to confirm whether these represent the same physical plot or two genuinely different plots that happen to be adjacent or similarly shaped.
In all three cases, the output is the same: a precise, farm-level flag that tells the supplier exactly which records are involved, what the anomaly is, and what confirmation is needed. The importer receives visibility into the issue before it becomes a compliance problem — and before the coffee has been pooled at a washing station.
Exact duplicate, contained, and overlapping polygon detection are now live in TraceBean — running automatically on every batch, with no configuration required. A polygon that is coordinate-for-coordinate identical to another, entirely contained within another, or overlapping another by more than 20% of the smaller plot's area is flagged in the validation report, with the affected Farm IDs and the exact overlap percentage where relevant. The detection logic follows the same principle as every other TraceBean check: flag what can be identified automatically, and give the supplier a precise description of what needs to be resolved.
Cross-batch detection — catching a polygon that was already submitted and approved in an earlier shipment, possibly for a different farmer — is the next step on the roadmap. The geometry hashing that powers same-batch detection today is the same foundation cross-batch detection will use; what remains is comparing each new submission against a company's own validated history, not against any other importer's data.
If your supplier files contain repeated boundaries — across farmers in the same batch, or across batches over time — that is a data integrity gap that a deforestation check alone will not catch. It is the kind of problem that surfaces at audit — not at submission.