The Farm Is in Colombia. The Coordinates Are in the Atlantic Ocean.

A coordinate pair is just two numbers. Without context, those numbers mean nothing. With context — a declared country, a known origin, a supply chain relationship — they can be checked against a simple question: does this location actually exist where the farm is supposed to be?

That question is what a country bounding box check asks. And it is remarkable how often the answer is no.

A country bounding box defines the geographic envelope within which a farm should fall. Coordinates outside that envelope are wrong — and the bounding box check is often the only way to know.

What a bounding box is

A country bounding box is the rectangular geographic envelope that contains an entire country — the minimum and maximum latitude and longitude values that define its extent. Colombia's bounding box, for example, runs roughly from latitude -4.2° to 13.4° and longitude -79.0° to -66.9°. Any coordinate that falls outside those ranges cannot be a Colombian farm.

This is a deliberately simple check. It does not verify that a coordinate falls within the actual country boundary — only that it falls within a rectangle large enough to contain the country. A coordinate that passes the bounding box check might still be in the ocean, in a neighbouring country, or on the wrong side of a mountain range. But a coordinate that fails the bounding box check is unambiguously wrong. No Colombian coffee farm has a longitude of +74.5°. That is the Bay of Bengal.

The errors it catches that nothing else does

Most geo-data errors are visible in the structure of the file. An unclosed polygon ring, a comma used as a decimal separator, a missing field name — these are detectable by looking at the file itself, without reference to any external data.

Coordinate location errors are different. A swapped latitude and longitude produces two perfectly valid numbers, in perfectly valid decimal format, that simply describe a location on the other side of the world. A missing negative sign produces a valid positive coordinate that falls in the wrong hemisphere. A decimal shift produces a valid coordinate that falls off the edge of the map — or on a farm in Bangladesh instead of Guatemala.

None of these errors are visible in the file. The numbers look right. The format is correct. The file parses without complaint. The error only becomes apparent when you ask: where is this?

How the correction works — the eight-permutation approach

When a coordinate fails the bounding box check, the question is not just "this is wrong" but "can we determine what the correct value is?" For a category of common errors, the answer is yes — because the correct coordinate is recoverable by testing a small set of transformations against the known country boundary.

For a two-coordinate pair (latitude, longitude), there are eight possible permutations of axis order, sign, and negation. Testing each permutation against the country bounding box identifies which one — if any — produces a coordinate that falls within the expected country.

When exactly one permutation lands within the country bounding box, the correction is deterministic — the error is identifiable and the fix is unambiguous. The record is auto-corrected and flagged as such in the validation report.

When zero permutations land within the bounding box, the coordinate cannot be recovered automatically. The record is flagged for supplier follow-up with a precise description of what was submitted and why it failed. When more than one permutation lands within the bounding box — which can happen for countries with unusual shapes or for coordinates near country borders — the correction is ambiguous and the record is flagged for manual review rather than auto-corrected.

What the bounding box cannot catch

A bounding box check has a known limitation that is worth being explicit about. It validates that a coordinate falls within a rectangular envelope around a country. It does not validate that the coordinate falls within the actual country boundary — only that it is in the right region of the world.

A coordinate that falls in the Caribbean Sea off the Colombian coast will pass a Colombia bounding box check. A coordinate that falls in Venezuela — adjacent to Colombia's eastern border — may also pass, depending on how tightly the bounding box is drawn. For these cases, a more precise point-in-polygon check against the actual country boundary is required.

There is also a category of error that no location check can catch: a coordinate that is internally consistent and falls within the correct country, but does not correspond to the actual farm location. A field agent who records the GPS coordinates of the road outside the farm instead of the farm itself produces a coordinate that passes every automated check — but describes the wrong piece of land.

Why this matters more than it sounds

A coordinate that places a Colombian coffee farm in the Atlantic Ocean will not pass any deforestation check — because there is no land there to check against. The compliance tool will either reject the record or return an error. The DDS cannot be submitted.

But the damage is often done before the compliance tool is ever involved. If a batch of 400 farms is submitted to a compliance tool and 12 of them have coordinates outside the country boundary, the compliance tool processes 388 records and errors on 12. Those 12 farms go back to the importer, who goes back to the supplier, who goes back to the field agent — a cycle that takes weeks and delays the shipment.

A bounding box check run before the file reaches the compliance tool catches those 12 farms in minutes. For the errors that are auto-correctable — swapped axes, missing signs — the record is fixed before it leaves the validation step. For the errors that are not — coordinates that cannot be recovered by permutation testing — the supplier receives a precise, farm-level description of what is needed, weeks before the shipment deadline rather than days after it.