Como funciona o cálculo de distância entre endereços na prática
A maioria das pessoas acha que calcular distância entre dois endereços é só colocar dois CEPs num site e pronto. Não é bem assim. O resultado que você vê na tela depende de vários fatores que raramente são explicados. A gente costuma receber a distância em linha reta como se fosse uma regra, mas na realidade as rotas de carro, moto ou caminhão seguem o redes viário, e isso pode fazer uma diferença absurda dependendo da cidade.
calcular distancia entre dois endereços com precisão real
O processo básico envolve transformar cada endereço num par de coordenadas geográficas. Isso se chama geocodificação. Você envia o endereço para um serviço como Google Maps, OpenStreetMap ou Mapbox, e eles devolvem latitude e longitude. Depois você aplica um algoritmo de distância entre esses dois pontos. O problema é que existem pelo menos três formas diferentes de medir isso, e elas dão resultados bem diferentes entre si. A primeira é a distância em linha reta, chamada de distância euclidiana ou até Haversine quando se leva em conta a curvatura da Terra. A segunda é a distância rodoviária, que considera as ruas, avenidas, travessas, desvios e tudo mais que existe num mapa de rede viária. A terceira é a distância temporal, que leva em conta o tempo real de deslocamento com base no trânsito. Quando você pede para calcular distancia entre dois endereços num app qualquer, na verdade está pedindo uma coisa específica sem saber qual.
No meu caso, trabalhando com logística há anos, já perdi meia tarde entendendo por que a distância entre dois pontos num relatório internal divergia 40% do que o GPS mostrava no caminhão. O problema não era o mapa. Era que o sistema usava coordenadas de geocodificação aproximadas para endereços rurais e estradas secundárias. O endereço "Fazenda Santa Luzia, km 12" foi geocodificado num ponto que ficava a cerca de 3 quilômetros da estrada real. Ninguém verificou isso porque a API simplesmente devolveu coordenadas sem nenhum aviso de baixa precisão. A solução que funcionou foi adicionar uma validação pós-geocodificação. Você pega o ponto retornado e verifica se ele cai sobre um segmento de via conhecido. Se cair num terreno baldio ou numa área rural sem cobertura de mapa, o resultado é descartado e você refaz a busca com termos mais específicos. Eu uso rotineiramente uma combinação de requisição à API com parâmetro de resultado mais restrito e, quando necessário, faço o ajuste manual no mapa mesmo. Demora uns cinco minutos a mais por requisição, mas evita erros de 30% a 50% nos cálculos finais.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro detalhe que poucos mencionam: a própria escolha do algoritmo de distância importa muito. A fórmula de Haversine assume que a Terra é uma esfera perfeita. Ela funciona bem para curtas distâncias, digamos até 50 quilômetros. Para trajetos maiores, como entre cidades do interior de Minas Gerais e São Paulo capital, o erro acumulado fica visível. O algoritmo de Vincenty é mais preciso porque modela a Terra como um elipsóide, mas é também mais pesado computacionalmente. Em sistemas que processam milhares de requisições por minuto, isso vira um problema real de performance. Se o seu objetivo é calcular distancia entre dois endereços para uma aplicação simples, tipo um site de delivery pequeno, o Google Maps Distance Matrix API resolve. Ele retorna distância e tempo de viagem por modo de transporte. O custo é por requisição, e depois de certo volume a conta sobe rápido. Uma alternativa mais barata é usar o OSRM, que é open source e roda no seu próprio servidor. Você baixa os dados do OpenStreetMap, sobe num container e faz as requisições sem pagar por uso. O downside é que a qualidade dos dados depende puramente do que o OpenStreetMap mapeou naquela região. Em algumas áreas rurais do Nordeste, por exemplo, estradas de terra nem aparecem no mapa base, e o OSRM vai traçar rotas impossíveis.
Para quem precisa de escala, vale a pena configurar um cache local. A maioria dos endereços não muda todo dia, então guardar os pares de coordenadas e as distâncias calculadas num banco como Redis ou até PostgreSQL com uma tabela dedicada reduz drasticamente o número de chamadas à API. Eu costumo fazer isso com TTL de 7 dias. Endereços comerciais mudam com mais frequência, então nesses casos o TTL cai para 48 horas. O resultado prático é que um sistema que antes fazia 12 mil requisições diárias passou a fazer cerca de 1800, porque a maior parte das consultas se repete para os mesmos clientes fixos. Um erro comum é esquecer a questão dos fuzis horários quando se calcula distância temporal. Se seus endereços estão em estados diferentes, o tempo de viagem pode ser afetado por mudanças de fuso. Não afeta a distância em si, mas o tempo estimado que o serviço retorna pode estar fora se você não normalizar os fusos antes de fazer o cálculo. Também tem a questão dos horários de pico. O mesmo trajeto pode levar 25 minutos numa terça-feira às 10h da manhã e 1h15 numa sexta às 18h. APIs de rota normalmente permitem passar um timestamp de partida, e ignorar isso é deixar dinheiro na mesa se o seu sistema depende de estimativas realistas.
Outro ponto que vale a pena mencionar é a diferença entre distancia como crow-fly e distancia rodoviária. Um cliente meu queria entender quantas lojas estavam num raio de 5km de cada ponto de venda. Ele usou a distância em linha reta porque era mais barato processar. O resultado mostrou 30 lojas dentro do raio. Quando fiz a validação com distância rodoviária, o número real era 18. A diferença era que o rio e a ferrovia cortavam o caminho, e várias lojas que pareciam próximas no mapa na verdade exigiam um desvio de 15 quilômetros pela rodovia. Isso mudou completamente a estratégia de distribuição dele. Se você está construindo algo do zero, o stack mais viável hoje é: geocodificação com Nominatim ou Google Geocoding API, armazenamento das coordenadas com índices espaciais no PostgreSQL (PostGIS), e cálculo de rotas com OSRM ou GraphHopper rodando localmente. O custo inicial de configuração é maior, mas a longo prazo fica muito mais barato e controlável do que depender exclusivamente de APIs pagas. E se o seu cenário é apenas ocasional, tipo calcular a distância entre dois endereços uma vez por semana, simplesmente use o Google Maps mesmo. Não adianta complicar o que não precisa ser complicado.
O que mais faz errar na prática é confiar cegamente no primeiro resultado que a API devolve. Sempre faça uma conferência visual. Abra o mapa, veja onde os pontos foram aterrissados, confira se a rota faz sentido. Leva dois minutos e evita retrabalho de horas. Já vi sistema de rotas de entregas sendo montado inteiro com base em geocodificações que aterrissavam os pontos no meio de lagos porque o endereço original estava digitado errado. O cálculo de distância ficou perfeito. O problema era que o endereço não existia no mapa daquele jeito.
