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.
Why "just use lat and lon" oversimplifies location precision
Two coordinate pairs can look completely identical on paper and mean very different things depending on where they came from. One might be a direct GPS reading from a device standing at the exact spot. Another might be the centroid of a city, returned because that was the best match available for a partial or ambiguous address. Printed as bare numbers, both look equally precise. Only the surrounding metadata tells you which one you can actually trust for a fine-grained use case.
This is the core reason "just use lat and lon" is a real oversimplification whenever the source and precision of the coordinates matter to what you are building. A pair of coordinates on their own carries no information about how they were derived, how much area they represent, or how confident the source was in the match. Treating every coordinate pair as equally authoritative, regardless of origin, is how applications end up quietly making decisions, like routing a delivery or triggering a location-based alert, based on what is actually a city-wide approximation rather than a specific point.
This is exactly the gap that precision and confidence fields are designed to close. Precision tells you what kind of match produced the coordinate, house, street, postcode, or city, which directly implies how much real-world area that point plausibly represents. Confidence tells you how sure the match itself was, independent of its precision tier. Together, they turn a bare coordinate pair into something you can actually reason about: not just "here is a point," but "here is a point, here is roughly how precise it claims to be, and here is how sure we are that claim is correct."
The practical habit worth building into any system that stores or passes coordinates between services is to carry precision and confidence alongside the raw numbers, not just the numbers alone. If a coordinate pair gets passed into a database, a queue, or another internal service without that context, anyone consuming it downstream loses the ability to make an informed decision about how much to trust it, and will likely default to treating it as more precise than it actually is, since a lone coordinate pair offers no signal otherwise.
Every geocoding result from our forward and reverse endpoints includes type, precision, and confidence alongside the coordinates for exactly this reason. Passing all of it through your own pipeline, not just the latitude and longitude, is what lets any system further downstream make the same informed judgment your application already had access to at the moment of the original lookup.