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

Ziel

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

Bei der Geocoding API mit der Geocoding API werden Adressen in geografische Koordinaten umgewandelt, mit denen sich Markierungen auf einer Karte oder einer Position auf der Karte platzieren lassen.

Einen allgemeinen Überblick über die Unterschiede zwischen Address Validation und Geocoding API finden Sie hier.

Wann sollte die Address Validation API im Vergleich zur Geocoding API verwendet werden?

Address-Validation-vs-Geocoding

Hinweise zum obigen Flussdiagramm:

  • Anwendungsfall „Nutzerinteraktion“ bezieht sich darauf, dass Nutzer anwesend sind, 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 bestehenden Adressen bekannt. Auch wenn Sie nur Geocodes benötigen, ist es ratsam, diese Standorte über die Address Validation API auszuführen, um die Datensätze zu korrigieren.

Es gibt viele Situationen, in denen Sie sich basierend auf dem obigen Entscheidungsbaum dafür entscheiden könnten, ein Produkt gegenüber dem anderen zu verwenden. In anderen Situationen können jedoch beide Produkte verwendet werden, um Ihre Ziele zu erreichen.

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

  • Es besteht ein hohes Risiko für fragwürdige Daten oder die Angabe einer falschen Adresse hat negative Auswirkungen auf nachgelagerte Leistungsmerkmale. Das liegt daran, dass die Address Validation API mehr Feedback dazu gibt, warum eine Eingabe kein Ergebnis mit hoher Genauigkeit erhalten hat.
  • Sie müssen Nutzereingaben (z.B. Rechtschreibfehler oder fehlende Felder) korrigieren, um die Wahrscheinlichkeit eines genauen Ergebnisses in der Ausgabe zu erhöhen.
  • Ihre Zielregion liefert von der Address Validation API im Vergleich zur Geocoding API mehr Metadaten, z. B. die Klassifizierung des Gebäudetyps als Wohngebäude oder Gewerbegebäude.

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

  • Ihr primäres Ziel ist es, den Standort einer Adresse abzurufen. Die Genauigkeit einzelner Adressen ist dabei möglicherweise nicht entscheidend.
    • Zum Beispiel, um eine Heatmap aus einem großen Datensatz zu 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, in denen die Funktionen der Address Validation API im Vergleich zur Geocoding API veranschaulicht werden.

Beispiel für eine ungültige Adresse

1 Fake St, Mountain View, CA 94043, USA

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

Die Fake St ist in Mountain View, Kalifornien, nicht vorhanden und 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 Eigenschaft, 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 eine Straße diesen Namen als Namen haben könnte, aber nicht mit den unterstützenden Adressdaten abgeglichen werden kann.

Durch die Verwendung des API-Ergebnisses als Feedback kann daraus abgeleitet werden, dass die Straßenkomponente dieser Eingabe (Fake St) ein Fehler ist.

Wenn Sie dieselbe Adresse mit der Geocoding API verwenden, kann eine Übereinstimmung mit „Kalifornien“ gefunden werden, wie im Screenshot des Geocoding-Tools zu sehen ist. Hier können Sie es ausprobieren.

alt_text

Das Ergebnis ist jedoch eine Geocodierung des gesamten Zustands mit minimalem Feedback dazu, welche Komponenten in der Eingabe möglicherweise fehlerhaft waren.

Beispiel für 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 wurden:

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

Die Address Validation API gibt ein Flag zurück, um anzuzeigen, dass das Feld korrigiert wurde. Für dieses Flag könnte Geschäftslogik implementiert werden, um die Korrektur noch einmal mit dem Datenanbieter zu überprüfen, z. B. mit einem Kunden an einem E-Commerce-Bezahlvorgang.

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 diese beiden 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 erfolgreich beheben und gibt als 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 richtig, mit Ausnahme der Wohnungsnummer (Ste 123), die im Gebäude nicht vorhanden ist.

Die Address Validation API kann die Adresse der PREMISE (111 8th Ave) validieren und einige Metadaten zur Unterkunft bereitstellen, z. B., dass es sich um eine kommerzielle Unterkunft handelt

Gebäude:

"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

Überblick

Wenn Sie das Geocoding API verwenden, enthält das Geocoding-Ergebnis verschiedene Hinweise in der Antwort, die zum Verständnis der Details der angegebenen Adresse verwendet werden können.

Die Funktionsweise der Geocoding API besteht darin, dass 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 die folgende Place_id für diese Postleitzahl 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"
           ]

Die Geocoding API kann überprü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 wird, gibt die API Folgendes zurück:

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

Wenn Sie eine Anfrage nur mit der Adresse ohne Hausnummer stellen, wird ein Ergebnis im Formular zurückgegeben:

"types": [
  "route"
]

Das bedeutet, dass die Geocoding API die Hausnummer nicht finden konnte und keine Übereinstimmung gefunden hat.

Hinweis:Wenn Sie wissen möchten, ob eine Adresse vorhanden ist, prüfen Sie, ob Parameter (z. B. types, partial_match, results, status) in der Geocoding API-Antwort) festgelegt sind. 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.

Sie können die oben beschriebenen Methoden verwenden, um die Zuverlässigkeit der Adressgenauigkeit allein aufgrund einer Geocoding API-Antwort zu erhöhen. Im Gegensatz zu einem Address Validation API-Ergebnis gibt die Geocoding API jedoch kein exaktes Feedback zurück, um die Ergebnisgenauigkeit zu bestimmen.

Standorttyp

Damit Sie diesen Abschnitt richtig verstehen, sollten Sie sich mit den verschiedenen Standorttypen, die von einer Geocoding API-Antwort zurückgegeben werden könnten, vertraut machen:

  • 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 Näherung darstellt (normalerweise auf einer Straße), die zwischen zwei präzise lokalisierten 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 einer Polylinie (z. B. einer Straße) oder eines Polygons (einer Region) ist.
  • APPROXIMATE gibt an, dass das zurückgegebene Ergebnis nichts der oben Genannten ist.

Wenn eine Geocoding API als location_type den Wert ROOFTOP oder RANGE_INTERPOLATED zurückgibt, bedeutet dies nicht unbedingt, dass die Adresse existiert. Wenn eine Geocoding API eine Antwort zurückgibt, bei der das Flag partial_match auf true gesetzt ist, ist es möglicherweise trotzdem das richtige Ergebnis.

Diese Art falscher Übereinstimmung ist ein sehr schwieriges Problem, das mit der Geocoding API zu lösen ist. Sie können zumindest eine grundlegende Validierung der Nachbearbeitung für das Land und den Ort der Anfrage / Antwort implementieren. Noch besser ist es, wenn Sie die tatsächlichen Adressen auf Rechtschreibfehler und/oder unvollständige Adressen vergleichen.

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

Teilweise Übereinstimmung und falsche Übereinstimmung

Wenn es sich bei einer Adresse um eine teilweise Übereinstimmung handelt, 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, wenn 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 abgeglichen werden konnte.

Sie sollten die ursprüngliche Anfrage nach einer unvollständigen Adresse prüfen. Teilweise Übereinstimmungen treten am häufigsten bei Adressen auf, die nicht innerhalb des in der Anfrage angegebenen Orts vorhanden sind. Teilübereinstimmungen können auch zurückgegeben werden, wenn eine Anforderung mit mehr als einem Standort am selben Ort übereinstimmt.

Beispiel: „21 Henr St, Bristol, UK“ gibt eine teilweise Übereinstimmung für die Henry Street und die Henrietta Street zurück. Wenn eine Anfrage eine Adresskomponente mit Tippfehler enthält, schlägt die Geocoding API möglicherweise eine alternative Adresse vor. Vorschläge, die auf diese Weise ausgelöst werden, 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 exakter Standort vorhanden sind.

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

Wenn Sie in der Antwort auf diese Indikatoren stoßen, markieren Sie die eingegebene Adresse als ungültig und versuchen Sie, sie auf andere Weise noch einmal zu bestätigen.

Hinweis: Dies ist ein weiteres Beispiel, bei dem Sie mit der Address Validation API direktes Feedback erhalten, wenn keine Adresse vorhanden ist.

Informationen zur Address Validation API-Antwort

Es gibt bereits eine sehr gute Dokumentation dazu, wie die Antworten der Address Validation API zu verstehen sind, sodass wir hier nicht weiter ins Detail gehen können.

Best Practices

Geografie angeben

Beim Aufrufen der Address Validation API oder der Geocoding API empfiehlt es sich, die geografische Suche nach dieser Adresse einzuschränken. Die beiden APIs implementieren dies auf zwei verschiedene Arten:

  • Geocoding API – Gewichtung nach Region

    Wenn Sie wissen, dass die Geocodes innerhalb eines bestimmten Landes liegen werden, erhalten Sie viel bessere Ergebnisse, wenn Sie die Gewichtung nach Region verwenden. Wenn Sie beispielsweise in Kanada Geocodierungen durchführen, empfehlen wir, &region=ca zu Ihren Anfragen hinzuzufügen, um die Gewichtung auf Kanada zu gewichten. Bei der Gewichtung nach Region werden nur Ergebnisse innerhalb dieser Region bevorzugt. Außerhalb dieser Region können Sie weiterhin Ergebnisse erhalten.

  • Address Validation API – Regionscode

    Auf ähnliche Weise liefert die Address Validation API genauere Ergebnisse, wenn in der Anfrage mit dem Feld regionCode ein ISO2-Code übergeben wird.

Orts-IDs speichern

Wenn Sie Informationen zum Standort der Google Maps Platform für zukünftige Anfragen speichern möchten, können Sie die Orts-ID unbegrenzt in Ihrer Datenbank als Attribut des Standorts speichern. Für jede Orts-ID sollten Sie 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 die aktuellsten Informationen haben, sollten Sie alle 12 Monate Orts-IDs aktualisieren. Verwenden Sie dazu eine Place Details-Anfrage mit dem Parameter place_id.

Hinweis: Es empfiehlt sich, auch den Leitfaden mit Best Practices für die Geocodierung zu lesen.

Fazit

In diesem Dokument werden die Hauptunterschiede 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 in Betracht ziehen sollten:

  • Eine genaue Postanschrift ist erforderlich, insbesondere aus Gründen der Zustellbarkeit.
  • Die Eingabedaten sind bekanntermaßen von schlechter Qualität. Die Address Validation API ist bei Eingabefehlern weniger wichtig, hebt nicht überprüfbare Adresskomponenten hervor und nimmt Korrekturen an den Eingabedaten vor.
  • Für eine Adresse sind weitere Informationen erforderlich, z. B. eine private oder gewerbliche Adresse (in ausgewählten Regionen verfügbar).

Nächste Schritte

Laden Sie das Whitepaper Bezahl, Lieferung und Abläufe mit zuverlässigen Adressen verbessern herunter und sehen Sie sich das Webinar Bezahlvorgang, Zustellung und Abläufe mit Address Validation verbessern an.

Weitere Informationen:

Beitragende

Google verwaltet diesen Artikel. Er wurde von den folgenden Beitragenden verfasst.

Hauptautoren:

Henrik Valve | Solutions Engineer

Thomas Anglaret | Solutions Engineer

Sarthak Ganguly | Solutions Engineer