Ja, rechnen Sie immer mit schwankenden Koordinaten.
Obwohl das Gebäude wahrscheinlich nicht auf der Erdoberfläche zu verschieben ist, unter Verwendung von Koordinaten als Bezeichner / Schlüssel für Adressen , da der Datensatz eine schlechte Idee ist , geht von unten Sie verschieben:
Genauigkeit ist eine Frage der Definition. Ist eine Adresse am genauesten an ihrem Briefkasten, ihrer größten Struktur oder der Haustür befestigt? Welche Haustür? Vielleicht die Auffahrt?
Dezimalgenauigkeit ist ein weiteres Problem. Ist 33.754208das gleiche wie 33.754209? Dies kann durch Runden behoben werden, aber dann verlieren Sie an Präzision. Das Hinzufügen von Dezimalgenauigkeit ist ein Luxus, den Sie möglicherweise nicht haben. Unabhängig davon, wie genau Ihre Dezimalzahl ist, sind sie wahrscheinlich unterschiedlich (insbesondere wenn man bedenkt, wie Computer Float-Typen vergleichen), selbst wenn sie "gleich" sind. Zu diesem Zeitpunkt sind Sie vollständig auf Implementierungsdetails auf niedriger Ebene angewiesen.
Wenn Sie den Datensatz nicht steuern und ein physisches Attribut verwenden, um etwas einzugeben, können Sie nicht garantieren, dass sich der Schlüssel nicht ändert. Dies ist jedoch ein Problem, da Ihre Datenbank erwartet, dass die Kennung eindeutig und konstant ist. Was ist mit Kollisionen mit einem anderen Datenpunkt, selbst wenn Sie es aktualisieren?
Selbst wenn Sie den Datensatz besitzen, sind Sie den ersten beiden Problemen ausgesetzt. Definitionen und Implementierungen ändern sich. Sie könnten Ihre Koordinatendaten niemals aktualisieren, auch nicht für eine bessere "Genauigkeit", aber die Adressen ändern sich immer noch, ob Sie es mögen oder nicht, wodurch Ihr Cache ungültig wird.
Was Sie jedoch tun können, ist, den Schlüssel zu besitzen . Verwenden Sie keine Koordinaten als Bezeichner. Weisen Sie stattdessen einen Schlüssel zu, der garantiert für Ihre Anwendung ( oder möglicherweise für die ganze Welt ) eindeutig ist, und lassen Sie ihn niemals ändern.
Bei SmartyStreets beschäftige ich mich viel mit Geokodierungsadressen. Diese Adresse ist beispielsweise ein Gebäudestandard. Es fehlt eine sekundäre Nummer (Wohnung / Suite). Obwohl unsere Daten auf Blockebene (in der Nähe des Daches) vorliegen, wie wäre ihre Koordinate, wenn wir so genau wie möglich werden könnten? Im Moment weisen wir es zu, 33.75425, -84.38721das nur wenige Meter von Google Maps entfernt ist. Sollte es eine andere Koordinate sein, wenn es sich um die Lobby oder eine Einheit in diesem Gebäude handelt? Die Antwort auf diese Frage kann sich ändern, wodurch sich der zugrunde liegende Datensatz ändert. Und was ist mit Einheiten, die direkt übereinander liegen (Sie können einen Punkt in einem Gebäude festlegen, aber welche Etage haben Sie gemeint)? Google geht offensichtlich genau dieselben Fragen durch, und wenn sich die Antworten ändern, ändern sich auch die Koordinaten.
Aus diesem Grund empfehlen wir immer, dass Personen der Adresse einen Schlüssel geben, den sie steuern, um sie eindeutig zu identifizieren, und ihn niemals ändern.
Warum?
Adressen sind ein Chaos. Sie können sich auch ändern, insbesondere wenn Sie anfangen, die philosophischen Fragen zu stellen: "Was bedeutet eine Adresse wirklich? Stellt sie ein Gebäude oder einen Bewohner dar? Oder eine Mailbox?" und wenn Sie anfangen zu bedenken, dass Adressen zeitlich begrenzt sind, was bedeutet, dass sie sich mit der Zeit ändern, wird es noch hässlicher.
Wir hören auch von Leuten, die versuchen, die Adressen zu hashen oder den Lieferpunkt-Barcode als Kennung zu verwenden. Tun Sie das nicht, denn selbst in einem standardisierten Format können sich Adressen ändern und sind dennoch "dieselbe" Adresse. Und der Barcode für den Zustellpunkt, der fälschlicherweise für eine Adresse als eindeutig angesehen wird, ist doppelt schuldig: Er ändert sich und ist nicht unbedingt eindeutig. Cool was?
Lassen Sie Ihre Datenbank so wenig wie möglich von der tatsächlichen Adresse und den Koordinaten abhängen.