O que acontece quando você tenta colocar o mundo num mapa plano
A primeira coisa que todo mundo aprende de forma errada sobre projeções geográficas é que elas são "inferiores" à realidade. Isso é ingenuidade técnica. Não existe mapa plano perfeito. A Terra é uma esfera achatada (um esferoide, para ser preciso) e qualquer tentativa de projetá-la numa superfície bidimensional gera distorções inevitáveis. A pergunta certa não é qual projeção é a melhor, mas qual distorção você está disposto a aceitar para o seu projeto específico. O problema prático começa assim: você pega dados de satélite, um shapefile ou coordenadas GPS e tenta plotar tudo na tela. Se você simplesmente usar Web Mercator (EPSG:3857), que é o padrão do Google Maps e da maioria dos serviços de mapas online, áreas próximas aos polos vão parecer absurdamente grandes. Groenlândia do tamanho da África. Ruim se você está fazendo análise temática. Fine se você só quer mostrar rotas de navegação ou fazer um mapa-base para sobreposição visual rápida.
Como escolher projeções geográficas adequadas para o seu projeto
O processo real de escolha funciona em três etapas que rara vez são apresentadas nessa ordem. Primeiro, defina o que importa no seu mapa. Área relativa? Formas locais? Distâncias a partir de um ponto? Direções? Um único mapa raramente preserva tudo isso. Segundo, olhe para a extensão territorial dos seus dados. Mapas de um único estado brasileiro se comportam de forma muito diferente de mapas continentais ou globais. Terceiro, verifique se o sistema de coordenadas que você vai usar é compatível com as ferramentas que você tem disponíveis. Isso último é onde a maioria das pessoas trava. Para o Brasil, a projeção mais sensata costuma ser a de Lambert Conformal Conic, especificamente a SAD69 / UTM zona 22S (EPSG:29130) ou a SIRGAS2000 / UTM zona 22S (EPSG:31982). O IBGE adota o SIRGAS2000 como referenciais geodésico oficial desde 2015, e muitos datasets públicos ainda vêm em SAD69, o que cria problemas de sobreposição se você não tratar isso.
Aqui vai um exemplo concreto que me custou duas noites de trabalho. Estava processando dados de desmatamento do PRODES com coordenadas em WGS84 (EPSG:4326) e querendo calcular áreas em hectares para comparar com políticas públicas. O erro comum seria transformar direto para Web Mercator e calcular áreas a partir daí. A área distorcida por causa da projeção cilíndrica produzia valores até 40% maiores para polygons na região norte. A solução foi reprojecionar os dados para o sistema UTM local da zona correspondente a cada polygon — o que no QGIS pode ser feito de forma batch usando a ferramenta "Reproject Layer" com o parâmetro "CRS of destination layer" configurado dinamicamente por zona UTM. Isso corta o erro de área para menos de 0,1% em comparação com o cálculo geodésico direto. Não me mate dizendo que isso é inviável para grandes volumes de dados. Com uma pipeline em Python usando pyproj e geopandas, a reprojeção em lote de um shapefile de 50 mil features leva cerca de 3 a 5 minutos em uma máquina razoável. O mesmo processo no ArcMap, bem configura-do, leva o dobro do tempo e consome muito mais memória RAM.
Distorções que ninguém avisa antes de começar
Existe um conceito chamado "conformalidade" que as pessoas confundem com "precisão". Um mapa conforme preserva formas locais em pequena escala, mas isso não significa que ele seja preciso em termos absolutos. A projeção de Mercator, por exemplo, é conforme — ângulos são preservados, o que era essencial para a navegação marítima nos séculos XVII a XIX. Mas a distorção de área cresce exponencialmente com a latitude. Em 60° de latitude norte, tudo é amplificado por um fator de 4 em relação ao equador. O contraponto intuitivo é a projeção de Equal-Area, como a Mollweide ou a Albers. Essas preserva áreas, mas deforma formas. Um país como a Austrália vai parecer estranho, achatado horizontalmente. Para mapas temáticos de densidade populacional ou distribuição de recursos, Equal-Area é praticamente obrigatório. Para mapas de navegação ou rotas aéreas, conforme é mais útil.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro detalhe que os tutoriais ignoram: o datum. WGS84, SIRGAS2000, SAD69 — esses não são sinônimos. Eles representam modelos geodésicos diferentes do elipsoide terrestre. WGS84 e SIRGAS2000 são muito próximos (a diferença é da ordem de centímetros a metros, dependendo da região), mas SAD69 tem um elipsoide Clarke de 1866 que gera deslocamentos de até 100 metros em relação ao WGS84 em partes do Brasil. Se você sobrepõe camadas de datasets com datums diferentes sem fazer o transformation adequado, os feições nunca vão coincidir perfeitamente, e você vai gastar horas tentand diagnosticar o que está errado quando na verdade é só um problema de datum mal configurado. A correção é simples mas precisa ser feita de propósito. No QGIS, use o menu Settings > Options > CRS e marque "Project CRS" para o SIRGAS2000. Ao importar um dataset em SAD69, o QGIS pede automaticamente para transformar — aceite e deixe o software fazer o work. Se estiver usando Python, use pyproj.CRS.from_epsg() para definir explicitamente o source e target CRS em cada transformação, nunca confie no CRS padrão do sistema.
Ferramentas que realmente funcionam
Para quem faz isso no dia a dia, o QGIS com o plugin MMQGIS e o processamento batch do GRASS GIS cobrem 95% dos casos. O GRASS é particularmente bom para cálculos de área e perímetro porque trabalha nativamente com coordenadas geográficas e aplica correções esféricas antes de projetar. O comando v.category combinado com r.resamp.interp para reamostragem de dados raster projetados é uma combinação que pouca gente usa mas que resolve muitos problemas de precisão. Para programação, além do trio geopandas + pyproj + shapely, considere o cartopy para visualização. Ele lida automaticamente com transformações de projeção nos gráficos, o que economiza linhas de código e reduz bugs de transformação manual. A desvantagem é que cartopy é mais lento que matplotlib puro para visualizações com muitos elementos — espere cerca de 2 a 3 segundos a mais por plot quando você tem mais de 10 mil features renderizadas.
Se o seu foco é puramente análise espacial avançada, o PostGIS no PostgreSQL é imbatível. Armazenar geometrias projetadas corretamente no banco e fazer consultas com ST_Transform dentro das queries elimina a necessidade de reprojecionar dados toda vez que você abre um novo projeto. Uma query que calcula a distância entre dois pontos usando geometria geográfica (em vez de projetada) com ST_Distance(geom1::geography, geom2::geography) dá resultados em metros com precisão de centímetros, sem você precisar se preocupar com qual projeção usar.
Erros comuns que vão te dar trabalho extra
O erro número um é assumir que todos os dados no mesmo CRS estão alinhados. Duas camadas podem ter o mesmo código EPSG mas referenciar datums ligeiramente diferentes, e o software vai deixar você sobrepor sem aviso. Sempre verifique com ST_Transform ou a ferramenta "Check Geometry Validity" do QGIS antes de confiar numa sobreposição visual. O erro número dois é usar projeções globais para dados regionais. Projeções como Robinson ou Winkel Tripel são bonitas para mapas-múndi, mas se você está mapeando apenas o estado de São Paulo, essas projeções vão introduzir distorções desnecessárias. Use sempre uma projeção local ou regional — UTM, Lambert, ou a projeção cônica específica do seu país.
O erro número três é esquecer que a projeção afeta cálculos de buffer e interpolação. Um buffer de 1km em WGS84 não é um círculo de 1km de raio — é uma elipse distorcida porque as coordenadas estão em graus, não em metros. Sempre transforme para um CRS baseado em metros antes de fazer buffers, análises de proximidade ou qualquer operação que dependa de distância euclidiana. Projeções geográficas não são um detalhe técnico secundário. Elas determinam se o seu mapa comunica a informação corretamente ou se está mentindo, mesmo que involuntariamente. Escolha com consciência do que está sendo sacrificado e do que está sendo preservado. O resto é ferramenta.
