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

Ziel

Sie müssen häufig den Standort eines Orts bestätigen. 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 primären Diensten zur Standortvalidierung wählen: der Address Validation API und der Geocoding API.

Die Address Validation API ist ein Google Maps Platform-Produkt, 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.

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

Wann sollte die Address Validation API und wann die Geocoding API verwendet werden?

Hinweise zum Flussdiagramm oben:

• 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 Integration in Benutzeroberflächen.
• Möglicherweise sind Ihnen Probleme mit der Datenqualität bei Ihren vorhandenen Adressen bekannt. Auch wenn Sie nur Geocodes benötigen, ist es ratsam, diese Standorte über die Address Validation API zu korrigieren.

Es gibt viele Situationen, in denen Sie sich anhand des oben stehenden Entscheidungsbaums für das eine oder das andere Produkt entscheiden können. In anderen Fällen ist es jedoch möglicherweise erforderlich, beide Produkte zu verwenden, um Ihre Ziele zu erreichen.

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

• Es besteht eine hohe Wahrscheinlichkeit für fragwürdige Daten oder für negative Auswirkungen, wenn eine falsche Adresse zurückgegeben wird. Das liegt daran, dass die Address Validation API mehr Feedback dazu gibt, warum für eine Eingabe kein Ergebnis mit hoher Genauigkeit zurückgegeben wurde.
• Sie müssen Nutzereingaben korrigieren (z.B. Rechtschreibfehler oder fehlende Felder), um die Wahrscheinlichkeit eines genauen Ergebnisses zu erhöhen.
• 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 Gewerbegebäude.

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

• Ihr primäres Ziel ist es, den Standort einer Adresse abzurufen. Die Genauigkeit einzelner Adressen ist möglicherweise nicht entscheidend.
  • Sie können beispielsweise eine Heatmap aus einer großen Menge von Daten generieren.
• 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 zerlegt diese Eingabe in die einzelnen Adresskomponenten (Straße, Stadt, Bundesstaat usw.). Außerdem kann detailliertes Feedback dazu gegeben werden, warum die Adresse nicht gültig ist, bis hin zur PREMISE-Ebene.

Die Fake St gibt es in Mountain View, Kalifornien, nicht. Das wird auch in den zurückgegebenen Details auf Komponentenebene der Address Validation API berücksichtigt:

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

Die wichtige Property, die in diesem Fall untersucht 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, aber nicht mit den unterstützenden Adressdaten abgeglichen werden kann.

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 „California“ zugeordnet werden, wie im Screenshot des Geocoding-Tools zu sehen ist, das Sie hier ausprobieren können:

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

Beispiel für Rechtschreibfehler

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

Die oben genannte 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, um anzugeben, dass das Feld korrigiert wurde. Anhand dieses Flags kann die 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 Rechtschreibfehler

Bollschestraße 86, 12587, DE

Die obige Adresse enthält einen Rechtschreibfehler im Straßennamen und den Ort Berlin.

Mit der Address Validation API können beide Fehler behoben werden. Sie gibt einen Geocode auf PREMISE-Ebene und 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 Einheitsnummer (Ste 123), die im Gebäude nicht existiert.

Mit der Address Validation API kann die Adresse PREMISE (111 8th Ave) validiert werden. Außerdem werden einige Metadaten zur Immobilie zurückgegeben, z. B. dass es sich um ein gewerblich genutztes Gebäude handelt.

Räumlichkeiten:

"business": true

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

"dpvConfirmation": "S"

Ein dpvConfirmation-Wert von S bedeutet, dass die Adresse bis zur Ebene PREMISE validiert wurde, die im Input angegebene Wohnungsnummer jedoch nicht mit dieser Adresse verknüpft ist.

Die Geocoding API kann diese Informationen nicht bereitstellen.

Geocoding API-Antworten verstehen

Übersicht

Wenn Sie die Geocoding API verwenden, enthält das Geocode-Ergebnis in der Antwort verschiedene Hinweise, mit denen Sie Details der 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 Postleitzahl 60007. Daher wird die folgende Place_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 Adress-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ße, aber ohne Hausnummer stellen, erhalten Sie ein Ergebnis in folgendem Format:

"types": [
  "route"
]

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

Hinweis:Wenn Sie prüfen möchten, ob eine Adresse vorhanden ist, sehen Sie nach, ob in der Geocoding API-Antwort einer der Parameter (z. B. types oder partial_match, results, status)) festgelegt ist. Dadurch wird das Konfidenzniveau, dass eine Adresse vorhanden sein könnte, allmählich erhöht, aber es 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 Geocoding API-Antwort 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

Damit Sie diesen Abschnitt richtig 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 auf die Straßenebene genau sind.
• 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 den location_type-Wert ROOFTOP oder RANGE_INTERPOLATED zurückgibt, bedeutet das nicht unbedingt, dass die Adresse existiert. Wenn für ein Ergebnis der Geocoding API das Flag partial_match auf true gesetzt ist, kann es trotzdem das richtige Ergebnis für Sie sein.

Diese Art von falscher Übereinstimmung 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 in Betracht ziehen. 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.

Teilü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 Standorte 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 Ort vorhanden sind, der in der Anfrage angegeben wird. Teilübereinstimmungen können auch zurückgegeben werden, wenn eine Anforderung mit mehr als einem Standort am selben Ort übereinstimmt.

Wird z. B. „21 Henr St, Bristol, UK“ angefragt, wird 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 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 Eigenschaft: geometry.location_type=APPROXIMATE.

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

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

Antwort der Address Validation API verstehen

Es gibt bereits eine gute 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.
• Eine Demo, die die verschiedenen Komponenten der Antwort veranschaulicht, finden Sie hier.
• Im Dokument zur Adressvalidierung für die Kaufabwicklung wird detailliert beschrieben, wie zwischen guten und schlechten Adressen unterschieden wird.

Best Practices

Region 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, möglichst eingrenzen. 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 viel bessere Ergebnisse. Wenn Sie beispielsweise in Kanada geocodieren, empfehlen wir, Ihren Anfragen &region=ca hinzuzufügen, um die Ergebnisse auf Kanada auszurichten. Beim Anwenden einer Gewichtung werden die Ergebnisse innerhalb der Region lediglich bevorzugt. Sie können aber weiterhin Ergebnisse außerhalb der Region erhalten.

• Address Validation API – Region Code

  Ähnlich verhält es sich bei der Address Validation API. Hier werden genauere Ergebnisse erzielt, 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 entsprechende Orts-ID unbegrenzt als Attribut des Standorts in Ihrer Datenbank speichern. Sie sollten pro placeID 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: Sehen Sie sich auch den Leitfaden zu Best Practices für 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 in folgenden Fällen verwenden sollten:

• Eine korrekte Postanschrift ist erforderlich, insbesondere für die Zustellbarkeit.
• Die Eingabedaten sind bekanntermaßen von schlechter Qualität. Die Address Validation API ist toleranter gegenüber Eingabefehlern, 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 zum Optimieren von Bezahlvorgang, Lieferung und Betrieb mit gültigen Adressen herunter und sehen Sie sich das Webinar zum Optimieren von Bezahlvorgang, Lieferung und Betrieb mit Address Validation an.

Empfohlene Artikel:

• Address Validation for Ecommerce Checkout
• Dokumentation zu Place Autocomplete
• Dokumentation zur Address Validation API
• Google Maps Platform Reporting (derzeit nur in englischer Sprache verfügbar)

Beitragende

Dieser Artikel wird von Google verwaltet. Die folgenden Mitwirkenden haben den Artikel ursprünglich geschrieben.

Hauptautoren:

Henrik Valve | Solutions Engineer

Thomas Anglaret | Solutions Engineer

Sarthak Ganguly | Solutions Engineer