Ein kleiner Fahrdienst, der im Rahmen einer Vereinbarung für einen Campus und die umliegenden Wohnviertel betrieben wurde, hatte eine feste Regel, die er nicht brechen durfte: Abholungen und Absetzungen mussten innerhalb eines festgelegten Betriebsgebiets bleiben, das mit der örtlichen Behörde vereinbart war, die den Dienst überhaupt erst genehmigt hatte. Fahrer, die Fahrgäste außerhalb dieser Grenze absetzten, selbst nur ein kleines Stück, gefährdeten die gesamte Betriebsvereinbarung, und sich darauf zu verlassen, dass Fahrer eine Grenze auf einer Papierkarte nach Augenmaß einschätzen, konnte nie zuverlässig sein.
Der Dienst baute die Prüfung um Koordinaten statt um Adressen herum auf, da die Abholmarkierung eines Fahrgasts bereits eine auf einer Karte in der App gesetzte Koordinate war und kein eingetippter Text. Für diese rohe Koordinate nutzte der Dienst /v1/reverse, um eine lesbare Adresse und die zugehörige Verwaltungseinheit zu erhalten. Das war nützlich, um dem Fahrgast einen bestätigten Abholort anzuzeigen, und für Mitarbeiter, die eine markierte Fahrt nachträglich prüften, denn eine Koordinate allein ist für einen Menschen schwer schnell zu überprüfen, eine aufgelöste Adresse dagegen nicht.
Die eigentliche Grenzprüfung war ein einfacher geometrischer Vergleich, den das eigene Backend der App durchführte, zwischen der Koordinate des Fahrgasts und dem Polygon, das das genehmigte Betriebsgebiet beschreibt, eine Berechnung, für die kein externer Dienst nötig ist, sobald man eine zu prüfende Koordinate hat. Die Standort-Endpunkte kamen ins Spiel, um sicherzustellen, dass diese Prüfung immer eine echte Koordinate zur Verfügung hatte: Was ein Fahrgast auf seiner Seite der App eingegeben hatte, wenn er eine Adresse eintippte, statt eine Markierung zu setzen, wurde zuerst über /v1/forward in eine Koordinate umgewandelt.
Eine Abholanfrage innerhalb der Grenze wurde normal bearbeitet. Eine, die außerhalb lag, selbst nur geringfügig, wurde abgelehnt, bevor überhaupt ein Fahrer losgeschickt wurde, mit einer Nachricht, dass der Dienst außerhalb seiner genehmigten Zone rechtlich nicht tätig sein durfte, statt dass ein Fahrer ankam und dann feststellte, dass er die Abholung nicht durchführen durfte. Die frühe Ablehnung sparte sowohl dem Fahrer als auch dem Fahrgast Zeit und sorgte für eine saubere Dokumentation, die zeigte, dass der Dienst seine eigene Grenze aktiv durchsetzte, statt Verstöße erst im Nachhinein zu entdecken.
Der Dienst nutzte die per Reverse-Geokodierung ermittelte Adresse auch bei markierten oder strittigen Fahrten, denn eine kleine Zahl von Abholungen lag direkt am Rand der Grenze und erforderte eine menschliche Bestätigung, ob eine Anfrage tatsächlich innerhalb oder außerhalb des genehmigten Gebiets lag. Das ließ sich anhand einer aufgelösten Straßenadresse und eines Viertelnamens viel leichter beurteilen als anhand eines rohen Koordinatenpaars in einem internen Dashboard.
Diese Art der Grenzdurchsetzung ist kein kompliziertes technisches Problem, sobald die Standortbausteine vorhanden sind. Der schwierige Teil war sicherzustellen, dass jede Abholung und Absetzung, egal wie sie in die App eingegeben wurde, immer als Koordinate endete, die die geometrische Prüfung des Backends tatsächlich verwenden konnte, und das übernahmen /v1/forward und /v1/reverse im Zusammenspiel, je nachdem, aus welcher Richtung die Daten kamen.
Das Volumen hing direkt mit der Zahl der Fahrten zusammen, ein oder zwei Abfragen pro Fahrt, eine Last, die für einen Dienst dieser Größe in einem einzigen begrenzten Gebiet innerhalb des kostenlosen Tageskontingents blieb. Die Dokumentation zu beiden Endpunkten finden Sie unter /docs/forward-geocoding/ und /docs/reverse-geocoding/.