Durante una emergencia meteorológica en curso, la información sobre dónde se necesita ayuda y dónde hay ayuda disponible llega rápido y sin ningún formato coherente. Un grupo regional de coordinación de ayuda se encontró recopilando ubicaciones de refugios, puntos de entrega de suministros y avisos de personas que necesitaban asistencia a partir de voluntarios que enviaban por mensaje la descripción que se les ocurría: un cruce de calles, un punto de referencia, una dirección parcial, un par de coordenadas copiado de la app de mapas del teléfono.
Nada de eso se puede usar directamente en un mapa compartido sin un formato común por debajo. El grupo de coordinación necesitaba convertir cada aviso entrante en lo mismo, un par de coordenadas, sin importar cómo llegara. Los avisos que llegaban como texto, una dirección o una descripción lo bastante parecida a una, pasaban por /v1/forward para obtener una coincidencia de ubicación. Los avisos que llegaban como coordenadas, copiadas al compartir la ubicación del teléfono, pasaban por /v1/reverse para obtener una dirección legible y una división administrativa, algo útil para mostrar a los voluntarios una descripción sencilla de la ubicación en lugar de un par de números sin más en el mapa.
Con cada aviso normalizado a una coordenada, representarlos todos juntos en un único mapa compartido se volvió sencillo y, lo que es más importante, comparable: un punto de suministro y una necesidad notificada podían medirse entre sí por distancia real, algo que importaba enormemente para dirigir a los voluntarios con eficiencia en lugar de adivinar la proximidad a partir de descripciones escritas que no tenían una relación evidente entre sí.
El grupo gestionó esto con un formulario de recepción ligero y no con nada más elaborado, ya que la prioridad durante una emergencia en curso era la rapidez y la sencillez por encima del acabado. Un voluntario que enviaba un aviso no necesitaba saber ni preocuparse por qué endpoint gestionaba su formato de entrada concreto: el formulario lo decidía según si el envío parecía texto o coordenadas, y ambos caminos terminaban en el mismo punto normalizado en el mapa compartido.
La calidad de la coincidencia importaba aquí más que en la mayoría de los demás usos de la geocodificación, ya que un aviso durante una emergencia que se resuelve en la ubicación equivocada, aunque sea por poca distancia, puede enviar ayuda al lugar equivocado justo en el momento en que más importa. El formulario de recepción del grupo mostraba directamente la confianza de la coincidencia devuelta por la llamada de geocodificación directa a quien revisaba los avisos entrantes, de modo que una coincidencia de baja confianza recibía una rápida revisión humana antes de darla por buena y actuar en consecuencia, en lugar de representarse con la misma aparente certeza que una coincidencia limpia.
Nada de esto requirió software especializado de gestión de emergencias. El grupo de coordinación ejecutó su formulario de recepción en la infraestructura que ya tenía y añadió la geocodificación como la única pieza que faltaba para que las descripciones de ubicación no estructuradas enviadas por voluntarios se convirtieran en algo que un mapa compartido pudiera mostrar y comparar de verdad.
El volumen de solicitudes durante una emergencia en curso se disparó de forma brusca y breve, el tipo de patrón para el que es difícil planificar de antemano un presupuesto fijo. La cuota diaria gratuita cubría el uso habitual de planificación y preparación entre eventos, y el crédito prepago absorbió el pico durante una respuesta real sin obligar al grupo a comprometerse con un plan continuo más grande que no necesitaría la mayor parte del año.
La documentación de ambos endpoints está en /docs/forward-geocoding/ y /docs/reverse-geocoding/.