Eine regionale Lebensmittelkette eröffnete ein zweites Lager und brauchte eine Antwort auf eine einfache Frage, bevor sie Lieferung am selben Tag versprechen konnte: Welche Kunden ließen sich vom neuen Gebäude aus tatsächlich mit einer vertretbaren Fahrzeit erreichen, und welche wurden weiterhin besser vom ursprünglichen Standort beliefert?
Der erste Versuch bestand darin, diese Grenze von Hand zu ziehen, mit einem Zirkel und einer geschätzten Straßenentfernung, und das ergab eine Lieferzone, die vernünftig aussah und schlecht funktionierte. Manche Adressen innerhalb des Kreises lagen auf der einzigen Straße, die zu ihnen führte, vierzig Minuten entfernt. Andere knapp außerhalb lagen näher, als die Karte vermuten ließ.
Der bessere Ansatz beginnt damit, Adressen in Koordinaten umzuwandeln. Ein Aufruf von /v1/forward nimmt eine Adresse entgegen und liefert einen Treffer mit Feldern für Breiten- und Längengrad, also genau die strukturierte Ortsangabe, die eine Entfernungsberechnung braucht, statt eines Straßennamens, den ein Routing-Tool erst erraten muss. Die Lageradresse wird einmal geokodiert. Jede Bestelladresse in der Kundenliste wird im selben Batch geokodiert, da bei einer Sammelanfrage jede Adresse als ein abgerechneter Posten zählt, statt pro Aufruf zu berechnen.
Mit Koordinaten an beiden Enden wird die Luftlinienentfernung vom Lager zu jedem Kunden zu einer einfachen Berechnung, die das eigene System des Händlers ausführen kann. Die Zonen waren kein handgezeichneter Kreis mehr, sondern eine Grenze, die aus den tatsächlich belieferten Orten gebildet und automatisch aktualisiert wurde, sobald eine neue Kundenadresse hinzukam. Als der effektive Radius des Lagers schrumpfen musste, weil die Lieferzeiten sich verschlechterten, ließ sich die Grenze aus denselben Daten neu ziehen, statt nach Augenmaß.
Auch die umgekehrte Richtung spielte eine Rolle. Der Kundenservice hatte gelegentlich nur ein Koordinatenpaar aus einer Liefer-App, keine saubere Straßenadresse, und musste wissen, zu welcher Zone und welcher Filiale dieser Punkt gehörte. /v1/reverse nimmt ein Koordinatenpaar entgegen und liefert die Adressbestandteile für diesen Ort, sodass aus einer Stecknadel auf der Karte wieder etwas wird, das eine Routing-Tabelle im Lager verwenden kann.
Für nichts davon musste der Händler eine Kartenplattform aufbauen oder lizenzieren. Die Geokodierung war das einzige fehlende Teil, und sie ließ sich an die Logistiksoftware anbinden, die das Unternehmen bereits intern betrieb. Als das neue Lager eröffnete, wurden einige tausend Adressen neu geokodiert, danach jeden Tag ein kleinerer Strom neuer Bestellungen, bequem innerhalb des kostenlosen Tageskontingents, das die meisten Betriebe dieser Größe nutzen, mit Spielraum für Prepaid-Guthaben, falls das Bestellvolumen steigt.
Die Erkenntnis gilt über Lebensmittellieferungen hinaus. Jedes Unternehmen, das eine Servicegrenze um einen physischen Standort zieht, ob Lager, Reparaturstützpunkt oder Montageteam mit Einsatz am selben Tag, braucht dieselben zwei Dinge: eine zuverlässige Möglichkeit, eine Adresse in eine Koordinate umzuwandeln, und eine zuverlässige Möglichkeit, eine Koordinate wieder in eine Adresse umzuwandeln, wenn die Daten aus der anderen Richtung kommen. Beides gibt es mit demselben Schlüssel.
Anfrage- und Antwortformate beider Endpunkte sind unter /docs/forward-geocoding/ und /docs/reverse-geocoding/ dokumentiert.