Un pequeño servicio de viajes compartidos que operaba bajo un acuerdo para un campus y los barrios de alrededor tenía una regla estricta que no podía romper: las recogidas y las llegadas debían quedarse dentro de una zona de operación definida, acordada con la autoridad local que había autorizado el servicio desde el principio. Los conductores que dejaban a pasajeros fuera de ese límite, aunque fuera por poca distancia, ponían en riesgo todo el acuerdo de operación, y confiar en que los conductores calcularan a ojo un límite en un mapa de papel nunca iba a ser fiable.
El servicio construyó la comprobación en torno a coordenadas y no a direcciones, ya que el marcador de recogida de un pasajero ya era una coordenada colocada en un mapa dentro de la app, no un texto escrito. Para esa coordenada en bruto, el servicio usaba /v1/reverse para obtener una dirección legible y su división administrativa, algo útil para mostrar al pasajero una ubicación de recogida confirmada y para que el personal revisara después cualquier viaje marcado, ya que una coordenada sola es difícil de verificar rápidamente para una persona, mientras que una dirección resuelta no lo es.
La comprobación del límite en sí era una comparación geométrica sencilla, ejecutada por el propio backend de la app, entre la coordenada del pasajero y el polígono que describía la zona de operación autorizada, un cálculo que no requiere ningún servicio externo una vez que tienes una coordenada que comprobar. Los endpoints de ubicación entraban en juego para garantizar que esa comprobación siempre tuviera una coordenada real con la que trabajar, convirtiendo primero en coordenada mediante /v1/forward lo que el pasajero hubiera escrito en su lado de la app, si escribía una dirección en lugar de colocar un marcador.
Una solicitud de recogida que caía dentro del límite seguía su curso normal. Una que caía fuera, aunque fuera ligeramente, se rechazaba antes de enviar a ningún conductor, con un mensaje que explicaba que el servicio no podía operar legalmente fuera de su zona autorizada, en lugar de que un conductor llegara y descubriera entonces que no tenía permitido hacer la recogida. Rechazar pronto ahorraba tiempo al conductor y al pasajero, y mantenía un registro limpio que demostraba que el servicio hacía cumplir activamente su propio límite en lugar de descubrir las infracciones solo a posteriori.
El servicio también usaba la dirección obtenida por geocodificación inversa en los viajes marcados o en disputa, ya que un pequeño número de recogidas caían justo en el borde del límite y necesitaban que una persona confirmara si una solicitud había caído realmente dentro o fuera de la zona autorizada, algo mucho más fácil de juzgar a partir de una dirección resuelta y el nombre de un barrio que a partir de un par de coordenadas en bruto en un panel interno.
Este tipo de control de límites no es un problema técnico complicado una vez que las piezas de ubicación están en su sitio. Lo difícil era garantizar que cada recogida y cada llegada, se introdujera como se introdujera en la app, terminara siempre como una coordenada que la comprobación geométrica del backend pudiera usar de verdad, y de eso se encargaban /v1/forward y /v1/reverse trabajando juntos según la dirección de la que vinieran los datos.
El volumen dependía directamente del número de viajes, una o dos consultas por trayecto, una carga de trabajo que se mantuvo dentro de la cuota diaria gratuita para un servicio de este tamaño que operaba en una única zona limitada. La documentación de ambos endpoints está en /docs/forward-geocoding/ y /docs/reverse-geocoding/.