Pendant une urgence météorologique en cours, les informations sur les endroits où l'aide est nécessaire et ceux où elle est disponible arrivent vite et sans aucun format cohérent. Un groupe régional de coordination des secours s'est retrouvé à collecter les emplacements d'abris, les points de dépôt de fournitures et les signalements de personnes ayant besoin d'aide auprès de bénévoles qui envoyaient par SMS la première description qui leur venait à l'esprit : un croisement de rues, un point de repère, une adresse partielle, des coordonnées copiées depuis l'application de cartographie d'un téléphone.
Rien de tout cela n'est directement exploitable sur une carte partagée sans un format commun sous-jacent. Le groupe de coordination avait besoin que chaque signalement entrant soit converti en une même chose, une paire de coordonnées, quelle que soit sa forme d'arrivée. Les signalements reçus sous forme de texte, une adresse ou une description suffisamment proche d'une adresse, passaient par /v1/forward pour obtenir une correspondance de lieu. Les signalements reçus sous forme de coordonnées, copiées depuis le partage de position d'un téléphone, passaient par /v1/reverse pour obtenir une adresse lisible et une zone administrative, utiles pour montrer aux bénévoles une description claire du lieu plutôt qu'une simple paire de nombres sur la carte.
Une fois chaque signalement normalisé en coordonnée, il est devenu simple de les afficher ensemble sur une même carte partagée et, surtout, de les comparer : un point de fournitures et un besoin signalé pouvaient être rapprochés selon leur distance réelle, ce qui comptait énormément pour orienter efficacement les bénévoles au lieu de deviner la proximité à partir de descriptions écrites sans lien évident entre elles.
Le groupe a fait passer tout cela par un simple formulaire de collecte plutôt que par un outil plus élaboré, car pendant une intervention en cours la priorité était la rapidité et la simplicité plutôt que la finition. Un bénévole qui envoyait un signalement n'avait pas besoin de savoir quel endpoint traitait son format de saisie, ni de s'en soucier : le formulaire en décidait selon que l'envoi ressemblait à du texte ou à des coordonnées, et les deux chemins aboutissaient au même point normalisé sur la carte partagée.
La qualité de la correspondance comptait ici davantage que dans la plupart des autres usages du géocodage, car un signalement qui, en situation d'urgence, est résolu au mauvais endroit, même à faible distance, peut envoyer de l'aide au mauvais endroit au moment précis où cela compte le plus. Le formulaire de collecte du groupe affichait directement le niveau de confiance renvoyé par l'appel de géocodage direct à la personne chargée d'examiner les signalements entrants, de sorte qu'une correspondance peu fiable faisait l'objet d'une rapide vérification humaine avant d'être prise en compte et suivie d'action, plutôt que d'être affichée avec la même apparente certitude qu'une correspondance nette.
Rien de tout cela n'a nécessité de logiciel spécialisé de gestion des urgences. Le groupe de coordination faisait fonctionner son formulaire de collecte sur une infrastructure dont il disposait déjà, en ajoutant le géocodage comme la seule pièce manquante qui permettait de transformer des descriptions de lieux non structurées, envoyées par des bénévoles, en éléments qu'une carte partagée pouvait réellement afficher et comparer.
Le volume de requêtes pendant une intervention augmentait fortement et brièvement, le genre de profil autour duquel il est difficile de prévoir un budget fixe à l'avance. Le quota quotidien gratuit couvrait l'usage ordinaire de planification et de préparation entre les événements, et le crédit prépayé absorbait le pic lors d'une intervention réelle, sans obliger le groupe à s'engager sur une offre plus importante et permanente dont il n'aurait pas besoin la majeure partie de l'année.
La documentation des deux endpoints se trouve sur /docs/forward-geocoding/ et /docs/reverse-geocoding/.