Es gibt eine Kategorie von Koordinatenfehlern, die nichts damit zu tun hat, wie gut die zugrunde liegende Geokodierung war, sondern allein damit, wie die resultierenden Zahlen danach gespeichert, übertragen und weiterverarbeitet werden. Ein völlig exaktes Koordinatenpaar kann spürbare Rundungsfehler aufnehmen, nur weil es irgendwo auf seinem Weg durch Ihr System in einem numerischen Typ mit unzureichender Genauigkeit dargestellt wird, und diese Art von Fehler lässt sich mit ein wenig gezielter Aufmerksamkeit vollständig vermeiden.
Gleitkommazahlen einfacher Genauigkeit, meist float32 genannt, bieten etwa sieben signifikante Dezimalstellen. Bei einem Breiten- oder Längengrad, der schon mehrere Stellen vor dem Komma allein für die ganzen Grad benötigt, bleiben damit spürbar weniger echte Nachkommastellen übrig, als eine Gleitkommazahl doppelter Genauigkeit, meist float64, für denselben Wert bieten würde. Praktisch bedeutet das: Wenn Sie Koordinaten als float32 statt als float64 speichern, können je nach Breitengrad Rundungsfehler in der Größenordnung von einem Meter oder mehr entstehen, völlig unabhängig von und zusätzlich zu den Genauigkeitsgrenzen, die der ursprüngliche Geokodierungstreffer selbst hatte.
Diese Art von Fehler schleicht sich leicht versehentlich ein und wird leicht übersehen, weil sie auf keine offensichtliche Weise wie ein Fehler aussieht: Die resultierende Koordinate ist immer noch eine plausible, korrekt aufgebaute Zahl, die nur unbemerkt ein wenig vom ursprünglichen Wert abgewichen ist. Häufig entsteht sie durch eine Datenbankspalte mit unzureichender numerischer Genauigkeit, durch ein Serialisierungsformat, das standardmäßig einen schmaleren numerischen Typ als beabsichtigt verwendet, oder durch eine Zwischenberechnung, etwa eine Entfernungsformel oder eine Koordinatentransformation, die in einem Typ mit geringerer Genauigkeit ausgeführt wird als der Rest der Pipeline.
Die praktische Empfehlung ist einfach: Verwenden Sie für das Speichern und Berechnen von Koordinaten in Ihrem gesamten System durchgängig Gleitkommazahlen doppelter Genauigkeit oder einen gleichwertigen Festkomma-Dezimaltyp mit ausreichend Stellen, und nicht nur an der Stelle, an der sie zuerst empfangen werden. Prüfen Sie gezielt Ihr Datenbankschema, denn eine Spalte, die als schmalerer Typ als beabsichtigt definiert ist, gehört zu den häufigsten und am leichtesten übersehenen Ursachen genau dieses Problems. Oft wird sie früh im Projekt angelegt und nie wieder überprüft, sobald alles gut genug funktioniert, um die ersten Tests zu bestehen. Prüfen Sie auch jede Serialisierungs- oder API-Schicht zwischen Systemen, denn manche Formate und Bibliotheken verwenden standardmäßig einfache Genauigkeit, sofern nicht ausdrücklich anders angegeben, und verringern die Genauigkeit so unbemerkt genau an der Grenze, an der Sie am wenigsten danach suchen würden.
Die von unseren Endpunkten für Geokodierung und Reverse-Geokodierung zurückgegebenen Koordinaten sind Dezimalwerte mit voller doppelter Genauigkeit. Es lohnt sich, direkt zu überprüfen, ob diese Genauigkeit in Ihrer eigenen Speicher- und Berechnungspipeline erhalten bleibt, statt davon auszugehen, dass sie jeden Schritt automatisch übersteht.