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.
Address parsing ambiguity: apartments, units and PO boxes
Take an address line like "12B Flat 3" and ask what each part means, and you will find the answer depends on convention, not on the string itself. Is "12B" a building number with a letter suffix, or a floor and unit combined. Is "Flat 3" a separate qualifier for a specific unit within building 12B, or redundant with it. A human familiar with the local convention resolves this instantly. Software parsing arbitrary free text from anywhere in the world has to work much harder, because the same characters carry different meanings depending on where the address comes from.
Unit and apartment designators vary widely across countries and even within them. Abbreviations like "Apt," "Unit," "Ste," "Fl," or a bare number after a comma can each indicate a sub-unit of a building, and different countries and even different regions within a country favor different conventions. A parser tuned for one region's habits will regularly misread another's, either dropping the unit information entirely or attaching it to the wrong part of the address.
PO boxes add a separate wrinkle, because they represent a mailing destination with no direct correspondence to a physical building at all. A PO box has a real, meaningful location in the sense that it belongs to a specific post office, but geocoding it to that post office's coordinates is a different thing than geocoding a street address, and treating the two identically produces a plausible-looking but functionally meaningless result if your use case actually needs a physical delivery point.
The precision and confidence fields exist partly to surface exactly this kind of ambiguity rather than hide it. An address that includes an unresolved or ambiguous unit designator might still geocode successfully at the building level, with precision reflecting that the match succeeded at the building rather than confirming the specific sub-unit was correctly parsed. Reading only the coordinates and ignoring precision here can create false confidence that a specific apartment was located, when in fact only the building was.
If your application depends on unit-level accuracy, such as delivery to a specific apartment within a large complex, it is worth validating that the unit or apartment field was actually parsed and preserved separately, not folded silently into a match that only resolved the building. Testing your address input against real examples containing unit designators, PO boxes, and multi-part building identifiers from several different countries, rather than only your home market's format, will surface this kind of gap well before a user does. Our forward geocoding endpoint returns the type and precision fields specifically so you can tell the difference between a full match and a building-level approximation.