Coordenadas Geograficas

Como funciona a coisa na prática

Quando você começa a mexer com coordenadas geograficas, logo percebe que a teoria da escola é bem diferente do que acontece no campo ou no software. O sistema parece simples até você tentar converter entre diferentes referenciais e descobrir que os resultados não batem. A base é isto: cada ponto na Terra recebe dois números, latitude e longitude. Latitude vai de -90 a 90 graus, longitude de -180 a 180. O zero de latitude é o equador, o zero de longitude é o meridiano de Greenwich. Isso todo mundo sabe.

O que pouca gente explica direito é que esses números não têm significado por si só. Eles dependem de um datum geodésico. Mudar o datum e as coordenadas mudam, mesmo sendo o mesmo lugar físico. No Brasil, o mais comum é o SIRGAS 2000, que substituiu o SAD 69 há anos. A diferença entre eles pode ser de dezenas de metros dependendo da região.

Coordenadas geograficas no dia a dia de quem trabalha com georreferenciamento

Eu perdi uma manhã inteira num projeto de mapeamento porque um arquivo_shape tinha coordenadas em SAD 69 e o outro em SIRGAS 2000. Como ambos usavam WGS84 como base de projeção no QGIS, o software nem reclamar. Dois lotes que deveriam colar um no outro ficaram afastados quase 70 metros. Levei dois dias para achar o problema. O workaround foi direto: verificar o datum de cada camada individualmente nas propriedades, não confiar na projeção do projeto. A maioria dos erros nessa área acontece por confiança cega no default do software. Ninguém para pra checar o sistema de referência de cada fonte de dados que importa.

Outro ponto que sempre causa confusão: graus decimais versus graus minutos segundos. GPS de consumo costuma entregar em GMS ou em formato híbrido (graus e minutos decimais). Planilha de imobiliário geralmente vem em GD. Se você tratar tudo como a mesma coisa sem converter, o erro é garantido. Multiplicar ou dividir por 60 no lugar errado destrói suas coordenadas em segundos.

Sistemas de referência e projeção: a parte que ninguém lê

SRD (Sistema de Referência de Coordenadas) e (projeção cartográfica) são coisas diferentes e você precisa tratar elas separadamente. O SRD define o datum e o elipsoide. A projeção define como você amassa a esfera num plano. No Brasil, o padrão para mapas temáticos e projetos de engenharia é o UTM, zona correspondente à sua área de interesse. Zona 22S, 23S, 24S. Cada uma cobre cerca de 6 graus de longitude. Colocar coordenadas UTM de uma zona numa outra zona altera a posição em centenas de metros.

Uma coisa que gente nova quase nunca leva em conta: a precisão das suas coordenadas depende de como elas foram obtidas. Coordenadas extraídas de olho num mapa digital no Google Earth podem ter erro de 5 a 20 metros. Coordenadas de GNSS RTK chegam a centímetros. Anotar a fonte e o método de captura é tão importante quanto o número em si. Sem isso, seu dado não tem rastreabilidade e vira problema futuro.

Formatos que você vai encontrar e como lidar com cada um

Os formatos mais usados na prática são WGS84 em graus decimais, que é o padrão do GPS e da maioria dos sistemas GIS. Depois vem UTM em metros, útil pra medição de distâncias porque evita a distorção de escala que aparece em graus. CSV com duas colunas, SHP com CRS embutido no arquivo prj, KML pros casos mais simples. Quando você recebe um arquivo sem metadados de projeção, o QGIS ou o ArcGIS vai tentar adivinhar. Adivinhar.errado é o comportamento padrão. A solução mais rápida é usar a ferramenta de definição de projeção com cuidado, mas só depois de confirmar qual é o sistema correto. Se não tiver como confirmar, não processe aquele dado até resolver. Dados projetados errado propagam erro pra todo o resto do fluxo.

Um detalhe prático que corta tempo: se você tem uma planilha com latitude e longitude em graus decimais e quer transformar num shape ou geojson, não precisa de ferramenta paga. O QGIS resolve com a função "Adicionar camada de camada de texto delimited". Seleciona as colunas X e Y, marca o CRS como EPSG:4326 e pronto. Levanta em segundos. O mesmo vale pra conversão em lote via PyQGIS ou scripts Python com a biblioteca pyproj, que converte entre qualquer par de sistemas em milissegundos.

Limitações reais que ninguém avisa

Coordenadas geográficas em graus não servem pra calcular distância direta com boa precisão. Usar a fórmula de Haversine funciona pra distâncias curtas, mas pra algo como o Comprimento de uma estrada ou perímetro de um município grande, o erro já começa a aparecer. Pra isso, use projeção UTM local ou ferramentas que considerem o elipsoide, como a função de distância do PostGIS com geometria geográfica. O outro problema clássico: coordenadas polares. Perto dos polos, a convergência dos meridianos faz com que pequenos erros de longitude causem deslocamentos enormes no terreno. Se você trabalha com dados em altas latitudes, projeções poli-equidistantes ou a UPS são mais adequadas que UTM.

Também tem o caso dos arquivos mal formados onde valores de latitude ultrapassam 90 ou longitude ultrapassa 180. Isso é sempre um erro de digitação ou de conversão. Filtrar e validar os limites antes de processar evita dores de cabeça. Um script simples que identifica outliers já resolve boa parte dos problemas de qualidade.

Recursos práticos

Pro conversões, o site da Embraesp tem calculadoras online gratuitas que funcionam bem pra SAD 69, SIRGAS 2000 e WGS84. Pro tratamento em batch, o QGIS com o processador de modelos permite automatizar conversão, validação e exportação num fluxo só. Pra quem programa, a biblioteca pyproj cobre praticamente todas as transformações suportadas pelo PROJ. O manual do IBGE sobre sistemas de referência também é útil quando precisa justificar a escolha do datum num laudo técnico. Não é leitura obrigatória, mas resolve dúvidas pontuais sobre margem de erro e padrões aceitos pelos órgãos públicos.