Distância Entre Dois Pontos Fórmula

Como calcular a distância real quando o GPS te mente

A fórmula mais usada para isso é a raiz da soma dos quadrados das diferenças nas coordenadas. Na prática, eu comecei a usá-la em 2014 num projeto de roteirização de entregas onde a prefeitura fornecia coordenadas em WGS84 e a planilha de rotas esperava distâncias em metros. O erro que todo mundo comete na primeira vez é tratar a diferença de graus como se fosse metros. Duas coordenadas com diferença de 0,01 graus estão separadas por aproximadamente 1110 metros no eixo Y, não por 0,01. Quem não percebe isso perde um dia inteiro debugando rotas que fazem sentido visual mas são numericamente absurdas. A forma padrão, a que você vai encontrar em qualquer livro de geometria analítica, é: d = ((x - x)² + (y - y)²)

Isso funciona perfeitamente num plano cartesiano bidimensional onde as unidades são consistentes. O problema é que coordenadas geográficas não vivem num plano cartesiano. Elas vivem numa esfera (ou quasi-esfera). Aplicar a fórmula euclidiana diretamente em graus Lat/Lon dá resultados que parecem plausíveis a curtas distâncias mas que distorcem brutalmente conforme a latitude aumenta. Eu já vi engenheiros junior usarem essa versão "simplificada" num sistema de geocerca e o raio de detecção variar de 500m no equador para 80m em São Paulo porque eles não converteram nada. Para coordenadas reais, o correto é usar a fórmula de Haversine. Ela leva em conta a curvatura da Terra: a = sen²(lat/2) + cos(lat) × cos(lat) × sen²(lon/2)
d = 2 × R × atan2(a, (1-a))

Onde R é o raio da Terra, aproximadamente 6371 km. A diferença entre os valores nunca é menor que 0,5% mesmo para distâncias de poucos quilômetros perto dos polos. Num projeto meu de rastreamento de frota, a versão euclidiana em graus gerava uma variação acumulada de 12% no custo de combustível estimado ao longo de rotas de longa distância. A correção com Haversine eliminou esse erro completamente. Se você precisa de máxima precisão em escalas continentais ou transversais, o GPS e os sistemas de navegação usam a fórmula de Vincenty ou a de Karney, que modelam a Terra como um elipsoide e levam em conta o achatamento nos polos. A diferença prática entre Haversine e Vincenty para a maioria das aplicações é da ordem de milímetros para distâncias de até 100 km. Para rotas aéreas ou projetos topográficos, isso muda. Para logística urbana, não muda nada perceptível. Um detalhe que ninguém ensina e que causa problema constante: a unidade de entrada. Se você passar os graus diretamente para a função trigonométrica sem converter para radianos, o resultado será completamente errado. Em JavaScript, todas as funções seno e cosseno esperam radianos, não graus. Multiplicar por /180 antes de chamar Math.sin() parece bobo mas é o erro número um que eu vejo em código novo. Eu levei duas horas para achar esse bug numa API que eu mesmo escrevi porque o log mostrava valores "razoáveis" mas com um viés sistemático que só fazia sentido retrocedendo linha por linha.

Para quem quer algo pronto, bibliotecas como Turf.js (JavaScript), Shapely (Python), ou até a função ST_Distance do PostGIS resolvem isso internamente. A vantagem de saber a fórmula na mão é que você consegue identificar quando uma biblioteca está aplicando o modelo errado ao seu caso. Já vi projeto inteiro travado porque o serviço de geocodificação retornava coordenadas em um datum e a fórmula de distância assumia outro, sem nenhum aviso ou exceção. O cálculo rodava, o resultado era apenas meio grau errado, e ninguém percebia até o cliente reclamar.