Une chaîne d'épiceries régionale a ouvert un second entrepôt et devait répondre à une question simple avant de pouvoir promettre la livraison le jour même : quels clients pouvaient réellement être desservis depuis le nouveau bâtiment en un temps de trajet raisonnable, et lesquels restaient mieux servis par le site d'origine.
Tracer cette limite à la main, avec un compas et une estimation de la distance routière, a été la première tentative, et elle a produit une zone de livraison qui semblait raisonnable mais fonctionnait mal. Certaines adresses à l'intérieur du cercle se trouvaient à quarante minutes par la seule route qui les desservait. D'autres, juste à l'extérieur, étaient plus proches que la carte ne le laissait penser.
La meilleure approche commence par la conversion des adresses en coordonnées. Un appel à /v1/forward prend une adresse et renvoie une correspondance, avec notamment un champ latitude et longitude, le type de localisation structurée dont un calcul de distance a besoin, plutôt qu'un nom de rue qu'un outil d'itinéraire doit interpréter. L'adresse de l'entrepôt est géocodée une seule fois. Chaque adresse de commande de la liste de clients est géocodée dans le même lot, puisqu'une requête groupée compte chaque adresse comme un élément facturé au lieu de facturer par appel.
Avec des coordonnées aux deux extrémités, la distance à vol d'oiseau entre l'entrepôt et chaque client devient un simple calcul que le propre système de l'épicier peut effectuer. Les zones ont cessé d'être un cercle tracé à la main pour devenir une limite construite à partir des emplacements réellement desservis, mise à jour automatiquement à chaque nouvelle adresse client. Lorsque le rayon d'action effectif de l'entrepôt a dû être réduit parce que les délais de livraison s'allongeaient, la limite a pu être redessinée à partir des mêmes données au lieu d'être redessinée à l'œil.
Le sens inverse comptait aussi. Le service client ne disposait parfois que de coordonnées issues d'une application de livraison, sans adresse postale propre, et devait savoir à quelle zone et à quel magasin ce point appartenait. /v1/reverse prend une paire de coordonnées et renvoie les composantes de l'adresse de cet emplacement, transformant une épingle sur une carte en une information exploitable par une table d'acheminement d'entrepôt.
Rien de tout cela n'a obligé l'épicier à construire une plateforme cartographique ou à en acquérir une licence. L'étape de géocodage était la seule pièce manquante, et elle s'est intégrée au logiciel logistique que l'entreprise exploitait déjà en interne. Quelques milliers d'adresses ont été géocodées à nouveau à l'ouverture du nouvel entrepôt, puis un flux plus modeste de nouvelles commandes a été géocodé chaque jour, largement dans le quota gratuit quotidien qu'utilisent la plupart des activités de cette taille, avec de la marge pour passer au crédit prépayé si le volume de commandes augmentait.
La leçon dépasse la livraison d'épicerie. Toute entreprise qui trace une zone de service autour d'un lieu physique, qu'il s'agisse d'un entrepôt, d'un atelier de réparation ou d'une équipe d'installation le jour même, a besoin des deux mêmes choses : un moyen fiable de convertir une adresse en coordonnées, et un moyen fiable de reconvertir des coordonnées en adresse lorsque les données arrivent dans l'autre sens. Les deux s'obtiennent avec la même clé.
Les formats de requête et de réponse des deux endpoints sont documentés sur /docs/forward-geocoding/ et /docs/reverse-geocoding/.