CSV com Latitude e Longitude no Mapa: Abra no Navegador e Corrija os Sete Problemas Mais Comuns

Três colunas — um id, lat e lon — salvas como CSV e soltas no csv-viewer: esse é o tutorial inteiro para um arquivo limpo. Nada é enviado a um servidor; o arquivo é processado dentro da aba do seu navegador. Se o cabeçalho diz lat e lon, o seletor de colunas já vem preenchido e basta clicar em Abrir no mapa.

O resto é sobre arquivos que não são limpos — o Excel pt-BR ou es escreve -23,55 e ;, uma linha de título fica acima do cabeçalho, graus e minutos dividem uma única célula — e um visualizador que erra o palpite nem sempre avisa. Cada caso: o arquivo, o que o visualizador mostra (citado da nossa execução, inclusive quando não mostra nada), a correção no Excel, no LibreOffice Calc ou no Google Sheets, e a correção com ogr2ogr.

Testado em 15 de setembro de 2026 contra static-page-tools@6016a1b mais a mudança de robustez do csv-viewer — vírgula decimal, contador de linhas ignoradas, fallback para Latin-1 — não lançada no momento em que este texto foi escrito; GDAL 3.13.3 "Iowa City" para as transcrições de linha de comando.

O que o visualizador procura

A primeira linha é o cabeçalho — sempre a linha 0 — e o delimitador é escolhido contando ,, ; e tabulações apenas nessa linha; o mais frequente vence, e um empate vai para a vírgula. Células entre aspas são respeitadas; uma quebra de linha dentro de uma célula não é. Não há opção manual de delimitador, nem campo para colar texto, nem campo de URL; um arquivo por vez, sem limite de tamanho.

As colunas de coordenadas são encontradas pelo nome — sem diferenciar maiúsculas de minúsculas, correspondência exata — em três listas:

• Latitude — lat, latitude, latitudine, latitud, y, y_coord, ycoord, ylat, lat_dd, latitude_dd.
• Longitude — lon, lng, long, longitude, longitudine, longitud, x, x_coord, xcoord, xlon, lon_dd, longitude_dd.
• Geometria WKT — wkt, geom, geometry, wkb, shape, the_geom, geo, geomwkt, wkt_geom.

Sem correspondência exata: qualquer coluna que contenha lat, e qualquer uma que contenha lon ou lng; ainda nada: as duas primeiras colunas. Essas são apenas pré-seleções. O seletor Selecione as colunas de coordenadas abre para todo arquivo, mesmo um perfeito, com a dica Selecione quais colunas contêm as coordenadas. A detecção automática pré-selecionou os campos mais prováveis., um menu Coluna de Latitude e um Coluna de Longitude, e Abrir no mapa. Uma coluna WKT abre o mesmo seletor na aba WKT / Geometria; não existe o caminho "mapeado instantaneamente".

Ao confirmar, o painel de camadas exibe 3 pontos para um arquivo de três linhas e, quando alguma linha não sobreviveu, um segundo contador: 1 linha sem coordenadas válidas — a forma plural da mensagem é 2 linhas sem coordenadas válidas. Uma linha é contada quando sua latitude ou longitude não é um número após o processamento ou está fora de ±90 e ±180. As colunas de coordenadas saem da tabela de atributos; todas as outras colunas permanecem.

A vírgula decimal: -23,55

Sintoma. Excel pt-BR ou es, "Salvar como CSV": -23,55 com ; entre as colunas. Google Sheets, LibreOffice Calc e uma pasta de trabalho solta diretamente no visualizador (o caso .xlsx abaixo) escrevem vírgulas entre as colunas e colocam entre aspas as células com vírgula decimal: 1,"-23,55","-46,63",São Paulo. Uma exportação com tabulação dá -23,55 com tabulações.

O que o visualizador mostra. Os três são lidos corretamente: 3 pontos, sem contador, primeiro ponto em São Paulo em -46.63, -23.55 no GeoJSON exportado (fixtures 1, 2, 1b). A regra é aplicada na célula, não no arquivo: o visualizador lê -23,55 como −23,55 seja qual for o delimitador — ;, tabulação, ou uma célula entre aspas em um arquivo de vírgula, que é exatamente o que o Google Sheets, o LibreOffice Calc e uma pasta de trabalho solta diretamente (o caso .xlsx abaixo) escrevem para uma planilha pt-BR ou es. A única coisa que ele não consegue resgatar é uma vírgula decimal sem aspas em um arquivo de vírgula, porque 1,-23,55,-46,63 já são cinco células antes de qualquer parser vê-las — e nenhuma planilha escreve isso. O limite é 1,234: ele é lido como 1,234 (um grau e pouco), nunca como 1234, porque um valor com separador de milhar não pode ser uma coordenada em graus. Atributos não são tocados — um preço de 12,50 continua sendo o texto 12,50.

Correção na planilha, para ferramentas que precisam de ponto. Excel: Opções → Avançado, desmarque "Usar separadores do sistema", separador decimal .. Calc: Opções → Configurações de idioma → Localidade → Inglês (EUA). Sheets: Arquivo → Configurações → Localidade → Estados Unidos. Depois exporte.

Correção na linha de comando. No GDAL 3.13.3, nomear as colunas já resolve: ogr2ogr -f GeoJSON out.geojson decimal-comma-semicolon.csv -oo X_POSSIBLE_NAMES=lon -oo Y_POSSIBLE_NAMES=lat grava "coordinates":[-46.63,-23.55], e os arquivos com tabulação e com vírgula entre aspas dão o mesmo par. O que -oo AUTODETECT_TYPE=YES faz com as outras colunas depende do delimitador: em um arquivo ;, lat vira Real -23.55; em um arquivo de vírgula entre aspas ou de tabulação, a mesma célula continua String -23,55. Para atributos, e para qualquer ferramenta que não seja o GDAL, a exportação com localidade correta é a correção honesta.

Uma linha de título acima do cabeçalho

Sintoma. Uma linha de título — Levantamento de campo, setembro 2026, equipe A — acima do cabeçalho real id;lat;lon;nome, linhas separadas por ; com vírgula decimal.

O que o visualizador mostra. O título tem duas vírgulas e nenhum ponto e vírgula, então a vírgula vence e o título vira o cabeçalho: o seletor pré-seleciona Levantamento de campo como latitude e setembro 2026 como longitude. A linha do cabeçalho real não tem vírgula, então ela vira uma linha de dados cuja "latitude" é id;lat;lon;nome — não é um número — e é contada: 3 pontos · 1 linha sem coordenadas válidas. Cada linha de dados é dividida pelas vírgulas em 1;-23, 55;-46 e 63;São Paulo; o parser lê os dígitos iniciais, e os três pontos são desenhados em [55, 1], [79, 2] e [12, 3] — no oceano Índico, ao norte das Seicheles (fixture 3). Um plote silenciosamente errado, com um contador que culpa a única linha que estava certa; o atributo que sobrevive é equipe A, contendo 63;São Paulo. Isso não é "tudo cai em uma única coluna" — isso exigiria um título sem vírgula; um título com vírgulas espalha cada linha em tantas células quantas forem suas vírgulas, mais uma.

Correção na planilha. Apague a linha de título para que o cabeçalho vire a linha 1 — vale para Excel, Calc e Sheets; uma linha de unidades logo abaixo do cabeçalho é contada apenas como uma linha sem coordenadas válidas — é a linha de título acima do cabeçalho que destrói tudo.

Correção na linha de comando. O driver CSV do GDAL não tem uma opção de "pular N linhas" (HEADERS só aceita YES, NO ou AUTO), então descarte a linha e depois indique o separador: tail -n +2 title-row.csv > title-row-noheader.csv, e então ogr2ogr -f GeoJSON title-row-fixed.geojson title-row-noheader.csv -oo SEPARATOR=SEMICOLON -oo X_POSSIBLE_NAMES=lon -oo Y_POSSIBLE_NAMES=lat -oo AUTODETECT_TYPE=YES grava "coordinates":[-46.63,-23.55], vírgulas decimais incluídas. Lido como está, o ogrinfo comete o mesmo erro do visualizador e imprime Levantamento de campo (String) = 1;-23.

Latitude e longitude trocadas

Sintoma. Colunas chamadas lat e lon, com os valores invertidos: 1,-46.63,-23.55,São Paulo — uma exportação lon,lat colada sob um cabeçalho lat,lon; GeoJSON, WKT e a maioria das APIs escrevem a longitude primeiro.

O que o visualizador mostra. Dois resultados possíveis. Se os dois valores estão dentro de ±90 — todo ponto brasileiro, já que o país vai de aproximadamente −74° a −29° de longitude — o mapa desenha no oceano errado e não diz nada: 3 pontos, sem aviso, sem contador, primeiro ponto [-23.55, -46.63], no Atlântico Sul, cerca de 3.290 km a sudeste de São Paulo (fixture 4). Se uma longitude está além de ±90 — os 139,69 de Tóquio na coluna lat — essa linha é descartada e contada: 2 pontos · 1 linha sem coordenadas válidas, enquanto as duas linhas brasileiras do mesmo arquivo continuam desenhando no Atlântico Sul (fixture 5). O contador avisa que algo deu errado; ele não consegue dizer que os pontos que sobreviveram também estão errados.

A correção é o seletor. Nada detecta uma inversão — latitude −46,63 é um ponto perfeitamente válido. Defina Coluna de Latitude como lon e Coluna de Longitude como lat, clique em Abrir no mapa, e o mesmo arquivo desenha em São Paulo, primeiro ponto [-46.63, -23.55] (medido na fixture 4). Ou troque os dois nomes de cabeçalho na planilha.

Graus, minutos e uma letra de hemisfério em uma única célula

Sintoma. 23°33'S na célula de latitude, 46°38'W na célula de longitude — uma exportação de GPS ou um caderno de campo digitado.

O que o visualizador mostra. 3 pontos, sem mensagem, primeiro ponto [46, 23]: 23° norte, 46° leste, no centro da Arábia Saudita (fixture 6). O parser lê os dígitos iniciais e para no símbolo de grau; os minutos se perdem, e junto vai a letra do hemisfério que carregava o sinal de menos. A mudança de robustez não mexeu nisso: uma célula com símbolo de grau é trabalho de quem lê o arquivo.

Correção na planilha. Uma fórmula converte graus-minutos-hemisfério para graus decimais e nega tanto S quanto W. Com o texto em A1, no Calc ou no Sheets em configuração regional pt-BR ou es (; entre os argumentos; o Excel em inglês pede ,):

=IF(OR(RIGHT(A1;1)="S";RIGHT(A1;1)="W");-1;1)*(VALUE(LEFT(A1;FIND("°";A1)-1))+VALUE(MID(A1;FIND("°";A1)+1;FIND("'";A1)-FIND("°";A1)-1))/60)

Rodada no LibreOffice: 23°33'S → -23.55, 15°47'S → -15.78333, 46°38'W → -46.63333. Coloque o resultado em uma coluna chamada lat ou lon e o visualizador reconhece pelo nome.

Para alguns poucos pontos, o coordinate-converter tem um campo de GMS com uma pegadinha que medimos: ele exige os segundos. 23°33'S 46°38'W dá Formato GMS não reconhecido.; 23°33'00"S 46°38'00"W dá -23.55000000 e -46.63333333. Adicione o 00".

Na linha de comando, nada. O GDAL não tem parser de GMS: ogrinfo -oo AUTODETECT_TYPE=YES classifica a célula como String, e o ogr2ogr com -oo X_POSSIBLE_NAMES=lon -oo Y_POSSIBLE_NAMES=lat sai com código 0, imprime Warning 1: Invalid value type found in record 1 for field lat, e grava "geometry":null em cada linha — um arquivo "convertido" sem nenhum ponto dentro.

Coordenadas UTM (E/N) coladas como latitude e longitude

Sintoma. 333624,7394648 — metros em SIRGAS 2000 / UTM zona 23S, colunas easting e northing.

O que o visualizador mostra. Nenhum dos dois nomes é um alias e nenhum contém lat ou lon, então o seletor cai de volta para as duas primeiras colunas e pré-seleciona id e easting. Confirmar isso, ou escolher easting e northing manualmente, dá o mesmo resultado: toda linha falha na checagem de faixa, zero pontos sobrevivem, e o visualizador mostra Nenhuma coluna de coordenadas válida encontrada. Verifique se as colunas selecionadas contêm valores numéricos de latitude e longitude. (fixture 7). A mensagem é sobre os valores, não sobre os nomes; não há entrada de CRS.

Correção na linha de comando. Nomeie as colunas, declare o CRS de origem, peça WGS 84: ogr2ogr -f GeoJSON utm-fixed.geojson utm.csv -oo X_POSSIBLE_NAMES=easting -oo Y_POSSIBLE_NAMES=northing -s_srs EPSG:31983 -t_srs EPSG:4326 coloca o primeiro ponto em -46.6300, -23.5500 — São Paulo, com um resíduo de alguns milionésimos de grau sendo o arredondamento em metros da nossa fixture. 31983 é SIRGAS 2000 / UTM zona 23S; confira esse nome com gdalsrsinfo -o wkt1 EPSG:31983, porque 31982 e 31984 são as zonas vizinhas (cerca de 6° de diferença, sem erro), 3198 é um CRS líbio válido, e só 319830 falha. A cola de códigos EPSG do Brasil e da América Latina tem os códigos de zona. Por padrão, o GDAL grava um membro crs (CRS84) nesse GeoJSON; -lco RFC7946=YES remove esse membro e arredonda para sete casas decimais, que é o que um visualizador quer.

Na planilha, não dá. Converter UTM para geográficas é matemática de projeção; uma planilha com easting renomeada para lon é a versão silenciosa desse mesmo problema.

Latin-1 do Excel: São Paulo ou S�o Paulo

Sintoma. O Excel no Windows, em "CSV (delimitado por vírgulas)" — não "CSV UTF-8" — grava em Windows-1252: ã vira o byte único 0xE3, inválido como UTF-8. As coordenadas são ASCII e nunca se importaram; os atributos é que quebram.

O que o visualizador mostra. 3 pontos, o primeiro ponto correto, e São Paulo na tabela de atributos — não S�o Paulo (fixture 8). O arquivo é decodificado como UTF-8 estrito primeiro; quando isso falha em um byte como 0xE3, ele é decodificado como Windows-1252 em vez disso. Um arquivo realmente em UTF-8 não é afetado.

Correção na planilha. Excel: Salvar Como → "CSV UTF-8 (Delimitado por vírgulas)". Calc: Text CSV → Editar configurações do filtro → conjunto de caracteres "Unicode (UTF-8)". O Sheets sempre grava em UTF-8.

Correção na linha de comando. iconv -f WINDOWS-1252 -t UTF-8 latin1.csv > latin1-utf8.csv — o byte 0xE3 vira C3 A3. O GDAL no arquivo bruto mostra o mesmo estrago (ogrinfo imprime nome (String) = S�o Paulo), então rode o iconv antes do ogr2ogr também.

Soltando o .xlsx diretamente

Sintoma. Você solta a própria pasta de trabalho. O visualizador lê .xls e .xlsx, apenas a primeira planilha.

O que o visualizador mostra. Depende de como cada célula está armazenada, então montamos uma pasta de trabalho pt-BR com os dois tipos e medimos célula por célula (fixture 9). Uma célula numérica guardando -23.55 com formato de número 0.00 — o que o Excel pt-BR exibe como -23,55 — sai como -23.55; a configuração regional de exibição não fica no arquivo. Uma célula guardando o texto -15,79, mantido como texto pelo Excel, sai entre aspas, "-15,79" — a mesma forma de uma exportação do Sheets — e é lida como −15,79. Os dois caem onde deveriam: 3 pontos, sem contador, [-46.63, -23.55] e [-47.88, -15.79].

Correção. Mova a planilha com as coordenadas para a primeira posição, ou exporte-a como CSV UTF-8 e use as correções acima.

Arquivos de teste que você pode usar

Nenhum host público mantém CSVs de teste pequenos, então aqui estão os nossos — três linhas cada. Copie um item para um editor de texto, um trecho por linha, salve como .csv e solte no csv-viewer. O parêntese indica o caso acima, na ordem das seções.

• Vírgula decimal, ponto e vírgula (fixture 1) — id;lat;lon;nome · 1;-23,55;-46,63;São Paulo · 2;-15,79;-47,88;Brasília · 3;-3,12;-60,02;Manaus (caso 1).
• Vírgula decimal, entre aspas, separado por vírgula (fixture 1b) — id,lat,lon,nome · 1,"-23,55","-46,63",São Paulo · 2,"-15,79","-47,88",Brasília · 3,"-3,12","-60,02",Manaus (caso 1).
• Vírgula decimal, separado por tabulação (fixture 2) — a fixture 1 com uma tabulação digitada no lugar do ; (caso 1).
• Linha de título acima do cabeçalho (fixture 3) — Levantamento de campo, setembro 2026, equipe A · id;lat;lon;nome · 1;-23,55;-46,63;São Paulo · 2;-15,79;-47,88;Brasília · 3;-3,12;-60,02;Manaus (caso 2).
• Trocada, dentro da faixa (fixture 4) — id,lat,lon,nome · 1,-46.63,-23.55,São Paulo · 2,-47.88,-15.79,Brasília · 3,-60.02,-3.12,Manaus (caso 3).
• Trocada, uma linha fora da faixa (fixture 5) — id,lat,lon,nome · 1,-46.63,-23.55,São Paulo · 2,-47.88,-15.79,Brasília · 3,139.69,35.68,Tóquio (caso 3).
• Graus e minutos (fixture 6) — id,lat,lon,nome · 1,23°33'S,46°38'W,São Paulo · 2,15°47'S,47°53'W,Brasília · 3,3°07'S,60°01'W,Manaus (caso 4).
• UTM zona 23S (fixture 7) — id,easting,northing,nome · 1,333624,7394648,São Paulo · 2,191433,8252182,Brasília · 3,687688,7465276,Rio de Janeiro (caso 5; Rio, não Manaus, porque Manaus fica na zona 20S).
• Latin-1 (fixture 8) — o controle recodificado com iconv -f UTF-8 -t WINDOWS-1252 all-valid.csv > latin1.csv (caso 6).
• Uma pasta de trabalho no estilo pt-BR construída para imitar o Excel (fixture 9) — um .xlsx com o cabeçalho de controle, linha 2 com células numéricas formatadas 0.00, linha 3 com células de texto -15,79 e -47,88, linha 4 numérica — 3 pontos no Brasil (caso 7).
• Controle (fixture 10) — id,lat,lon,nome · 1,-23.55,-46.63,São Paulo · 2,-15.79,-47.88,Brasília · 3,-3.12,-60.02,Manaus — 3 pontos no Brasil.

E um arquivo real. O Programa Queimadas do INPE publica todo foco de incêndio ativo detectado no Brasil em um CSV diário: o arquivo de 14 de setembro de 2026 é focos_diario_br_20260914.csv, 4.283.545 bytes, UTF-8, 16 colunas separadas por vírgula começando com id,lat,lon,data_hora_gmt,satelite,municipio,estado,…, 27.447 linhas. Ele responde 200 com Accept-Ranges: bytes e Access-Control-Allow-Origin: * — aberto, sem cadastro. Não há arquivo de licença ao lado dos CSVs; a nota de governança de dados do INPE em focos/documentos/ (irmão de focos/csv/) descreve os dados como disponíveis para qualquer usuário pela sua página de dados abertos, então o crédito é INPE / Programa Queimadas.

lat e lon são correspondências exatas de alias e os espaços à esquerda nas células são removidos: nossa execução desenhou 27447 pontos, nenhuma linha ignorada, primeiro ponto [-45.2744, -5.2883] no Maranhão, 581 ms entre Abrir no mapa e a linha na camada.

Dois avisos, datados de 15 de setembro de 2026: o diretório diário mantém cerca de um mês de arquivos, então o nome do arquivo acima expira — pegue o mais recente; e os arquivos mensais ao lado dele têm cerca de 99 MiB, um download, não algo para simplesmente soltar.

Para times

Colocar os pontos em um mapa é a metade fácil. Alguém te mandou um CSV porque um time precisa fazer alguma coisa naqueles pontos: um status por linha, fotos e um formulário vindos do campo, uma revisão, um relatório até sexta-feira. O Geodocs importa o mesmo arquivo para um mapa de equipe, mantém as colunas como campos que o time preenche, conduz a revisão e gera o relatório com o mapa dentro. O visualizador é onde você confere o arquivo; o workspace é onde ele vira trabalho.