In an earlier post, we described how roughly 70–80% of farm geo-data errors are auto-fixable: decimal separators, swapped coordinates, malformed field names, non-standard XML tags. These are formatting problems. The underlying data exists. It just arrived in the wrong shape.
Point-instead-of-Polygon is not that kind of error.
It appears in supplier files constantly — sometimes for a handful of records, sometimes for an entire batch. It is easy to spot. And it is genuinely impossible to fix without going back to the field. Understanding why requires understanding what a point and a polygon actually represent, and what EUDR actually demands.
What a point is, and what it is not
A GPS point is a single coordinate pair: latitude and longitude. It marks a location. In a supplier file, it might look like this:
"type": "Point",
"coordinates": [-74.2973, 4.5709]
}
That is a valid GeoJSON feature. It will parse without errors. It will import into a database without complaint. Most supplier file validation tools will accept it. And for many legitimate purposes — marking a warehouse, a collection point, a cooperative headquarters — it is exactly the right format.
For an individual farm plot, it is not enough.
A point tells you where a farm is. It does not tell you how large it is, what shape it is, or where its boundaries are. From a single coordinate, you cannot calculate area. You cannot determine whether the land overlaps with a protected forest. You cannot run a deforestation check. The information simply does not exist in the data.
What EUDR actually requires
The EU Deforestation Regulation requires that farm geo-data submitted as part of a Due Diligence Statement includes geolocation data sufficient to demonstrate that the commodity was produced on land that was not deforested after 31 December 2020.
For farms up to 4 hectares, a single GPS point is accepted — on the assumption that the risk area can be assessed with a reasonable buffer around the coordinate.
For farms larger than 4 hectares, a polygon is required. The boundary of the plot must be defined. There is no workaround, no buffer approximation, no acceptable substitute. Without a polygon, a farm above the 4-hectare threshold cannot pass a EUDR due diligence check.
This is not a data quality problem. It is a data collection problem. The polygon was never collected — and no software can reconstruct it from a point.
Why suppliers send points instead of polygons
The short answer: collecting a polygon is significantly harder than collecting a point.
A GPS point takes seconds. Open an app, tap the screen, save. A single farmer can record their location in under a minute, with any smartphone.
A polygon requires walking the perimeter of the plot while recording a continuous GPS track, or placing boundary markers at each corner and connecting them. In hilly or forested terrain, with an entry-level GPS device, this can take twenty minutes per farm. Multiply that across hundreds of smallholder plots, and the field mobilisation requirement is substantial.
Many origin suppliers — particularly cooperatives working with large numbers of smallholder farmers — began collecting geo-data before the full EUDR requirements were clear. They collected what was practical at the time: GPS points. Now those records exist in databases across Ethiopia, Honduras, Indonesia, and Colombia, and they need to be upgraded to polygons before the compliance deadline.
Some suppliers are aware of this. Many are not. Either way, the data arrives at the importer's door with point geometries for farms that are well above the 4-hectare threshold.
Why this error cannot be auto-fixed
Some errors can be corrected because the correct answer is recoverable. A swapped latitude and longitude can be detected by checking whether the reversed values fall within the expected country bounding box. A comma used as a decimal separator can be detected by its presence in a coordinate field. The fix is deterministic.
A point-to-polygon conversion is not deterministic. There is no algorithm that can reconstruct a farm boundary from a single coordinate. Satellite imagery can help — remote sensing tools can sometimes identify field boundaries from land cover data — but this is not reliable for small plots in dense vegetation, requires significant manual review, and is not a substitute for a GPS-surveyed boundary in a EUDR submission.
Any tool that claims to "fix" this automatically is either generating an approximate buffer circle around the point — which EUDR does not accept for farms over 4 hectares — or doing nothing useful. Neither is a solution.
What TraceBean does with point geometries
When TraceBean encounters a point geometry for a farm with a recorded area above 4 hectares, it flags the record clearly, does not attempt a correction, and produces an actionable supplier message. For example: "Farm ID SAM-047 has point geometry. Area recorded as 6.2 ha. EUDR requires polygon boundary for farms above 4 ha. Please resurvey plot perimeter and resubmit."
No buffer is generated. No approximation is made. The record is passed through as-is with the flag attached, so nothing in the downstream compliance tool is based on fabricated geometry. A clear flag on a genuine data gap is more useful to an importer than a quietly generated approximation that will fail a deforestation check three weeks later.
What happens next — the importer's options
When a batch arrives with point geometries for farms above the 4-hectare threshold, there are three realistic paths forward.
- Request a re-survey from the supplier. The supplier mobilises field agents to walk the plot boundaries. This is the correct long-term solution. It is also slow — weeks or months, depending on origin and supplier capacity. For importers working on a compliance deadline, this is the path that requires the most lead time.
- Exclude the affected farms from the current shipment. If the volume of flagged farms is small and the commercial impact is manageable, some importers choose to process only the farms with valid polygon data and defer the affected farmers to a later shipment once re-survey is complete. Not ideal, but pragmatic.
- Use satellite-derived boundaries as a bridging measure. Some compliance tools and third-party services offer satellite-derived farm boundaries for specific origins. These are not GPS-surveyed, and their acceptance under EUDR is subject to interpretation. This is a conversation for the importer's compliance lead — not something to be decided in the data cleaning step.
What all three paths have in common: they require a decision by a human being with knowledge of the supplier relationship, the commercial context, and the compliance timeline. That is not something a data validation tool can or should make on the importer's behalf.
The broader point
Point-vs-Polygon is the clearest illustration of a principle that applies across EUDR data validation: the value of automated processing is not that it eliminates all problems. It is that it separates the problems that can be resolved immediately from the problems that require human action — and makes the latter as actionable as possible.
A file with 800 farms, 760 of which have valid polygon geometry and 40 of which have point geometry for plots above 4 hectares, might sound like a 5% problem. It is not.
In coffee supply chains, individual smallholder farms rarely deliver their coffee directly to an exporter. Their harvest is collected and processed together at a washing station or cooperative — pooled into a single batch before it ever reaches the importer. Once that happens, the geo-data from every contributing farm must be valid. If even one farm in the batch lacks a compliant polygon, the entire shipment is at risk of being blocked.
Those 40 flagged farms are not a manageable tail. They are a potential blocker for the full 800.
What is not manageable is discovering this inside the compliance tool, three days before a shipment needs to clear customs — when the coffee has long since been pooled and there is no way to separate it. The only moment when geo-data problems are truly fixable is before the harvest reaches the washing station.
The implications of this for how importers should think about upstream data validation — and when in the supply chain it needs to happen — are significant enough to deserve a post of their own. That is coming next.
← Back to Blog