Die Nutzung Ihres Schlüssels überwachen, bevor Sie an ein Limit stoßen
Wenn Sie Ihre Kontingent-Header laufend beobachten, wissen Sie, wann ein Limit näher rückt, lange bevor eine Anfrage tatsächlich abgelehnt wird.
Ein Freitext-Adressfeld in strukturierte Bestandteile zerlegen
Ein einzelnes Freitext-Adressfeld ist leicht zu erfassen und hinterher schwer zu verarbeiten, vor allem, sobald Sie nach Stadt filtern oder nach Region gruppieren müssen. Die Geokodierung übernimmt das Parsen für Sie als Nebeneffekt der Auflösung der Adresse in Koordinaten.
Den Freitext senden
GET /v1/forward?q=1600 Pennsylvania Avenue, Washington, DC 20500&limit=1{
"status": "ok",
"query": "1600 Pennsylvania Avenue, Washington, DC 20500",
"results": [
{
"formatted": "1600 Pennsylvania Avenue NW, Washington, DC 20500",
"lat": 38.8977,
"lon": -77.0365,
"type": "address",
"precision": "house",
"confidence": 0.97,
"place_id": "def456",
"components": {"house_number": "1600", "street": "Pennsylvania Avenue NW", "city": "Washington", "region": "DC", "postcode": "20500", "country": "US"}
}
]
}Bestandteile getrennt speichern
Sobald Sie das components-Objekt haben, schreiben Sie jedes Feld in eine eigene Datenbankspalte, statt nur die ursprüngliche Freitext-Zeichenkette zu behalten. So können Sie Kundendatensätze nach Stadt oder Region filtern, genaue regionale Berichte erstellen und prüfen, ob eine Postleitzahl und eine Stadt tatsächlich zusammengehören. Nichts davon ist mit einer einzigen unstrukturierten Zeichenkette praktikabel.
Ein zweites Beispiel: eine Adresse in einem anderen Format
Adressstrukturen sind nicht überall gleich. Eine Adresse im Vereinigten Königreich kann mit einer Grafschaft statt einer Region nach US-Muster aufgelöst werden, und ein Bestandteil wie house_number kann bei einem Gebäude mit Namen ganz fehlen. Dieselbe Art von Anfrage funktioniert unabhängig vom Land, aber die Schlüssel der Bestandteile, die Sie tatsächlich zurückbekommen, können variieren. Bauen Sie Ihr Speicherschema daher so, dass es einen fehlenden Bestandteil toleriert, statt anzunehmen, dass jedes Land jedes Mal genau dieselben Felder befüllt.
Ein häufiger Fehler, den Sie vermeiden sollten
Programmieren Sie nicht fest die Annahme ein, dass jedes Ergebnis house_number, street, city, region und postcode enthält, und behandeln Sie nicht jede Adresse, der eines davon fehlt, als Parsing-Fehler. Eine völlig gültige Adresse, besonders außerhalb eines städtischen Rasters mit Hausnummern, kann berechtigterweise mit einigen leeren Feldern zurückkommen. Eine strenge Validierung, die einen vollständigen Satz an Bestandteilen verlangt, lehnt echte Kundeneingaben ab, die der Endpunkt korrekt geparst hat.
Auch den Originaltext behalten
Speichern Sie die ursprüngliche Freitext-Eingabe zusammen mit den geparsten Bestandteilen, statt sie zu verwerfen. Wenn ein Bestandteil unvollständig zurückkommt oder ein Kunde später etwas korrigieren muss, macht der vorhandene Originaltext ein erneutes Parsen oder eine manuelle Korrektur einfach.
Mit unvollständig geparsten Adressen umgehen
Nicht jede Adresse wird mit allen Bestandteilen aufgelöst. Eine ländliche Adresse kann ohne house_number zurückkommen, und eine kleine Stadt ohne eigenen region-Wert. Behandeln Sie fehlende Bestandteile als berechtigterweise leer statt als Parsing-Fehler, und greifen Sie für die Anzeige auf die formatierte Zeichenkette zurück, wenn ein gewünschter Bestandteil nicht vorhanden ist.
Mit mehr als einem plausiblen Treffer umgehen
Wenn Sie limit über 1 anheben, erhalten Sie mehrere Kandidaten, sortiert danach, wie gut jeder zum Freitext passt. Das ist nützlich, wenn Sie dem Kunden eine kurze Auswahlliste zeigen möchten, statt stillschweigend den besten Treffer zu übernehmen. Es ist ein vernünftiger Mittelweg zwischen vollautomatischem Parsing und einem komplett manuellen Eingabeformular, besonders für Adressen, die Ihre Konfidenzschwelle sonst als unsicher markieren würde.
Was es kostet
Ein Freitextfeld auf diese Weise zu parsen kostet eine Anfrage pro Adresse, genau wie jede andere Geokodierung von Adresse zu Koordinaten. Ein Backfill-Job, der eine bestehende Tabelle mit Freitextadressen bereinigt, kann die gesamte Tabelle als Sammelanfrage durchlaufen, eine Anfrage pro Zeile.
Freitext in strukturierte Felder zu verwandeln ist ein natürlicher Nebeneffekt der Geokodierung einer Adresse, kein zusätzlicher Schritt. Die Dokumentation zur Geokodierung listet jede Komponente auf, die der Endpunkt zurückgeben kann.