Uma rede regional de supermercados abriu um segundo armazém e precisava responder a uma pergunta simples antes de poder prometer entrega no mesmo dia: quais clientes podiam de fato ser atendidos a partir do novo prédio em um tempo de trajeto razoável e quais ainda eram mais bem atendidos pelo local original.
Traçar essa linha à mão, com um compasso e um palpite sobre a distância pelas estradas, foi a primeira tentativa, e ela produziu uma zona de entrega que parecia razoável e funcionava mal. Alguns endereços dentro do círculo ficavam a quarenta minutos pela única estrada que chegava até eles. Outros, logo fora dele, estavam mais perto do que o mapa sugeria.
A abordagem melhor começa transformando endereços em coordenadas. Uma chamada a /v1/forward recebe um endereço e retorna uma correspondência, incluindo um campo de latitude e longitude, o tipo de localização estruturada de que um cálculo de distância precisa, em vez de um nome de rua que uma ferramenta de roteamento tem de adivinhar. O endereço do armazém é geocodificado uma vez. Todos os endereços de pedidos da lista de clientes são geocodificados no mesmo lote, já que uma requisição em lote conta cada endereço como um item cobrado, em vez de cobrar por chamada.
Com coordenadas nas duas pontas, a distância em linha reta do armazém até cada cliente se torna um cálculo simples que o próprio sistema do supermercado pode executar. As zonas deixaram de ser um círculo desenhado à mão e passaram a ser um limite construído a partir dos locais realmente atendidos, atualizado automaticamente sempre que chegava um novo endereço de cliente. Quando o alcance efetivo do armazém precisou diminuir porque os prazos de entrega estavam atrasando, o limite pôde ser redesenhado a partir dos mesmos dados, em vez de no olho.
A direção inversa também importava. O atendimento ao cliente às vezes tinha apenas um par de coordenadas vindo de um aplicativo de entregas, sem um endereço limpo, e precisava saber a qual zona e a qual loja aquele ponto pertencia. /v1/reverse recebe um par de coordenadas e retorna os componentes do endereço daquele local, transformando um alfinete no mapa de volta em algo que uma tabela de roteamento do armazém pudesse usar.
Nada disso exigiu que o supermercado construísse ou licenciasse uma plataforma de mapas. A etapa de geocodificação era a única peça que faltava, e ela se encaixou no software de logística que a empresa já rodava internamente. Alguns milhares de endereços foram geocodificados novamente quando o novo armazém abriu, com um fluxo menor de novos pedidos geocodificados todos os dias depois disso, com folga dentro da cota diária gratuita que a maioria das operações desse porte usa, com espaço para crescer para o crédito pré-pago se o volume de pedidos aumentasse.
A lição vale além da entrega de supermercado. Qualquer empresa que trace um limite de atendimento em torno de um local físico, seja um armazém, uma oficina de reparos ou uma equipe de instalação no mesmo dia, precisa das mesmas duas coisas: uma forma confiável de transformar um endereço em uma coordenada e uma forma confiável de transformar uma coordenada de volta em um endereço quando os dados chegam na direção oposta. As duas vêm da mesma chave.
Os formatos de requisição e resposta dos dois endpoints estão documentados em /docs/forward-geocoding/ e /docs/reverse-geocoding/.