O problema com coordenadas que todo mundo encontra
A maioria dos arquivos CSV que vejo trazendo para projetos espaciais tem longitude definida de forma inconsistente. Uns usam graus decimais, outros graus-minutos-segundos, alguns colocam valores negativos para oeste e outros esquecem o sinal. Isso gera erros silenciosos que só aparecem quando o mapa já foi gerado e nada faz sentido.
defina longitude corretamente desde o início
Longitude é a coordenada angular que mede a posição leste-oeste de um ponto na superfície terrestre em relação ao meridiano de Greenwich. O valor varia de -180 a +180 graus no formato decimal, ou de 0 a 180 com indicação L (leste) ou O (oeste) no formato DMS. O sistema de referência mais comum é o WGS84, usado por GPS e praticamente todas as APIs de mapa modernas. Se você não especificar o sistema de referência, ninguém saberá exatamente onde aquele ponto está no planeta. Na prática, a maior parte das pessoas só se importa com o formato numérico. Gravar como float com casas decimais suficientes, manter o sinal negativo para hemisfério oeste, e garantir que o valor esteja dentro do intervalo válido. Um problema real que eu enfrentei recentemente foi com um banco de dados PostGIS que recebia longitude no formato DMS embutida em texto, tipo "46°37'54.2\"O". O campo era do tipo text porque alguém decidiu que seria mais fácil assim. Eu converti tudo com uma função customizada que extraía graus, minutos e segundos, aplicava a fórmula de conversão e salvava como double precision. O workaround foi escrever uma routine em SQL que fazia a split por e caracteres especiais, convertia cada parte e calculava o resultado decimal. Levou cerca de três horas para refazer os dados de uma tabela com 40 mil registros, mas salvou o projeto inteiro.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro detalhe que poucos percebem: a ordem dos pares latitude-longitude não é universal. O padrão ISO define lat primeiro, depois lon, mas APIs como a do Google Maps e o GeoJSON usam lon primeiro, depois lat. Se você passar os valores na ordem errada para o GeoJSON, o ponto vai parar no lugar errado e você vai levar algum tempo para perceber que está olhando para a África quando deveria estar olhando para São Paulo. Eu já perdi duas tardes caçando esse bug em dados importados de planilhas antigas. Para defina longitude em projetos sérios, use sempre o sistema de referência explicitamente. Um código EPSG, como EPSG:4326 para WGS84, resolve metade dos problemas que surgem depois. Ferramentas como GDAL, QGIS e bibliotecas como pyproj ou shapely lidam bem com transformações entre sistemas, mas só se você informar qual sistema de origem e qual o destino. Sem isso, a conversão pode parecer funcionar e produzir resultados visualmente plausíveis que estão geometricamente errados.
O formato Decimal Degrees é o mais seguro para interoperabilidade. Evite DMS salvo como texto dentro de campos de banco de dados — ele ocupa mais espaço, não suporta operações espaciais diretas e quebra em qualquer consulta que exija cálculo. Se precisa armazenar DMS para fins de exibição, guarde os valores decimais e formate na camada de apresentação. A principal limitação da longitude como coordenada é que ela não funciona bem em projeções cartográficas sem transformação. Colocar longitude pura em um sistema de coordenadas planas distorcidas gera erros de distância e área. Para medições precisas, converta para um sistema projetado adequado à sua região, como UTM zona correspondente. Um erro comum em análise espacial iniciante é calcular distâncias diretamente sobre graus, o que produz resultados totalmente imprecisos — especialmente perto dos polos, onde um grau de longitude representa muito menos quilômetros do que no Equador.
Resumindo o fluxo prático: valide o intervalo (-180 a 180), confirme o sistema de referência (WGS84 na maioria dos casos), escolha Decimal Degrees como formato de armazenamento, e sempre verifique a ordem dos pares antes de importar qualquer dado para GIS ou APIs de mapeamento.
