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 Unternehmen mit einer Handvoll Büros braucht nichts Aufwendiges, um die Frage „Welches Büro ist mir am nächsten?“ zu beantworten, nur eine Geokodierungsanfrage und einen kurzen Vergleich mit einer Liste, die sich selten ändert.
Ob der Besucher eine Adresse oder eine Postleitzahl eingibt, geokodieren Sie sie, um Koordinaten zu erhalten.
GET /v1/forward?q=Berlin, Germany&limit=1{
"status": "ok",
"results": [
{"formatted": "Berlin, Germany", "lat": 52.5200, "lon": 13.4050, "type": "locality", "precision": "city", "confidence": 0.85, "place_id": "bl456", "components": {"city": "Berlin", "country": "DE"}}
]
}Halten Sie die Koordinaten Ihrer Büros als kleine feste Liste in Ihrem eigenen Code oder Ihrer Konfiguration vor, da sich diese selten ändert und nicht jedes Mal eine eigene Abfrage braucht.
offices = [
{"name": "Berlin", "lat": 52.5170, "lon": 13.3888},
{"name": "Paris", "lat": 48.8566, "lon": 2.3522},
{"name": "London", "lat": 51.5074, "lon": -0.1278}
]Berechnen Sie die Entfernung von den Koordinaten des Besuchers zu jedem Büro mit der üblichen Haversine-Formel, sortieren Sie dann nach Entfernung und geben Sie den nächstgelegenen Treffer zurück.
Statt eines einfachen Textfelds kann das Standortfeld mit /v1/autocomplete hinterlegt werden, sodass der Besucher beim Tippen aus vorgeschlagenen Orten wählen kann. Das verringert die Gefahr, dass ein Tippfehler zu einem unerwarteten Geokodierungsergebnis führt. Sobald ein Vorschlag ausgewählt ist, wird seine place_id oder sein Text über denselben Ablauf der Geokodierung (Adresse zu Koordinaten) aufgelöst und fließt direkt in denselben, bereits beschriebenen Entfernungsvergleich ein.
Beachten Sie, dass die Genauigkeit im obigen Beispiel „city“ statt „house“ ist, da der Besucher nur einen Städtenamen eingegeben hat. Für eine Bürosuche ist das in Ordnung, denn das Ziel ist, aus einer Handvoll Optionen das nächstgelegene Büro auszuwählen, nicht ein bestimmtes Gebäude genau zu lokalisieren. Eine gröbere Genauigkeit braucht hier keine besondere Behandlung, wie es bei einer Lieferadresse der Fall sein könnte.
Vergessen Sie nicht, die feste Büroliste in Ihrem eigenen Code zu aktualisieren, wenn ein Büro eröffnet, schließt oder umzieht. Da die Liste in Ihrer eigenen Konfiguration liegt und nicht in der API, kann sie leicht unbemerkt veralten, Besucher stillschweigend zu einem geschlossenen Standort schicken oder einen neuen Standort bei jedem Vergleich komplett auslassen. Behandeln Sie diese Liste als Teil Ihrer regelmäßigen Inhaltsprüfung, nicht als einmaligen Einrichtungsschritt.
Ein kurzer Ortsname kann gelegentlich auf mehr als einen realen Ort passen, etwa ein Name, den sich ein Land und eine davon unabhängige Region anderswo teilen. Wenn Sie den Parameter countries übergeben, um mögliche Treffer auf die Länder zu beschränken, in denen Sie tatsächlich Büros betreiben, vermeiden Sie, dass eine solche Mehrdeutigkeit auf der völlig falschen Seite der Welt aufgelöst wird.
Wenn Sie die zwei oder drei nächstgelegenen Büros anzeigen statt nur das eine nächste, kann ein Besucher in der Nähe einer regionalen Grenze das Büro wählen, das tatsächlich zu ihm passt, etwa eines mit einer Sprache oder Zeitzone, die besser passt, auch wenn es entfernungsmäßig etwas weiter weg liegt.
Jede Suche ist eine Geokodierungsanfrage. Der Vergleich mit Ihrer Büroliste findet danach vollständig in Ihrem eigenen Code statt und erhöht die Zahl Ihrer Anfragen nicht weiter. Eine solche Seite bleibt selbst bei stetigem Traffic deutlich innerhalb der 2.500 kostenlosen Anfragen pro Tag, die in jedem Schlüssel enthalten sind.
Eine auf diese Weise gebaute Bürosuche braucht genau eine Anfrage pro Suche eines Besuchers, während die eigentliche Vergleichslogik vollständig auf Ihrer Seite liegt. Details zum Anfrageformat finden Sie in der Dokumentation zur Geokodierung (Adresse zu Koordinaten).