Interseções E Suas Proximidades

Como lidar com interseções e suas proximidades em dados vetoriais

Se você já tentou processar uma rede viária inteira e depois buscar tudo que estava nos arredores de cada ponto de encontro, já deve ter percebido que o resultado não é o que parece. O problema não é a teoria. É o que acontece quando os dados entram em contato com a realidade. Vou explicar primeiro o método que eu uso, porque a definição pura raramente ajuda quem está na prática. O fluxo básico é simples: separar as geometrias de interseção, gerar um buffer ao redor delas, depois identificar os elementos que caem dentro desse raio. Parece direto até você tentar rodar em uma base com milhares de nós e ver que o tempo de processamento dobra a cada incremento.

Definição de interseções e suas proximidades

O conceito em si é trivial. Interseções são pontos ou trechos onde duas ou mais linhas se cruzam ou se conectam. Proximidade refere-se à distância linear entre esses pontos de encontro e os objetos de interesse próximos. Na teoria GIS isso aparece em muitos manuais como análise de buffer radial aplicada a nós de rede. O que os manuais não dizem é que a qualidade do resultado depende quase inteiramente de como os dados foram originados e de quão limpos os vértices estão antes de qualquer coisa. Eu trabalhei num projeto onde a municipalidade mapeava bueiros e as coordenadas dos pontos vinham de GPS campo com erro médio de doze metros. Quando gerei as interseções da rede de drenagem e apliquei um buffer de cinquenta metros para achar todos os poços de visita próximos, cerca de quinze por cento dos agrupamentos não faziam sentido geográfico. Linhas que na verdade eram paralelas e separadas por dois metros apareciam como intersecionadas por causa da distorção dos pontos de cabeceira. A solução que funcionou foi uma pré-limpeza com snap de vértices a dois metros mais uma dissolução de linhas compartilhando extremidades antes de calcular os nós de interseção de fato.

Implementação prática com PostGIS

Se o seu banco é PostgreSQL com PostGIS, você tem ferramentas suficientes sem precisar recorrer a softwares caros. O primeiro passo é garantir que suas geometrias estejam na mesma SRID e que a precisão topológica esteja resolvida. Um ST_Snap com tolerância evita a maioria dos falsos cruzamentos. Depois você extrai os nós usando ST_Node para redes complexas ou ST_Intersection entre as linhas para achar os pontos de sobreposição. Para o buffer de proximidade, ST_Buffer com resoluções de noventa segmentos já entrega suavização suficiente sem estourar a memória em bases médias. O filtro espacial em si roda rápido graças ao índice espacial. Uma consulta típica com CTEs fica mais ou menos assim: WITH intersecoes AS (SELECT (ST_DumpPoints(ST_Intersection(a.geom, b.geom))).geom AS ponto FROM rede AS a JOIN rede AS b ON ST_Intersects(a.geom, b.geom) AND a.id < b.id), proximidade AS (SELECT i.ponto, r.id AS referencia, ST_Distance(i.ponto, r.geom) AS distancia FROM intersecoes i JOIN rede r ON ST_DWithin(i.ponto, r.geom, 100)) SELECT * FROM proximidade WHERE distancia <= 100 ORDER BY distancia;

Isso devolve pares de interseção-referência com distância real em metros. O gargalo costuma ser o JOIN que gera combinações explosivas se você não usar ST_Intersects como filtro primário antes de chamar ST_Intersection. Com esse guarda-chuva eu consegui reduzir o tempo de um processamento que antes levava quatro horas para cerca de vinte minutos em uma base com aproximadamente onze mil trechos.

Pegadinhas que ninguém alerta

Uma delas é que ST_Intersection pode retornar linhas quando na verdade você quer pontos. Se duas vias colinemares se sobrepõem por trezentos metros, a interseção geométrica é um segmento, não um nó. Isso infla artificialmente a quantidade de interseções e distorce qualquer análise de proximidade subsequente. A correção é filtrar por ST_IsClosed ou exigir que o resultado tenha dimensão geométrica zero após a operação. Outro ponto cego é a tolerância de.buffer. Um buffer de cinquenta metros parece inocente até você aplicar em ruas sinuosas com curvas apertadas. Os buffers de interseções adjacentes se sobrepõem e passam a incluir áreas que não têm relação causal com o nó original. Se o objetivo é atribuir características de vizinhança a cada cruzamento, considerar a interseção dos buffers em vez da união costuma ser mais honesto. Também vale notar que essa abordagem falha de forma silenciosa quando a rede não está topologicamente integrada. Ruas que devem se conectar mas têm pequenos gaps de alguns centímetros — algo comum em shapefiles exportados de CAD — não geram interseção nenhuma. Você gasta meia tarde investigando por que um cruzamento óbvio não aparece no resultado e descobre que faltou um ST_Snap inicial com tolerância adequada. Nunca pule essa etapa só porque o visualizador mostra as linhas se tocando.

Alternativas quando o buffer tradicional não serve

Se o seu caso envolve acessibilidade real e não apenas distância euclidiana, o buffer simples é enganoso. Uma intersecação pode estar a duzentos metros em linha reta de um hospital, mas a viagem pela rede viária leva quinhentos metros de percurso efetivo. Nesse cenário um ST_DWithin com projeção de rede ou um query de custo via pgRouting entrega muito mais informação do que qualquer círculo. Eu substituí essa abordagem em um estudo de localização de pontos de coleta seletiva e o ranking das melhores interseções mudou completamente em relação à análise por buffer puro. Quando a performance é crítica e você precisa de proximidade aproximada em larga escala, considerar uma indexação por grid em vez de buffer completo também vale a pena. Uma grade de cinquenta por cinquenta metros aplicada sobre as interseções e depois cruzada com os elementos de interesse reduz drasticamente o número de comparações de geometria sem perder muito da acurácia.

Considerações finais sobre o que funciona e o que não funciona

Interseções e suas proximidades são úteis enquanto você lembra que o produto final é tão bom quanto a qualidade dos dados de entrada e a escolha certa da tolerância. O método não resolve redes mal topologizadas, não compense curvas muito fechadas que fazem buffers se fundirem de forma irreal e não substitui modelagem de rede quando a distância de percurso importa mais do que a distânciastraight-line. Se você está lidando com bases limpas e um raio de influência razoável, a abordagem por buffer com filtro espacial atende na maior parte das vezes. Caso contrário, considere sair do modelo euclidiano antes de gastar tempo ajustando parâmetros que não vão corrigir a falha de fundo do problema.