Una cadena regional de supermercados abrió un segundo almacén y necesitaba responder a una pregunta sencilla antes de poder prometer entregas en el mismo día: a qué clientes se podía llegar realmente desde el nuevo edificio en un trayecto razonable en coche y a cuáles seguía atendiendo mejor el local original.
Trazar esa línea a mano, con un compás y una estimación de la distancia por carretera, fue el primer intento, y produjo una zona de entrega que parecía razonable y funcionaba mal. Algunas direcciones dentro del círculo estaban a cuarenta minutos por la única carretera que llegaba a ellas. Otras, justo fuera, estaban más cerca de lo que sugería el mapa.
El mejor enfoque empieza por convertir las direcciones en coordenadas. Una llamada a /v1/forward recibe una dirección y devuelve una coincidencia, con un campo de latitud y longitud, el tipo de ubicación estructurada que necesita un cálculo de distancias en lugar de un nombre de calle que una herramienta de rutas tiene que adivinar. La dirección del almacén se geocodifica una vez. Todas las direcciones de pedido de la lista de clientes se geocodifican en el mismo lote, ya que una solicitud masiva cuenta cada dirección como un elemento facturado en lugar de cobrar por llamada.
Con coordenadas en ambos extremos, la distancia en línea recta desde el almacén hasta cada cliente se convierte en un cálculo sencillo que el propio sistema de la cadena puede ejecutar. Las zonas dejaron de ser un círculo dibujado a mano y pasaron a ser un límite construido a partir de las ubicaciones reales atendidas, actualizado automáticamente cada vez que llegaba una nueva dirección de cliente. Cuando el alcance efectivo del almacén tuvo que reducirse porque los tiempos de entrega se alargaban, el límite pudo redibujarse a partir de los mismos datos en lugar de a ojo.
La dirección inversa también importaba. Atención al cliente a veces solo tenía un par de coordenadas de una app de reparto, sin una dirección postal limpia, y necesitaba saber a qué zona y a qué tienda pertenecía ese punto. /v1/reverse recibe un par de coordenadas y devuelve los componentes de la dirección de esa ubicación, convirtiendo un marcador en un mapa en algo que una tabla de rutas del almacén podía usar.
Nada de esto obligó a la cadena a construir o licenciar una plataforma de mapas. El paso de geocodificación era la única pieza que faltaba, y se conectó al software de logística que la empresa ya usaba internamente. Unos pocos miles de direcciones se volvieron a geocodificar cuando abrió el nuevo almacén, y después un goteo menor de pedidos nuevos se geocodificaba cada día, holgadamente dentro de la cuota diaria gratuita que usan la mayoría de las operaciones de este tamaño, con margen para pasar al crédito prepago si el volumen de pedidos crecía.
La lección va más allá del reparto de supermercado. Cualquier negocio que trace un límite de servicio alrededor de una ubicación física, ya sea un almacén, un taller de reparaciones o un equipo de instalación en el mismo día, necesita las mismas dos cosas: una forma fiable de convertir una dirección en una coordenada y una forma fiable de convertir una coordenada de nuevo en una dirección cuando los datos llegan en sentido contrario. Ambas salen de la misma clave.
Los formatos de solicitud y respuesta de ambos endpoints están documentados en /docs/forward-geocoding/ y /docs/reverse-geocoding/.