Como coordenadas funcionam na prática
Muita gente confundindo latitude com longitude desde o primeiro dia de aula de geografia. Eu vi isso acontecer todo semestre quando dava suporte técnico para projetos de mapeamento. A confusão básica é entender que a linha do equador e meridiano de greenwich são apenas referências arbitrárias — nenhum deles é mais "natural" que o outro, só decidimos chamar um de zero horizontal e outro de zero vertical. A linha do equador marca 0 grau de latitude. Tudo acima é norte, tudo abaixo é sul. O meridiano de Greenwich, que passa pelo Observatório Real em Londres, marca 0 grau de longitude. Leste é positivo, oeste é negativo. Isso é suficiente para a maioria das aplicações, mas a parte que ninguém explica direito vem depois, quando você precisa trabalhar com dados reais.
O que todo mundo erra sobre linha do equador e meridiano de greenwich
O primeiro erro comum é achar que grau decimal e grau minuto segundo são intercambiáveis sem conversão. Eu já vi planilha inteira de GPS quebrar porque alguém colou valores em DMS diretamente onde o sistema esperava DD. Um valor de 45°30'00" virando 45.30 em vez de 45.50 é o tipo de erro que passa despercebido até o relatório final sair errado. A conversão é simples: divide os minutos por 60 e soma ao grau. Os segundos, por 3600. O segundo erro, bem mais difícil de diagnosticar, é não verificar o sistema de referência. WGS84, SIRGAS2000, NAD83. Eles parecem equivalentes à primeira vista. A diferença entre WGS84 e SIRGAS2000 no Brasil pode variar de poucos metros a quase cem metros dependendo da região. Quando eu estava trabalhando num projeto de delimitação de propriedade rural no Mato Grosso, os dados do IBGE e os do cartório não fechavam. Descobriu-se que um usava WGS84 e o outro SIRGAS2000. A transformação entre eles usando o parâmetro NTL não resolveu tudo — tive que rodar uma transformação com pontos de controle locais para ajustar o resíduo. O workaround foi mapear três pontos conhecidos na região, calcular o desvio médio e aplicar uma correção afim nos dados problemáticos.
Sistema de coordenadas geográficas vs projetadas
Coordenadas geográficas usam graus. Latitude e longitude. Ideais para armazenamento e transmissão porque são universais. O problema aparece quando você precisa medir distância ou área. Um grau de longitude não vale a mesma coisa em quilômetros em toda parte. No equador, um grau de longitude equivale a cerca de 111 km. Nos polos, equivale a zero. Isso significa que cálculos de área direta em graus vão dar resultados absurdos se você não fizer a conversão para um sistema projetado. Sistemas projetados como UTM resolvem isso dividindo o planeta em zonas. Cada zona tem 6 graus de largura e usa uma projeção cilíndrica transversa que preserva distâncias dentro da zona. No Brasil, as zonas vão de 17S a 25S, dependendo da longitude. Se o seu dados cobre mais de uma zona, você precisa lidar com a mudança de fuso, o que introduz distorção na fronteira entre elas. A regra prática é: use geográficas para armazenar e transmitir, use UTM para calcular distância e área. Não tente fazer o contrário.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Formatos práticos de saída
Para quem trabalha com GIS ou desenvolvimento, o formato mais útil é GeoJSON com coordenadas em WGS84. É o padrão universal para APIs. Exemplo simples: { "type": "Feature", "geometry": { "type": "Point", "coordinates": [ -46.6333, -23.5505 ] }, "properties": { "nome": "São Paulo" } }
Nota importante: em GeoJSON a ordem é longitude primeiro, depois latitude. Isso invertido é a causa número um de dados mapeados no lugar errado. Londres aparecer no meio do Atlântico Sul é o sintoma clássico. Para arquivos shapefile, a estrutura é diferente. Você precisa de pelo menos três arquivos: .shp, .shx e .dbf. O .shp contém as geometrias, o .shx o índice e o .dbf os atributos. Ferramentas como QGIS exportam automaticamente os três quando você salva como shapefile. Se estiver programando, a biblioteca GDAL faz a conversão em uma linha.
Referência rápida de transformações
Dados brutos de GPS normalmente vêm em WGS84. Se o seu projeto exige SIRGAS2000, a conversão oficial no Brasil é feita pelo site do IBGE, que oferece uma ferramenta gratuita com o método NTL. O processo leva alguns segundos por ponto. Para lotes de dados, vale a pena automatizar com a biblioteca PROJ no Python. Um script básico converte mil pontos em menos de dois segundos.
| Sistema | Uso típico | Projeto no Brasil |
|---|---|---|
| WGS84 | GPS, mapas online, APIs | Padrão internacional |
| SIRGAS2000 | órgãos públicos brasileiros | Substituto oficial do SAD69 |
| UTM | medições de distância e área | Zonas 17S a 25S conforme a região |
| NAD83 | dados norte-americanos | Diferente de WGS84 por alguns centímetros a metros |
Uma última observação que acho importante: o próprio meridiano de Greenwich não é mais a referência oficial desde 1999. A IERS mantém o ITRF como padrão, e a diferença entre o antigo Greenwich astronômico e o Greenwich moderno é de cerca de 102 metros na direção leste. Para a maioria das aplicações correntes isso é irrelevante. Mas se você estiver lidando com dados históricos de navegação ou mapeamento preciso que use referências pré-1999, essa discrepância pode aparecer como erro sistemático nos seus resultados.
