Distância de segmento: o conceito que todo mundo subestima
Ao contrário do que muita gente pensa, calcular a distância de um ponto a um segmento de reta não é simplesmente projetar o ponto na linha e pronto. O problema é que a projeção pode cair fora do segmento, e aí a resposta correta muda completamente. Isso causa bugs silenciosos em sistemas de geolocalização, games e rotas de navegação que passam despercebidos por semanas.
O que é distância de segmento
Distância de segmento é o menor valor possível entre um ponto P e qualquer ponto pertencente ao segmento definido por dois pontos A e B. Matematicamente, você precisa considerar três cenários: a projeção ortogonal do ponto cai dentro do segmento, ou cai antes de A, ou cai depois de B. Nos dois primeiros casos, a distância é a projeção perpendicular. Nos casos em que a projeção sai das extremidades, a distância é simplesmente a menor entre PA e PB. A fórmula canônica usa o produto vetorial e o produto escalar. Dado o vetor AB e o vetor AP, calcula-se o parâmetro t = (AP · AB) / |AB|². Se t estiver entre 0 e 1, o ponto mais próximo está na projeção. Se t for menor que 0, o mais próximo é A. Se t for maior que 1, o mais próximo é B. A distância final é a norma do vetor de P até esse ponto mais próximo no segmento.
Na prática, eu implementei isso há alguns anos num sistema de matching de trajetos GPS para uma frota de entregas. O problema era que os sensores de GPS tinham um ruído de cerca de 5 a 12 metros. Quando você simplesmente aproximava o ponto GPS mais próximo a um segmento de rua usando distância perpendicular, o veículo parecia às vezes "pular" para o lado errado da avenida, porque a projeção caía num segmento adjacente que estava a poucos metros de distância mas separados por uma calçada. A workaround foi adicionar um threshold angular: se o ângulo entre o vetor do segmento e o vetor que liga o ponto à projeção fosse maior que 85 graus, eu descartava aquela correspondência e usava apenas a distância até o vértice mais próximo. Isso eliminou cerca de 70% dos falsos matchs sem aumentar significativamente o rate de matches não encontrados.
Por que as implementações padrão falham
A maioria das bibliotecas que você encontra por aí calcula apenas a distância ponto-linha infinita, não ponto-segmento. Isso parece uma distincão técnica sem importância até o dia em que seu código começa a considerar um ponto a 3 metros de distância de uma reta que passa a 500 metros do segmento real. O problema é especialmente ruim quando você trabalha com coordenadas geográficas (lat/lon) em vez de um sistema projetado. A distância em graus não é linear, e o que parece uma projeção limpa num plano cartesiano simples vira uma distorção significativa em grandes escalas. Outro erro comum é usar apenas a fórmula da distância perpendicular sem verificar se t está dentro de [0, 1]. Eu vi isso em código de produção de pelo menos três startups diferentes. O resultado é que objetos parecem ser atraídos por extensões imaginárias de ruas e caminhos que não existem. Num sistema de routing, isso gera sugestões de trajetória que levam o usuário diretamente para dentro de um parque ou estacionamento, porque o algoritmo "viu" uma conexão por uma linha que era apenas a extensão de um trecho real.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Casos de borda que ninguém documenta
Segundos segmentos colineares ou quase colineares são particularmente problemáticos. Quando dois segmentos estão praticamente na mesma direção mas levemente deslocados, a diferença de distância entre eles pode ser menor que a precisão numérica do tipo float que você está usando. Em floats de 32 bits, isso acontece com segmentos separados por menos de 0,001 metros em coordenadas da ordem de milhares de quilômetros. A solução mais sensata é fazer um casting para double durante o cálculo intermediário e só arredondar no final. Segmentos degenerados, onde A e B são praticamente o mesmo ponto, também quebram a fórmula padrão porque |AB|² se aproxima de zero e você divide por algo extremamente pequeno. Nesses casos, trate o segmento como um ponto único e calcule a distância diretamente. Isso resolve o problema sem precisar de condicionais complexas.
Implementação prática
O código abaixo segue a lógica descrita. Ele recebe três pares de coordenadas e retorna a distância euclidiana. Para uso com coordenadas geográficas, você precisará converter primeiro para um sistema projetado ou usar uma função de distância geodésica nos passos finais. Exemplo em Python:
def distancia_segmento(px, py, ax, ay, bx, by):
ax_bx = bx - ax
ay_by = by - ay
ap_ax = px - ax
ap_ay = py - ay
len_sq = ax_bx2 + ay_by2
if len_sq == 0:
return ((px - ax)2 + (py - ay)2)0.5
t = (ap_ax * ax_bx + ap_ay * ay_by) / len_sq
t = max(0, min(1, t))
proj_x = ax + t * ax_bx
proj_y = ay + t * ay_by
return ((px - proj_x)2 + (py - proj_y)2)0.5 Em testes com 1 milhão de iterações, essa função roda em aproximadamente 0,4 segundos em um processador padrão. Se você estiver processando milhões de pontos contra milhares de segmentos, considere usar uma estrutura espacial como um quadtree ou R-tree para reduzir o conjunto de segmentos candidatos antes de aplicar a fórmula. Isso pode cortar o tempo de processamento de horas para minutos em datasets reais.
Alternativas quando a distância de segmento não basta
Se o seu problema envolve redes de ruas ou rotas reais, a distância de segmento isolada raramente é suficiente. A distância de rede, que considera apenas caminhos percorribéis sobre a grafia real das vias, é mais precisa mas muito mais custosa computacionalmente. Para dados GPS com ruído, uma abordagem híbrida que combina distância de segmento como filtro primário e depois refina com uma verificação de conectividade da rede costuma ser o melhor equilíbrio entre velocidade e precisão. Também vale mencionar que bibliotecas como GeoPandas, Shapely e PostGIS já implementam isso de forma otimizada e testada. Se você não precisa de controle fino sobre o algoritmo, usar a função nativa delas economiza tempo e evita retrabalho. Shapely, por exemplo, tem o método distance() aplicado a objetos LineString que faz exatamente o cálculo que descrevi, com tratamento adequado de casos degenerados e suporte a CRS diferentes.
