Bestätigungsfunktion für Standorte mit der Google Maps Platform erstellen

Ziel

Häufig müssen Sie den Standort eines Ortes überprüfen. Es gibt verschiedene Dienste in der Google Maps Platform, die Ihnen bei diesem Anwendungsfall helfen können. In diesem Dokument erfahren Sie, wie Sie zwischen den beiden wichtigsten Diensten zur Standortüberprüfung wählen können: der Address Validation API und der 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.

Jetzt ausprobieren:Rufen Sie die Google Cloud Console auf und aktivieren Sie die Address Validation API und die Places API.

Address Validation API oder Geocoding API

Hinweise zum obigen Flussdiagramm:

• Der Anwendungsfall „Nutzerinteraktion“ bezieht sich auf den Fall, dass ein Nutzer anwesend ist, um mit den Ergebnissen zu interagieren.
• Places Autocomplete ist eine JavaScript API, die sich für die Integration in Benutzeroberflächen eignet.
• Möglicherweise sind Ihnen Probleme mit der Datenqualität Ihrer vorhandenen Adressen bekannt. Auch wenn Sie nur Geocodes benötigen, sollten Sie diese Standorte über die Address Validation API ausführen, um die Datensätze zu korrigieren.

Es gibt viele Situationen, in denen Sie basierend auf dem obigen Entscheidungsbaum ein Produkt dem anderen vorziehen könnten. In anderen Fällen kann es jedoch sinnvoll sein, beide Produkte zu verwenden, um Ihre Ziele zu erreichen.

In folgenden Fällen können Sie die Address Validation API anstelle der Geocoding API verwenden:

• Es besteht eine hohe Wahrscheinlichkeit, dass es sich um fragwürdige Daten handelt oder dass eine falsche Adresse negative Auswirkungen hat. Das liegt daran, dass die Address Validation API mehr Feedback dazu liefert, warum für eine Eingabe kein Ergebnis mit hoher Präzision erhalten wurde.
• Sie müssen Nutzereingaben korrigieren (z. B. Rechtschreibfehler oder fehlende Felder). Dadurch steigt die Wahrscheinlichkeit, dass ein korrektes Ergebnis ausgegeben wird.
• In Ihrer Zielregion werden von der Address Validation API mehr Metadaten zurückgegeben als von der Geocoding API, z. B. die Klassifizierung des Gebäudetyps als Wohn- oder Geschäftsgebäude.

Sie können das Geocoding anstelle der Address Validation API verwenden, wenn:

• Ihr primäres Ziel ist es, den Standort einer Adresse abzurufen. Die Genauigkeit einzelner Adressen ist dabei möglicherweise nicht entscheidend.
  • Beispielsweise können Sie damit eine Heatmap aus einer großen Datenmenge generieren.
• Sie benötigen eine globale Lösung. 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 gliedert diese Eingabe in die einzelnen Adresskomponenten (Straße, Ort, Bundesland usw.) auf. Außerdem erhalten Sie detailliertes Feedback dazu, warum die Adresse ungültig ist, bis hinunter auf PREMISE-Ebene.

Die Fake Street gibt es in Mountain View, CA, nicht. Die Address Validation API gibt dies in den zurückgegebenen Details auf Komponentenebene an:

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

Die wichtige Eigenschaft, 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 eine Straße diesen Namen haben könnte, er aber nicht mit den unterstützenden Adressdaten abgeglichen werden kann.

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 eine Übereinstimmung mit „Kalifornien“ gefunden werden, wie Sie im Screenshot des Geocoding-Tools sehen, das Sie hier ausprobieren können:

Das Ergebnis ist jedoch ein Geocode für den gesamten Bundesstaat, mit nur minimalen Informationen 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 sind in der Lage, diese Fehler zu korrigieren und das Ergebnis von 76 Buckingham Palace Road, London, SW1W 9TQ, zu erzielen. Die Address Validation API kann jedoch weitere Informationen zum Vorgang 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 mit dem Datenanbieter zu überprüfen, z. B. mit einem Kunden an der Kasse eines E-Commerce-Shops.

Beispiel für fehlende Daten und Rechtschreibfehler

Bollschestraße 86, 12587, DE

Die obige Adresse weist einen Rechtschreibfehler im Straßennamen auf und die Stadt (Ort) von Berlin fehlt.

Die Address Validation API kann beide Fehler beheben und gibt einen Geocode auf PREMISE-Ebene und eine Adresse zurück, die auf der Ebene PREMISE 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 bis auf die Wohnungsnummer (Ste 123) korrekt. Diese Nummer gibt es im Gebäude nicht.

Die Address Validation API kann die Adresse des PREMISE (111 8th Ave) validieren und einige Metadaten zur Unterkunft liefern, darunter, dass es sich um eine kommerzielle

premises:

"business": true

Darüber hinaus lautet 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 auf PREMISE-Ebene validiert wurde, aber die in der Eingabe angegebene Einheitennummer nicht mit dieser Adresse verknüpft ist.

Die Geocoding API kann diese Informationen nicht bereitstellen.

Informationen zur Antwort der Geocoding API

Übersicht

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

Die Geocoding API funktioniert, indem Adresskomponenten in einer Hierarchie aufgelöst werden.

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

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

ChIJwRKzf8ixD4gRHiXqucwr_HQ

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

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

Mit der Geocoding API können Sie prüfen, zu welcher Art von Ort diese Adresse gehört. Eine Liste der Adressen types, die von der Geocoding API zurückgegeben werden, finden Sie hier.

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

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

Wenn Sie nur eine Straße ohne Hausnummer angeben, erhalten Sie ein Ergebnis in folgendem Format:

"types": [
  "route"
]

Das bedeutet, dass die Geocoding API keine Hausnummer finden konnte und keine Übereinstimmungen finden konnte.

Hinweis:Ob eine Adresse existiert, erkennen Sie daran, ob einer der Parameter (z. B. types oder partial_match, results, status)) in der Geocoding API-Antwort festgelegt ist. Dadurch wird das Konfidenzniveau, dass eine Adresse möglicherweise existiert, allmählich erhöht, aber sie ist nicht zu 100% genau. Deshalb benötigen wir die Address Validation API.

Mit den oben genannten Methoden 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 Genauigkeit des Ergebnisses zurück.

Standorttyp

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

• ROOFTOP gibt an, dass das zurückgegebene Ergebnis ein präziser Geocode ist, für den Standortinformationen bis zur Straßengenauigkeit vorliegen.
• 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 keines der oben genannten ist.

Wenn eine Geocoding API einen location_type von ROOFTOP oder RANGE_INTERPOLATED zurückgibt, bedeutet das nicht unbedingt, dass die Adresse existiert. Wenn eine Geocoding API ein Ergebnis mit dem Flag partial_match zurückgibt, das auf true gesetzt ist, ist das möglicherweise trotzdem das richtige Ergebnis für Sie.

Diese Art von Falschübereinstimmung ist mit der Geocoding API nur sehr schwer zu lösen. Sie können zumindest eine grundlegende Validierung der Nachbearbeitung 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 Datenqualitätsüberprüfungen zwischen der ursprünglichen Anfrage und der Geocoding API-Antwort durchführen.

Teilweise Übereinstimmung und falsche Übereinstimmung

Wenn eine Adresse nur teilweise übereinstimmt, 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.

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 in der Anfrage angegebenen Ort vorhanden sind. 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 Fällen enthält das Antwortobjekt oft eine lange Orts-ID und die folgende Eigenschaft: 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 direkt Feedback erhalten, wenn eine Adresse nicht existiert.

Address Validation API-Antworten

Es gibt bereits eine gute Dokumentation dazu, wie Sie die Antworten der Address Validation API verstehen. Wir gehen hier nicht weiter darauf ein.

• Hier finden Sie eine Übersicht über das Antwortobjekt.
• Eine Demo, die die verschiedenen Komponenten der Antwort veranschaulicht, finden Sie hier.
• Im Dokument Adressbestätigung für den Bezahlvorgang wird ausführlich beschrieben, wie Sie zwischen gültigen und ungültigen Adressen unterscheiden.

Best Practices

Geografie angeben

Wenn Sie die APIs zur Adressbestätigung oder Geocodierung aufrufen, sollten Sie die Region eingrenzen, in der nach der Adresse gesucht werden soll. Die beiden APIs implementieren dies auf zwei unterschiedliche Arten:

• Geocoding API – regionale Verzerrung

  Wenn Sie wissen, dass die Geocodes in einem bestimmten Land liegen, erzielen Sie mit der Regionengewichtung viel bessere Ergebnisse. Wenn Sie beispielsweise in Kanada geocodieren, empfehlen wir, Ihren Anfragen &region=ca hinzuzufügen, um die Gewichtung auf Kanada auszurichten. Bei der Gewichtung nach Region werden nur Ergebnisse innerhalb dieser Region bevorzugt. Sie können aber weiterhin Ergebnisse außerhalb der Region erhalten.

• Address Validation API – Regionscode

  Ähnlich liefert die Address Validation API genauere Ergebnisse, wenn in der Anfrage über das Feld regionCode ein ISO2-Code ü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 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 Sie immer auf dem neuesten Stand sind, 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 sich auch den Leitfaden zu Best Practices für das Geocoding durch.

Fazit

In diesem Dokument werden die Hauptunterschiede zwischen der Address Validation API und der Geocoding API beschrieben. Zusammenfassend sollten Sie die Address Validation API verwenden, wenn:

• Eine korrekte Postanschrift ist erforderlich, insbesondere für die Zustellbarkeit.
• Die Eingabedaten sind bekanntlich 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 Mit gültigen Adressen den Bezahlvorgang und die Lieferung optimieren und das Webinar Mit der Adressbestätigung den Bezahlvorgang, die Lieferung und die Abläufe optimieren herunter.

Empfohlene weiterführende Informationen:

• Adressbestätigung für den E-Commerce-Kaufvorgang
• Place Autocomplete – Dokumentation
• Dokumentation zur Address Validation API
• Google Maps Platform Reporting (derzeit nur in englischer Sprache verfügbar)

Beitragende

Dieser Artikel wird von Google gepflegt. Die folgenden Mitwirkenden haben den Artikel ursprünglich verfasst.

Hauptautoren:

Henrik Valve | Solutions Engineer

Thomas Anglaret | Solutions Engineer

Sarthak Ganguly | Solutions Engineer