Eine Adresse in einem gut kartierten Stadtzentrum sagt Ihnen fast nichts darüber, wie Ihr System mit einer ländlichen Zustellroute, einer umstrittenen Grenze oder einer Anfrage in Polnähe umgeht. Testen Sie die schwierigen Fälle gezielt.
Ein leeres Ergebnis ist eine normale, gültige Antwort und kein Fehler, und Ihr Code braucht einen bewusst angelegten Weg, damit umzugehen.
Eine ländliche Adresse, ein Wahrzeichen oder ein Neubaugebiet ohne zugewiesene Hausnummer lässt sich trotzdem korrekt geokodieren, nur mit gröberer Präzision als eine vollständige Straßenadresse.
In der Nähe der Pole laufen die Längengrade in einem einzigen Punkt zusammen, und Zeitzonen werden nahezu bedeutungslos. Standortsoftware, die auf gewöhnlichen Annahmen beruht, verhält sich dort oft seltsam.
Zwei Punkte, die nur ein kurzes Stück voneinander entfernt sind, können an völlig verschiedenen Kalendertagen liegen, einzig weil die Datumsgrenze zufällig zwischen ihnen verläuft.
Hin und wieder wird eine zusätzliche Sekunde in UTC eingefügt, um die Zeit mit der tatsächlichen Erdrotation in Einklang zu halten. Kaum eine Anwendung muss sich direkt damit befassen.
Eine Koordinate wenige Meter von einer Grenze entfernt kann bei der Reverse-Geokodierung je nachdem, wie die Grenzdaten genau gezeichnet sind, einem der beiden Länder zugeordnet werden. Das ist ein wirklich schwieriger Fall, kein Fehler.
Eine einzige Adresszeichenkette kann mehrere eigenständige Bedeutungsbestandteile enthalten, und dieselbe Abkürzung kann in verschiedenen Ländern Verschiedenes bedeuten. Sie korrekt zu parsen ist schwieriger, als es aussieht.
Zweimal im Jahr gibt es einen Bereich lokaler Uhrzeiten entweder gar nicht oder doppelt. Software, die davon ausgeht, dass jede Uhrzeit eindeutig ist, scheitert genau dann.