Un petit service de VTC fonctionnant dans le cadre d'un accord couvrant un campus et les quartiers environnants avait une règle stricte qu'il ne pouvait pas enfreindre : les prises en charge et les déposes devaient rester à l'intérieur d'une zone d'exploitation définie, convenue avec l'autorité locale qui avait autorisé le service au départ. Des chauffeurs qui déposaient des passagers hors de cette limite, même à faible distance, mettaient en péril tout l'accord d'exploitation, et compter sur les chauffeurs pour estimer une limite à l'œil sur une carte papier n'allait jamais être fiable.
Le service a construit la vérification autour de coordonnées plutôt que d'adresses, puisque le repère de prise en charge d'un passager était déjà une coordonnée placée sur une carte dans l'application, et non un texte saisi. Pour cette coordonnée brute, le service utilisait /v1/reverse afin d'obtenir une adresse lisible et sa zone administrative, utiles pour montrer au passager un lieu de prise en charge confirmé et pour le personnel qui examinait après coup un trajet signalé, car une coordonnée seule est difficile à vérifier rapidement pour un humain, alors qu'une adresse résolue ne l'est pas.
La vérification de la limite elle-même était une simple comparaison géométrique, effectuée par le backend de l'application, entre la coordonnée du passager et le polygone décrivant la zone d'exploitation autorisée, un calcul qui ne nécessite aucun service externe une fois que l'on dispose d'une coordonnée à tester. Les endpoints de localisation intervenaient pour garantir que ce test disposait toujours d'une vraie coordonnée, en convertissant d'abord via /v1/forward ce que le passager avait saisi de son côté dans l'application, s'il avait tapé une adresse au lieu de placer un repère.
Une demande de prise en charge située à l'intérieur de la limite suivait son cours normalement. Une demande située à l'extérieur, même légèrement, était refusée avant même l'envoi d'un chauffeur, avec un message expliquant que le service ne pouvait pas légalement opérer hors de sa zone autorisée, plutôt que de voir un chauffeur arriver et découvrir alors qu'il n'avait pas le droit d'effectuer la prise en charge. Refuser tôt faisait gagner du temps au chauffeur comme au passager, et permettait de conserver un historique clair montrant que le service faisait activement respecter sa propre limite au lieu de ne découvrir les infractions qu'après coup.
Le service utilisait aussi l'adresse issue du géocodage inverse pour les trajets signalés ou contestés, car un petit nombre de prises en charge se trouvaient pile au bord de la limite et nécessitaient qu'un humain confirme si une demande se situait réellement à l'intérieur ou à l'extérieur de la zone autorisée, ce qui est bien plus facile à juger à partir d'une adresse et d'un nom de quartier résolus qu'à partir d'une simple paire de coordonnées sur un tableau de bord interne.
Ce type de contrôle de limite n'est pas un problème technique compliqué une fois les briques de localisation en place. La difficulté consistait à s'assurer que chaque prise en charge et chaque dépose, quelle que soit la façon dont elle avait été saisie dans l'application, finissait toujours sous forme d'une coordonnée réellement utilisable par la vérification géométrique du backend, et ce rôle revenait à /v1/forward et /v1/reverse, utilisés ensemble selon le sens dans lequel arrivaient les données.
Le volume était directement lié au nombre de courses, une ou deux recherches par trajet, une charge qui restait dans le quota quotidien gratuit pour un service de cette taille opérant dans une seule zone limitée. La documentation des deux endpoints se trouve sur /docs/forward-geocoding/ et /docs/reverse-geocoding/.