Testing location data with edge cases, not just happy paths
An address in a well mapped city center tells you almost nothing about how your system handles a rural route, a disputed border, or a query near the poles. Test the hard cases deliberately.
Coordinate precision and floating-point rounding errors
There is a category of coordinate error that has nothing to do with how good the underlying geocoding was, and everything to do with how the resulting numbers get stored, transmitted, and computed afterward. A perfectly accurate coordinate pair can pick up meaningful rounding error purely from being represented in a numeric type with insufficient precision somewhere along its journey through your system, and this kind of error is entirely avoidable with a small amount of deliberate attention.
Single-precision floating point numbers, commonly called float32, carry roughly seven significant decimal digits of precision. For a latitude or longitude value, which needs several digits before the decimal point just to represent the whole-number degree component, that leaves noticeably fewer digits of real precision after the decimal point than double-precision floating point, commonly float64, would provide for the identical value. In practical terms, storing coordinates as float32 rather than float64 can introduce rounding error on the order of a meter or more, depending on the exact latitude, entirely separate from and in addition to whatever accuracy limitations existed in the original geocoding match itself.
This kind of error is easy to introduce accidentally and easy to miss, because it does not look like an error in any obvious way, the resulting coordinate is still a plausible, well-formed number, just one that has silently drifted slightly from the original value. It commonly creeps in through a database column defined with insufficient numeric precision, through a data serialization format that defaults to a narrower numeric type than intended, or through an intermediate calculation, a distance formula or a coordinate transformation, performed in a lower-precision type than the rest of the pipeline uses.
The practical guidance is straightforward: use double-precision floating point, or an equivalent fixed-point decimal type with sufficient digits, for storing and computing coordinates throughout your system, end to end, rather than only at the point where they are first received. Check your database schema specifically, since a column defined as a narrower type than intended is one of the most common and easiest to overlook sources of this exact problem, often introduced early in a project and never revisited once it is working well enough to pass initial testing. Check any serialization or API layer between systems as well, since some formats and libraries default to single precision unless explicitly told otherwise, silently downgrading precision at exactly the boundary where you would least expect to look for it.
Coordinates returned by our forward and reverse geocoding endpoints carry full double-precision decimal values. Preserving that precision through your own storage and calculation pipeline is worth verifying directly rather than assuming it survives every step automatically.