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.
Name transliteration and diacritics in address data
A street named with an accented character, an umlaut, or a character from a non-Latin script can legitimately appear in several different written forms, and all of them can be correct depending on the context. A German street with an umlaut might be written with the umlaut intact, or with the letter followed by an extra "e" as a standard substitution when the umlaut character is not available. A name originally written in a non-Latin script might be transliterated into Latin characters in more than one accepted way, since transliteration is a set of conventions, not a single deterministic function, and different systems make different reasonable choices.
This creates a real matching problem for geocoding. If a user types an address using one valid spelling and the underlying data was indexed using a different, equally valid spelling, a naive exact-match search fails even though both forms clearly refer to the same real street. This is not a data error in the traditional sense, both spellings are correct, but it produces the same user-facing symptom as one, a search that returns nothing when it clearly should have returned a result.
Good address matching handles this by normalizing input before comparison, stripping or standardizing diacritics, accounting for known substitution conventions, and being tolerant of the common alternate transliterations for a given region, rather than requiring an exact character-for-character match against however the underlying data happened to store the name. This is fundamentally a fuzzy matching problem, and it directly affects the confidence score returned for a match, since an address resolved through a diacritic or transliteration variant reasonably carries a slightly different confidence than one matched on an exact literal string.
It is worth testing your own address input handling specifically against names containing diacritics and against places where transliteration is common, rather than assuming your test address set, if it leans heavily on domestic addresses from a single script, represents the full range of inputs your users will actually type. A form that silently mangles or rejects a correctly spelled international address is a quiet but real loss of usable traffic, and it is one of the easier data quality issues to catch early with a deliberately varied test set.
If you are building an autocomplete or input field for international addresses, test it directly against a range of scripts and diacritic variants using the address autocomplete endpoint rather than assuming your existing domestic test cases cover this kind of input.