Address Validation im Vergleich zu Geocoding

Ziel

Häufig müssen Sie den Standort eines Ortes validieren. In der Google Maps Platform gibt es verschiedene Dienste, die Sie für diesen Anwendungsfall nutzen können. In diesem Dokument werden die beiden wichtigsten Dienste zur Standortvalidierung verglichen: die Address Validation API und die Geocoding API.

Die Address Validation API ist ein Angebot der Google Maps Platform, mit dem Kunden prü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 Sie die Address Validation API und wann die Geocoding API verwenden sollten

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 Ihrer vorhandenen Adressen bekannt. Auch wenn Sie nur Geocodes benötigen, ist es daher ratsam, die Standorte über die Address Validation API zu prüfen, um die Datasets zu korrigieren.

Es gibt viele Situationen, in denen Sie sich anhand des obigen Entscheidungsbaums für ein Produkt entscheiden können. In anderen Situationen kann es jedoch sinnvoll sein, beide Produkte zu verwenden, um Ihre Ziele zu erreichen.

In folgenden Fällen ist die Address Validation API der Geocoding API vorzuziehen:

  • Es besteht eine hohe Wahrscheinlichkeit, dass die Daten fragwürdig sind oder dass eine falsche Adresse negative Auswirkungen auf nachgelagerte Prozesse hat. Das liegt daran, dass die Address Validation API mehr Feedback dazu liefert, warum eine Eingabe kein Ergebnis mit hoher Genauigkeit erzielt hat.
  • Sie müssen Nutzereingaben korrigieren (z.B. Rechtschreibfehler oder fehlende Felder), um die Wahrscheinlichkeit eines genauen Ergebnisses bei der Ausgabe zu erhöhen.
  • In Ihrer Zielregion gibt die Address Validation API mehr Metadaten zurück als die Geocoding API, z. B. die Klassifizierung des Gebäudetyps als Wohn- oder Geschäftsgebäude.

In folgenden Fällen ist die Geocoding API der Address Validation API vorzuziehen:

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

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 die einzelnen Adresskomponenten (Straße, Ort, Bundesland usw.). Außerdem kann sie detailliertes Feedback dazu geben, warum die Adresse nicht gültig ist, bis hin zur Ebene PREMISE.

Die Fake St existiert nicht in Mountain View, Kalifornien. Die Address Validation API spiegelt dies in den zurückgegebenen Details auf Komponentenebene wider:

{
  "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 „Fake St“ hat die API festgestellt, dass es möglich wäre, dass eine Straße diesen Namen hat, aber sie kann nicht mit den unterstützenden Adressdaten abgeglichen werden.

Anhand des API-Ergebnisses 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 „California“ zuordnen, wie im folgenden Screenshot des Geocoder-Tools zu sehen ist:

alt_text

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

Beispiel für einen Rechtschreibfehler

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

Die obige Adresse enthält einige 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“ liefern. Die Address Validation API kann jedoch weitere 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, das angibt, dass das Feld korrigiert wurde. Anhand dieses Flags kann eine Geschäftslogik implementiert werden, um die Korrektur mit dem Datenanbieter, z. B. einem Kunden an einer E-Commerce-Kasse, noch einmal zu überprüfen.

Beispiel für fehlende Daten und Rechtschreibfehler

Bölschestraß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 Geocode auf PREMISE-Ebene sowie eine Adresse zurück, die auf 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, USA

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

Die Address Validation API kann die Adresse bis zur PREMISE (111 8th Ave) validieren und einige Metadaten zur Immobilie bereitstellen, einschließlich der Information, dass es sich um ein Gewerbeobjekt handelt.

Prämissen:

"business": true

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

"dpvConfirmation": "S"

Der dpvConfirmation-Wert S gibt an, dass die Adresse bis zur Ebene PREMISE validiert wurde, die in der Eingabe angegebene Wohnungsnummer jedoch nicht mit dieser Adresse verknüpft ist.

Die Geocoding API kann diese Informationen nicht bereitstellen.

Geocoding API-Antwort verstehen

Übersicht

Wenn Sie die Geocoding API verwenden, enthält das Geocoding-Ergebnis verschiedene Hinweise in der Antwort, die Ihnen helfen, die Details der angegebenen Adresse zu verstehen.

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 werden in dieser Reihenfolge ausgewertet. Die erste Übereinstimmung ist in diesem Fall Chicago, genauer gesagt die Postleitzahl 60007. 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"
           ]

Mit der Geocoding API lässt sich bestätigen, zu welcher Art von Ort diese Adresse gehört. Eine Liste der von der Geocoding API zurückgegebenen types für Adressen 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 einer Adresse 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 existiert, prüfen Sie, ob einer der Parameter (z. B. types, partial_match, results, status)) in der Geocoding API-Antwort festgelegt ist. Dadurch wird die Wahrscheinlichkeit, dass eine Adresse existiert, schrittweise erhöht, aber nicht zu 100 % genau. Deshalb benötigen wir die Address Validation API.

Mit den oben beschriebenen Techniken können Sie die Zuverlässigkeit der Adressgenauigkeit allein anhand einer Geocoding API-Antwort erhöhen. Im Gegensatz zu einem Ergebnis der Address Validation API gibt die Geocoding API jedoch kein genaues Feedback zurück, um die Genauigkeit des Ergebnisses zu bestimmen.

Standorttyp

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

  • ROOFTOP gibt an, dass das zurückgegebene Ergebnis ein genauer Geocode ist, für den wir Standortinformationen mit der Genauigkeit einer Adresse haben.
  • 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 üblicherweise dann zurückgegeben, wenn hausnummern-genaue Geocodierungen für eine Adresse in einer Straße nicht zur Verfügung stehen.
  • 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 keiner der oben genannten Typen ist.

Wenn die Geocoding API den location_type-Wert ROOFTOP oder RANGE_INTERPOLATED zurückgibt, bedeutet das nicht unbedingt, dass die Adresse existiert. Wenn die Geocoding API ein Ergebnis mit dem Flag partial_match und dem Wert true zurückgibt, kann es trotzdem das richtige Ergebnis für Sie sein.

Diese Art von falscher Zuordnung ist mit der Geocoding API nur sehr schwer zu beheben. Sie sollten zumindest eine grundlegende Nachbearbeitungsvalidierung für das Land und den Ort der Anfrage/Antwort implementieren. Am besten vergleichen Sie die tatsächlichen Adressen auf Tippfehler und/oder Vollständigkeit.

Hinweis: Wenn Sie die Geocoding API verwenden, sollten Sie regelmäßig die Datenqualität zwischen der ursprünglichen Anfrage und der Antwort der Geocoding API prüfen.

Teilübereinstimmung und falsche Übereinstimmung

Wenn eine Adresse nur teilweise übereinstimmt, d. h., die Geocoding API konnte die Adresse nicht genau identifizieren, 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 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.

Wir empfehlen, die ursprüngliche Anfrage auf Vollständigkeit zu prüfen. Teilweise Übereinstimmungen treten am häufigsten bei Adressen auf, die nicht in dem Ort vorhanden sind, der in der Anfrage angegeben ist. Teilübereinstimmungen können auch zurückgegeben werden, wenn eine Anforderung 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 gibt möglicherweise Standorte für „synthetische“ Adressen zurück, die in der Google-Datenbank nicht als genaue Standorte vorhanden sind.

In solchen Szenarien enthält das Antwortobjekt oft eine lange Orts-ID und das folgende Attribut: geometry.location_type=APPROXIMATE.

Wenn Sie diese Indikatoren in der Antwort sehen, sollten Sie die eingegebene Adresse als ungültig markieren und versuchen, sie auf andere Weise zu validieren.

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

Address Validation API-Antwort

Es gibt bereits eine gute Dokumentation dazu, wie die Antworten der Address Validation API zu verstehen sind. Daher gehen wir hier nicht weiter darauf ein.

Best Practices

Geografische Einheit angeben

Wenn Sie die Address Validation API oder die Geocoding API aufrufen, sollten Sie die geografische Region, in der nach der Adresse gesucht werden soll, einschränken. Die beiden APIs implementieren dies auf zwei verschiedene Arten:

  • Geocoding API – Region Biasing

    Wenn Sie wissen, dass sich die Geocodes in einem bestimmten Land befinden, erzielen Sie mit der Regionsgewichtung wesentlich bessere Ergebnisse. Wenn Sie beispielsweise in Kanada Geocoding-Anfragen stellen, empfehlen wir, &region=ca in Ihre Anfragen aufzunehmen, um die Ergebnisse auf Kanada auszurichten. Beachten Sie, dass bei der regionalen Gewichtung Ergebnisse innerhalb dieser Region lediglich bevorzugt werden. Sie können aber weiterhin Ergebnisse außerhalb der Region erhalten.

  • Address Validation API – Region Code

    Ähnlich liefert die Address Validation API genauere Ergebnisse, wenn in der Anfrage ein ISO2-Code im Feld regionCode ü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 entsprechende Orts-ID unbegrenzt als Attribut des Standorts in Ihrer Datenbank speichern. Sie sollten pro Orts-ID nur einmal eine Find Place-Anfrage stellen müssen. 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: Lesen Sie auch den Leitfaden mit Best Practices für das Geocoding.

Fazit

In diesem Dokument werden die wesentlichen Unterschiede zwischen der Address Validation API und der Geocoding API beschrieben. Zusammenfassend lässt sich sagen, dass die Address Validation API in folgenden Fällen verwendet werden sollte:

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

Nächste Schritte

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

Empfohlene weitere Informationen:

Beitragende

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

Hauptautoren:

Henrik Valve | Solutions Engineer

Thomas Anglaret | Solutions Engineer

Sarthak Ganguly | Solutions Engineer