Como montar e calibrar uma escala de distancia em projetos GIS
A escala de distancia é aquela barra ou régua que você vê no canto de um mapa digital mostrando metros, quilômetros ou milhas. Parece bobagem, mas é uma das primeiras coisas que quebra sem ninguém perceber. Já vi gente inteira depender de dados geoespaciais com a escala errada e nem notar. O problema aparece quando o projetista exporta um shapefile ou geojson sem definir o sistema de referência corretamente, ou quando mistura camadas com SRDs diferentes e a escala passa a mostrar valores completamente fictícios.
Por que a escala de distancia falha (e como corrigir)
O passo mais simples é abrir o software, verificar o SRID da camada, e garantir que ela está em um sistema projetado apropriado. Se estiver usando QGIS, vai em Propriedades da Camada, Sistema de Referência Espacial, e coloca algo como EPSG:32723 (UTM zona 23S) se for trabalhar com distâncias lineares no Brasil. Dados geograficos (lat/lon, EPSG:4326) não dão escala de distancia confiável para medições. O software mostra números, mas eles são angulares, não lineares. Isso engana muita gente. Na prática, eu trabalho com uma planilha de medições de corredores ecológicos no Cerrado onde os dados vieram empacotados sem metadados. A escala de distancia aparecia correta na interface, mas quando eu cross-checkei com coordenadas conhecidas de pontos de campo, a diferença era de quase 18%. A causa: a camada tinha sido reprojecta para UTM na hora da exportação, mas o atributo SRID não foi atualizado no arquivo .prj. O QGIS exibiu a escala baseada na nova projeção, mas os vértices aindaRespondiam às coordenadas originais mal transformadas. A correção foi refazer a reprojeção com a ferramenta Save As marcada a opção "Reproject to source CRS", gerando um novo shapefile com o .prj coerente. Depois disso, a escala de distancia bateu com as medições de campo.
Outro detalhe que pouca gente leva a sério: a escala de distancia não é fixa em mapas interativos. Em sistemas web com tiles, a barra de escala precisa ser recalculada no client-side a cada zoom, porque a projeção Web Mercator (EPSG:3857) distorce comprimentos de forma não linear conforme a latitude. Se o desenvolvedor deixou a barra fixa, os valores errados persistem enquanto o usuário navega. Uma solução caseira que uso é rodar um script Python com PyQGIS que recalcula o comprimento da barra a cada evento de zoom, considerando a latitude central do viewport atual e o Fator de Escala do Meridiano.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Passo a passo rápido para uma escala confiável
Verifique o CRS da camada. Confirme que é um sistema projetado com unidade em metros. Se for lat/lon, reprojet antes de qualquer coisa. Depois, no QGIS vá em Configurações > Opções > Geral e defina o Sistema de Referência de Coordenadas padrão como o mesmo da sua camada. Isso evita que a escala seja calculada com base em outra coisa. Se estiver no ArcGIS, o procedimento é semelhante: Properties > Source > Spatial Reference, e garanta que o dataset tem definição correta. Nunca confie em dados abertos sem verificar isso primeiro. Para visualizar a escala, adicione uma North Arrow e uma escala gráfica pelas propriedades do layout de impressão. A escala de distancia impressa no PDF ou SVG sai fixa, o que é útil para documentação, mas inútil para análise interativa. Se o objetivo é usar a escala para medir áreas ou distâncias, o certo é trabalhar na tela, não no layout. Use a régua de medição com a unidade configurada no projeto, não no padrão do sistema operacional.
Pegadinhas que custam tempo
Distsintos softwares tratam a escala de distancia de formas diferentes. No QGIS, se o projeto não tem CRS definido, a barra usa graus. No ArcGIS Pro, o comportamento varia conforme a versão e o template usado. Eu já perdi umas três horas num projeto porque a escala de distancia mostrava metros, mas o geoprocessing de buffer estava sendo feito em unidades angulares por causa de uma configuração oculta de contexto de execução. A mensagem de erro só apareceu depois de rodar a operação, quando o buffer resultou com raios absurdos. Um segundo problema comum é a conversão automática entre sistemas ao importar KML ou GeoRSS. Esses formatos muitas vezes trazem EPSG:4326 embutido, e o usuário, achando que está tudo certo, pula a etapa de reprojeção. A escala de distancia fica visualmente bonita, mas numericamente errada. A dica é sempre rodar uma conferência rápida: pegue dois pontos com coordenadas conhecidas, meça a distância no software, e compare com o valor real. Se a divergência for maior que 0,5%, algo está errado no CRS ou na reprojeção.
Alternativas quando a escala de distancia não é suficiente
Se o projeto exige medições de alta precisão em grandes extensões, sistemas projetados locais (como datum surveys estaduais) entregam resultados muito melhores que UTM genérico. No Brasil, o SIRGAS 2000 em zona UTM é o padrão, mas para obras lineares curtas, como dutos ou estradas, alguns estados mantêm sistemas próprios com menor distorção. A escala de distancia nesse caso segue o mesmo princípio, mas a acurácia melhora porque a projeção local preserva mais fielmente as distâncias na região de interesse. Também vale mencionar que, em ambientes puramente web sem acesso a bibliotecas de CRS, a alternativa mais segura é calcular distâncias diretamente no backend com uma biblioteca como Proj4js ou s2geometry, usando elipsoide WGS84, e mostrar o resultado como texto ao usuário em vez de depender da barra gráfica. É menos elegante, mas elimina a ambiguidade da escala de distancia em páginas que não controlam o projeto espacial corretamente.
No fim das contas, a escala de distancia funciona quando o fundamento espacial está certo. Se o CRS é duvidoso, nenhum ajuste visual resolve. Verifique, reprojet, confere com pontos de controle e só então confia nos números que aparecem na tela.
