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 coordinate rounding matters more than people think
It is common to see coordinates trimmed to a handful of decimal places before being stored or displayed, often just to make a number look tidier in a table or a URL. What is easy to miss is that each decimal place in a latitude or longitude value corresponds to a specific, calculable distance on the ground, and rounding away digits is rounding away real physical precision, not just visual clutter.
Near the equator, a coordinate carried to four decimal places distinguishes locations roughly ten meters apart, close to the width of a building. Carry it to two decimal places instead, and you are now distinguishing locations closer to a kilometer apart, which is easily the difference between one neighborhood and the next. Round to zero decimal places and you are down to distinguishing entire degrees, spanning many kilometers. The exact distance per decimal place shrinks slightly as you move away from the equator toward the poles for longitude specifically, since lines of longitude converge, but the general relationship between decimal places and real-world distance holds everywhere.
This becomes a real problem in a few common situations. Storing coordinates in a database column with insufficient decimal precision silently truncates data on the way in, and nothing about the failure looks like an error, since the resulting number is still a valid coordinate, just a less accurate one. Passing coordinates through a system that rounds for display purposes and then using that rounded value for a subsequent calculation, like a distance check or a proximity search, compounds the original rounding into every downstream result. Manually copying coordinates between systems, where a person trims digits because the full value looked unnecessarily long, has the same effect.
The safe habit is to store and pass coordinates with enough decimal precision to match your actual use case, generally at least five to six decimal places for anything that needs to stay meaningfully accurate at the building or street level, and to only round for display purposes at the very last step before showing a number to a person, never before a calculation. If you genuinely only need city-level distinction, rounding earlier is fine, but that should be a deliberate choice based on what your application needs, not an accident of a database column width or a formatting habit.
Coordinates returned by forward and reverse geocoding here carry enough decimal precision to support building-level use cases. What you do with that precision downstream, particularly around storage and rounding, is worth checking deliberately rather than assuming it survives every step of your pipeline unchanged.