Address Validation im Vergleich zu Geocoding

Ziel

Oft müssen Sie den Standort eines Orts bestätigen. In der Google Maps Platform gibt es einige verschiedene Dienste, die Ihnen dabei helfen können. In diesem Dokument erfahren Sie, wie Sie zwischen den beiden wichtigsten Diensten zur Standortbestätigung wählen: der Address Validation API und der Geocoding API.

Die **Address Validation API** ist ein Angebot der Google Maps Platform, mit dem Kunden überprüfen können, ob eine Adresse korrekt ist.

Beim**Geocoding** mit der Geocoding API werden Adressen in geografische Koordinaten umgewandelt, mit denen Sie Markierungen auf einer Karte platzieren oder die Karte positionieren können.

Eine allgemeine Übersicht über die Unterschiede zwischen der Address Validation API und der Geocoding API finden Sie hier.

Wann sollte ich die Address Validation API und wann die Geocoding API verwenden?

Address-Validation-vs-Geocoding

Hinweise zum obigen Flussdiagramm :

  • Der Anwendungsfall „Nutzerinteraktion“ bezieht sich auf Situationen, in denen ein Nutzer anwesend ist, um mit den Ergebnissen zu interagieren.
  • Places Autocomplete ist eine JavaScript API und eignet sich daher für die Einbindung in Benutzeroberflächen.
  • Möglicherweise sind Ihnen Probleme mit der Datenqualität in Ihren vorhandenen Adressen bekannt. Auch wenn Sie nur Geocodes benötigen, empfiehlt es sich, diese Standorte über die Address Validation API zu verarbeiten, um die Datensätze zu korrigieren.

Es gibt viele Situationen, in denen Sie sich anhand des obigen Entscheidungsbaums für das eine oder andere Produkt entscheiden können. In anderen Situationen müssen Sie möglicherweise beide Produkte verwenden, um Ihre Ziele zu erreichen.

Sie sollten die Address Validation API anstelle der Geocoding API verwenden, wenn:

  • Die Wahrscheinlichkeit für fragwürdige Daten hoch ist oder eine falsche Adresse negative Auswirkungen nach sich zieht. Die Address Validation API bietet mehr Feedback dazu, warum für eine Eingabe kein Ergebnis mit hoher Genauigkeit erzielt wurde.
  • Sie Nutzereingaben korrigieren müssen (z.B. Tippfehler oder fehlende Felder), wodurch die Wahrscheinlichkeit eines genauen Ergebnisses bei der Ausgabe steigt.
  • Ihre Zielregion mehr Metadaten von der Address Validation API als von der Geocoding API zurückgibt, z. B. die Klassifizierung des Gebäudetyps als Wohn- oder Geschäftsgebäude.

Sie sollten die Geocoding API anstelle der Address Validation API verwenden, wenn:

  • Ihr Hauptziel darin besteht, den Standort einer Adresse abzurufen, und die Genauigkeit einzelner Adressen möglicherweise nicht entscheidend ist.
    • Sie möchten beispielsweise eine Heatmap aus einem großen Dataset generieren.
  • Sie hyperlokale Zielortdetails benötigen, z. B. Gebäudeeingänge, Gebäudeumrisse oder Navigationspunkte für die Abholung und Zustellung (verfügbar mit der SearchDestinations-Methode in der Geocoding API v4).
  • Sie eine globale Lösung benötigen und die Address Validation API nicht in allen Zielregionen verfügbar ist.

Im Folgenden finden Sie einige Beispiele, die die Funktionen der Address Validation API im Vergleich zur Geocoding API veranschaulichen.

Beispiel für eine ungültige Adresse

1 Fake St, Mountain View, CA 94043, USA

Die Address Validation API unterteilt diese Eingabe in ihre einzelnen Adresskomponenten (Straße, Stadt, Bundesstaat usw.). Sie kann auch detailliertes Feedback dazu geben, warum die Adresse bis auf die Ebene PREMISE ungültig ist.

Die Fake St gibt es in Mountain View, Kalifornien, nicht. Die Address Validation API gibt dies in den Details auf Komponentenebene zurück:

{
  "componentName": {
    "text": "Fake St",
    "languageCode": "en"
   },
   "componentType": "route",
   "confirmationLevel":"UNCONFIRMED_BUT_PLAUSIBLE"
 }

Die wichtige Property, die in diesem Fall geprüft werden muss, ist confirmationLevel. Durch die Rückgabe von UNCONFIRMED_BUT_PLAUSIBLE für die Fake St hat die API festgestellt, dass es möglich wäre, dass eine Straße diesen Namen hat, sie kann aber nicht mit den unterstützenden Adressdaten abgeglichen werden.

Anhand des API-Ergebnisses als Feedback lässt sich ableiten, dass die Straßenkomponente dieser Eingabe (Fake St) fehlerhaft ist.

Wenn Sie dieselbe Adresse mit der Geocoding API verwenden, kann sie eine Übereinstimmung für „California“ finden, wie Sie im Screenshot des Geocoding-Tools sehen, das Sie hier ausprobieren können:

alt_text

Das Ergebnis ist jedoch ein Geocode des gesamten Bundesstaats mit minimalem Feedback dazu, welche Komponenten der Eingabe möglicherweise fehlerhaft waren.

Beispiel für einen Rechtschreibfehler

76 Buckingamm Palace Road, Londn, SW1W 9TQ, GB

Die obige Adresse enthält zwei Rechtschreibfehler, einen im Straßennamen und einen im Ort.

Sowohl die Address Validation API als auch die Geocoding API können diese Fehler korrigieren und das Ergebnis „76 Buckingham Palace Road, London, SW1W 9TQ“ erzielen. Die Address Validation API kann jedoch mehr Informationen zum Prozess liefern.

Sehen Sie sich eine der Adresskomponenten an, die bei der Eingabe falsch geschrieben wurde:

{
  "componentName": {
    "text": "Buckingham Palace Road",
    "languageCode": "en"
        },
        "componentType": "route",
        "confirmationLevel": "CONFIRMED",
        "spellCorrected": true
     }
}

Die Address Validation API gibt ein Flag zurück, um anzugeben, dass eine Korrektur am Feld vorgenommen wurde. Anhand dieses Flags kann eine Geschäftslogik implementiert werden, um die Korrektur beim Datenanbieter zu überprüfen, z. B. bei einem Kunden an der Kasse eines Onlineshops.

Beispiel für fehlende Daten und einen Rechtschreibfehler

Bollschestraße 86, 12587, DE

Die obige Adresse enthält einen Rechtschreibfehler im Straßennamen und die Stadt (Ort) Berlin fehlt.

Die Address Validation API kann beide Fehler beheben und gibt einen PREMISE Geocode sowie eine Adresse zurück, die bis zur PREMISE Ebene bestätigt wurde:

Bölschestraße 86, 12587 Berlin, DE

Die Geocoding API kann die Eingabefehler in diesem Fall nicht beheben und gibt das Ergebnis ZERO_RESULTS zurück.

Beispiel für zusätzliche Adressmetadaten

111 8th Avenue Ste 123, New York, NY 10011-5201, US

Diese Adresse ist korrekt, mit Ausnahme der Einheitennummer (Ste 123), die im Gebäude nicht vorhanden ist.

Die Address Validation API kann die Adresse bis zur Ebene PREMISE (111 8th Ave) bestätigen und einige Metadaten zum Objekt liefern, einschließlich der Angabe, dass es sich um ein Geschäftsgebäude

handelt:

"business": true

Außerdem ist der Wert dpvConfirmation, der als Teil von uspsData in der Antwort zurückgegeben wird, S:

"dpvConfirmation": "S"

Ein dpvConfirmation Wert von S gibt an, dass die Adresse bis zur Ebene PREMISE bestätigt wurde, die in der Eingabe angegebene Einheitennummer jedoch nicht mit dieser Adresse verknüpft ist.

Die Geocoding API kann diese Informationen nicht liefern.

Antwort der Geocoding API

Übersicht

Wenn Sie die Geocoding API verwenden, enthält das Geocode-Ergebnis in der Antwort verschiedene Hinweise, mit denen Sie Details zur angegebenen Adresse nachvollziehen können.

Die Geocoding API löst Adresskomponenten in einer Hierarchie auf.

**Beispiel** : 123 Example Street, Chicago, 60007, USA wird in der folgenden Reihenfolge aufgelöst:

/ Example Street/ Chicago/ 60007/ USA wird in dieser Reihenfolge ausgewertet. Die erste Übereinstimmung ist in diesem Fall Chicago und genauer gesagt die 60007 Postleitzahl. Daher wird die folgende Orts-ID für diese Postleitzahl zurückgegeben:

ChIJwRKzf8ixD4gRHiXqucwr_HQ

Die Geocode API enthält die folgenden Informationen in der Antwort:

        "partial_match": true,
           "place_id": "ChIJwRKzf8ixD4gRHiXqucwr_HQ",
           "types": [
               "postal_code"
           ]

Die Geocoding API kann bestätigen, zu welcher Art von Ort diese Adresse gehört. Eine Liste der von der Geocoding API zurückgegebenen Adresstypen types finden Sie hier.

Wenn keine der Komponenten der Eingabe aufgelöst wird, gibt die API Folgendes zurück:

{
   "results": [],
   "status": "ZERO_RESULTS"
}

Wenn Sie eine Anfrage nur mit der Straßenadresse ohne Hausnummer stellen, wird ein Ergebnis im folgenden Format zurückgegeben:

"types": [
  "route"
]

Das bedeutet, dass die Geocoding API keine Hausnummer finden oder zuordnen konnte.

Hinweis: Wenn Sie wissen möchten, ob eine Adresse vorhanden ist, prüfen Sie, ob in der Antwort der Geocoding API einer der Parameter (z. B. types, partial_match, results, status) festgelegt ist. Dadurch steigt die Wahrscheinlichkeit, dass eine Adresse vorhanden ist, aber sie wird nicht zu 100% genau sein. Deshalb benötigen wir die Address Validation API.

Mit den oben genannten Techniken können Sie die Zuverlässigkeit der Adressgenauigkeit allein anhand einer Antwort der Geocoding API erhöhen. Im Gegensatz zu einem Ergebnis der Address Validation API gibt die Geocoding API jedoch kein genaues Feedback zur Bestimmung der Ergebnisgenauigkeit zurück.

Standorttyp

Um diesen Abschnitt richtig zu verstehen, müssen Sie die verschiedenen Standorttypen kennen, die in einer Antwort der Geocoding API zurückgegeben werden können:

  • ROOFTOP gibt an, dass das zurückgegebene Ergebnis ein präziser Geocode ist, für den wir Standortinformationen haben, die bis zur Genauigkeit der Straßenadresse reichen.
  • RANGE_INTERPOLATED gibt an, dass das zurückgegebene Ergebnis eine Schätzung ist (normalerweise auf einer Straße), die anhand von zwei genauen Punkten (wie Kreuzungen) interpoliert wurde. Interpolierte Ergebnisse werden zurückgegeben, wenn präzise Geocodes für eine Postanschrift nicht verfügbar sind.
  • GEOMETRIC_CENTER gibt an, dass das zurückgegebene Ergebnis der geometrische Mittelpunkt eines Ergebnisses wie z. B. einer Polylinie (z. B. eine Straße) oder eines Polygons (eine Region) ist.
  • APPROXIMATE gibt an, dass das zurückgegebene Ergebnis keines der oben genannten ist.

Wenn die Geocoding API einen location_type von ROOFTOP oder RANGE_INTERPOLATED zurückgibt, bedeutet das nicht unbedingt, dass die Adresse vorhanden ist. Ebenso kann es sein, dass die Geocoding API mit dem partial_match Flag auf true das richtige Ergebnis für Sie zurückgibt.

Diese Art von falscher Übereinstimmung ist ein sehr schwieriges Problem, das mit der Geocoding API gelöst werden kann. Sie sollten zumindest eine grundlegende Nachbearbeitungsvalidierung für das Land und den Ort der Anfrage / Antwort implementieren. Noch besser ist es, die tatsächlichen Straßenadressen auf Tippfehler und/oder Vollständigkeit zu prüfen.

Hinweis: Wenn Sie die Geocoding API verwenden, sollten Sie regelmäßig Datenqualitätsprüfungen zwischen der ursprünglichen Anfrage und der Antwort der Geocoding API durchführen.

Teilweise Übereinstimmung und falsche Übereinstimmung

Wenn eine Adresse eine teilweise Übereinstimmung ist, d. h. die Geocoding API die Adresse nicht genau identifizieren konnte, enthält die Antwort Folgendes:

"partial_match": true,
"types": [
           "locality",
           "political"
         ]

Noch wichtiger als die oben genannten Standorttypen ist es, zu berücksichtigen, wann partial_match = true in der Antwort enthalten ist . partial_match gibt an, dass die Geocoding API keine genaue Übereinstimmung für die ursprüngliche Anfrage zurückgegeben hat, obwohl ein Teil der angeforderten Adresse zugeordnet werden konnte.

Sie sollten die ursprüngliche Anfrage auf eine unvollständige Adresse prüfen. Teilweise Übereinstimmungen treten am häufigsten bei Adressen auf, die nicht in dem Ort vorhanden sind, der in der Anfrage angegeben wird. Teilweise Übereinstimmungen können auch zurückgegeben werden, wenn eine Anfrage mit mehr als einem Standort am selben Ort übereinstimmt.

Wird „21 Henr St, Bristol, UK“ angefragt, wird z. B. eine teilweise Übereinstimmung für die Henry Street und die Henrietta Street zurückgegeben. Enthält eine Anfrage eine Adresskomponente mit Tippfehler, wird von der Geocoding API möglicherweise eine andere Adresse vorgeschlagen. Solche Vorschläge werden nicht als teilweise Übereinstimmung gekennzeichnet.

Synthetische Adressen

Die Geocoding API kann Standorte für „synthetische“ Adressen zurückgeben, die in der Datenbank von Google nicht als genaue Standorte vorhanden sind.

In solchen Fällen enthält das Antwortobjekt oft eine lange Orts-ID und die folgende Property: geometry.location_type=APPROXIMATE.

Wenn Sie diese Hinweise in der Antwort sehen, sollten Sie die Eingabeadresse als ungültig kennzeichnen und versuchen, sie auf andere Weise neu zu bestätigen.

Hinweis: Dies ist ein weiteres Beispiel dafür, dass Sie mit der Address Validation API direkt Feedback erhalten, wenn eine Adresse nicht vorhanden ist.

Antwort der Address Validation API

Es gibt bereits eine ausführliche Dokumentation dazu, wie die Antworten der Address Validation API zu interpretieren sind. Daher gehen wir hier nicht weiter ins Detail.

  • Eine Übersicht über das Antwortobjekt finden Sie hier.
  • Hier finden Sie eine Demo, in der die verschiedenen Komponenten der Antwort veranschaulicht werden: hier
  • Im Dokument Address Validation for checkout wird detailliert beschrieben, wie Sie zwischen guten und schlechten Adressen unterscheiden.

Best Practices

Geografische Angaben

Wenn Sie Aufrufe an die Address Validation API oder die Geocoding API senden, sollten Sie die geografische Suche nach dieser Adresse einschränken. Die beiden APIs implementieren dies auf zwei verschiedene Arten:

  • Geocoding API – Gewichtung nach Region

    Wenn Sie wissen, dass sich die Geocodes in einem bestimmten Land befinden, erhalten Sie mit der Gewichtung nach Region viel bessere Ergebnisse. Wenn Sie beispielsweise in Kanada geocodieren, empfehlen wir, Ihren Anfragen &region=ca hinzuzufügen, um die Ergebnisse auf Kanada zu beschränken. Beachten Sie, dass bei der Gewichtung nach Region nur Ergebnisse innerhalb dieser Region bevorzugt werden. Sie können weiterhin Ergebnisse außerhalb der Region erhalten.

  • Address Validation API – Ländercode

    Ähnlich verhält es sich bei der Address Validation API. Sie liefert genauere Ergebnisse, wenn im Feld regionCode ein ISO2-Code in der Anfrage übergeben wird.

Orts-IDs speichern

Wenn Sie Google Maps Platform-Informationen zum Standort für zukünftige Anfragen speichern möchten, können Sie die Orts-ID unbegrenzt als Attribut des Standorts in Ihrer Datenbank speichern. Sie müssen nur einmal pro Orts-ID eine „Find Place“-Anfrage stellen. Sie können auch jedes Mal nach der Orts-ID suchen, wenn ein Nutzer Transaktionsdetails anfordert.

Damit Ihnen immer möglichst aktuelle Informationen vorliegen, sollten Sie die Orts-IDs alle zwölf Monate aktualisieren. Stellen Sie dazu eine „Place Details“-Anfrage mit dem Parameter place_id.

Hinweis: Sehen Sie sich auch den Leitfaden zu den Best Practices für das Geocoding an.

Fazit

In diesem Dokument werden die wichtigsten Unterschiede zwischen der Address Validation API und der Geocoding API beschrieben. Zusammenfassend lässt sich sagen, dass Sie die Address Validation API verwenden sollten, wenn:

  • Eine genaue Postanschrift ist erforderlich, insbesondere für die Zustellbarkeit.
  • Die Eingabedaten bekanntermaßen von schlechter Qualität sind. Die Address Validation API ist toleranter gegenüber Eingabefehlern, hebt nicht überprüfbare Adresskomponenten hervor und korrigiert die Eingabedaten.
  • Weitere Informationen zu einer Adresse erforderlich sind, z. B. ob es sich um eine Privat- oder Geschäftsadresse handelt (in ausgewählten Regionen verfügbar).

Nächste Schritte

Laden Sie das Improve checkout, delivery, and operations with reliable addresses Whitepaper herunter und sehen Sie sich das Improving checkout, delivery, and operations with Address Validation Webinar an.

Empfohlene weitere Artikel:

Beitragende

Dieser Artikel wird von Google verwaltet. Die folgenden Beitragenden haben ihn ursprünglich verfasst.

Hauptautoren:

Henrik Valve | Solutions Engineer

Thomas Anglaret | Solutions Engineer

Sarthak Ganguly | Solutions Engineer