Your Farm Is in Ethiopia. Your Coordinates Say Otherwise.

Every GPS coordinate is meaningless without a reference system. The numbers 9.145 and 38.720 could be a coffee farm in the highlands outside Addis Ababa — or they could be a location in the middle of the ocean, depending on which coordinate system was used to record them.

EUDR requires one specific coordinate system: WGS84, also known as EPSG:4326. It is the global standard used by every modern GPS device, by Google Maps, and by the EUDR Information System. It is also not the system that a significant portion of farm geo-data actually arrives in.

Coordinate system errors are among the most insidious problems in EUDR geo-data — not because they are common, but because they are completely invisible in the file itself. A coordinate pair looks identical whether it was recorded in WGS84 or in a local projection. The numbers are there. The file parses without errors. The compliance tool imports it without complaint. And the farm lands somewhere it has never been.

The same coordinate values mean different locations in different coordinate systems. Without reprojection, a farm recorded in a local system appears hundreds of metres — or kilometres — from its actual position.

What a coordinate system actually is

A coordinate system is a mathematical framework for describing locations on the Earth's surface. Because the Earth is not a perfect sphere, different regions of the world have historically used different mathematical models — different ellipsoids, different datum points, different projection methods — to produce accurate local maps.

WGS84 uses a single global ellipsoid that is accurate everywhere but optimal nowhere in particular. Local coordinate systems sacrifice global consistency for local precision. A UTM zone optimised for Ethiopia will place Ethiopian farms more accurately than WGS84 — but the coordinates it produces are meaningless if read as if they were WGS84.

This is the core of the problem. A GPS device set to record in Adindan UTM Zone 37N — the coordinate system historically used for Ethiopian topographic mapping — produces coordinates that look like ordinary decimal numbers. Submitted as WGS84 to a compliance tool, those coordinates place the farm somewhere that is not Ethiopia, not the correct country, and not within any reasonable distance of the actual plot.

Where the error enters

Coordinate system problems typically originate at one of three points in the data collection chain.

At the GPS device. Older GPS receivers — particularly devices used in government land surveys, agricultural cooperatives, and development projects in Africa and Latin America — default to local coordinate systems rather than WGS84. A field agent who does not know to change the device settings will record perfectly accurate local coordinates that cannot be used in EUDR without reprojection.

At the GIS export step. A cooperative that manages farm boundaries in QGIS or ArcGIS may have their data stored in a local projection for historical reasons. When they export to CSV or GeoJSON for EUDR submission, they may not apply a reprojection step — and the exported file contains local coordinates with no indication that they are not WGS84.

At the file assembly step. A supplier aggregating data from multiple sources may combine records from different coordinate systems without realising it. The resulting file contains a mix of WGS84 and non-WGS84 coordinates — indistinguishable without checking each record against the expected country boundary.

The systems that appear most frequently

Different origin countries have different legacy coordinate systems. For green coffee and cocoa importers, the following are the most relevant.

The last entry in the table deserves special attention. UTM coordinates are expressed in metres from a zone origin — values like E=500000, N=1150000. These look nothing like WGS84 decimal degree coordinates (which are typically in the range of -180 to 180 for longitude and -90 to 90 for latitude). A compliance tool that receives UTM coordinates without reprojection will either reject them outright or place them at an entirely nonsensical location.

Why Adindan matters for Ethiopian coffee

Ethiopia is one of the most important origins for specialty green coffee — and one of the origins where coordinate system issues are most likely to appear. Ethiopian land surveying has historically used the Adindan datum, based on the Clarke 1880 ellipsoid, with UTM projections across four zones covering the country.

The transformation from Adindan to WGS84 requires specific shift parameters — for Zone 37N, which covers the central coffee-growing regions including Yirgacheffe and Sidama, the transformation parameters are approximately -166 metres east, -15 metres north, and +204 metres elevation. These are not trivial offsets. Applied incorrectly — or not applied at all — they produce farm locations that are hundreds of metres from the actual plot boundary.

For a coffee farm in a forested highland region, a 200-metre coordinate error is not an administrative inconvenience. It is the difference between a farm polygon that sits cleanly in open agricultural land and one that overlaps with a fragment of natural forest — triggering a deforestation flag that requires months of additional documentation to resolve.

The three coordinate errors that are actually fixable

Not all coordinate system problems are equal. Some can be corrected automatically. Others require human intervention.

CRS reprojection is fully automatic when the coordinate system is declared in the file. A GeoJSON with a "crs" property, or a CSV with a projection file, provides enough information to apply the correct transformation. The reprojected coordinates can be verified against the expected country boundary to confirm the result is plausible.

UTM coordinates without declared CRS are detectable by their magnitude — values in the hundreds of thousands are outside the WGS84 coordinate range and can be flagged automatically, even if the correct UTM zone cannot always be determined without additional context.

Lat/lon axis swap — where longitude is recorded in the latitude field and vice versa — is detectable and correctable through the same eight-permutation bounding box check used for other coordinate errors. A farm in Honduras with coordinates (87.5, 14.2) has its axes swapped; the correct reading is (14.2, -87.5). The country boundary check confirms which permutation is plausible.

Undeclared local CRS without UTM-scale values is the hardest case. If a file arrives with geographic coordinates (values in the normal degree range) that are subtly offset because they were recorded in a local datum, the error may not be detectable without a reference point — the coordinates fall within the expected country boundary but are not in the correct location. This is a residual risk that validation can reduce but not eliminate entirely.

What this means for importers

Coordinate system errors are not the most common geo-data problem — missing decimal points, swapped axes, and non-standard field names appear more frequently. But they are among the most consequential, because a farm that is hundreds of metres from its correct location will produce a deforestation check result that refers to the wrong piece of land.

The EUDR Information System cross-checks submitted coordinates against satellite imagery. A coordinate system error that moves a farm polygon into adjacent forest cover will produce a deforestation flag — not because the farm is near a forest, but because the submitted coordinates say it is.

For importers sourcing from Ethiopia, Kenya, Uganda, Colombia, or any other origin with a legacy national coordinate system, the question to ask suppliers is not just "do you have geo-data?" It is "in which coordinate system was that geo-data recorded?" The answer determines whether the data can be submitted as-is or requires a reprojection step before it is useful.