Um ponto em (0, 0), ou em algum lugar do Golfo da Guiné: quatro maneiras de perder uma coordenada

Resposta curta: um ponto em (0, 0) não é um lugar de onde seus dados vieram. É uma coordenada que sumiu, foi trocada de coluna ou foi lida da coluna errada — e o aglomerado que você vê não precisa estar em (0, 0): o que foi medido para este post fica a mil quilômetros da costa da África Ocidental, no Golfo da Guiné. Quatro falhas produzem isso: duas as ferramentas contam em voz alta, duas são silenciosas.

Testado em 23 de setembro de 2026 contra static-page-tools@79fc1f6 — o csv-viewer e o coordinate-converter como estão publicados hoje. Toda string citada é a da própria ferramenta; toda coordenada é o primeiro par de um download Exportar GeoJSON, com exceção da transcrição do GDAL em "Como corrigir", repetida sem alteração da rodada de linha de comando do guia de CSV (GDAL 3.13.3 "Iowa City"). Arquivos de teste no fim.

A célula vazia: um descarte contado, e sempre foi

Cabeçalho id,lat,lon,nome, linhas 1,-23.55,-46.63,São Paulo, 2,,,Brasília, 3,-3.12,-60.02,Manaus. O painel mostra 2 pontos · 1 linha sem coordenadas válidas, não há aviso, e a linha em branco não entra no export de jeito nenhum: duas feições, nenhum [0,0] em lugar algum. Esvazie uma segunda linha e ele passa a mostrar 1 ponto · 2 linhas sem coordenadas válidas. Esvazie as três e o contador vai embora junto com a camada que ele contava, deixando o aviso citado mais adiante.

O visualizador nunca desenhou essa linha no zero — nem nesta versão, nem na anterior à correção de setembro. O mesmo arquivo passado pelo parser como ele estava antes da correção de setembro dá os mesmos dois pontos e o mesmo único descarte: o código antigo usava parseFloat, e parseFloat de uma string vazia já não é um número. A verificação explícita de string vazia que a correção acrescentou comprou preservação, não conserto — ela trocou parseFloat por Number para que uma célula 23°33'S deixasse de ser plotada na Arábia Saudita, e Number de uma string vazia é 0, então sem aquela linha a mudança teria introduzido o ponto em (0, 0). No mesmo aparato de teste a linha 23°33'S de fato se moveu, de desenhada em [46, 23] para um descarte contado, então a não-mudança da célula em branco é real.

O conversor transforma o mesmo defeito em instrução de digitação: preencha Latitude, deixe Longitude vazio, e o card diz Preencha latitude e longitude para converter. em âmbar e não renderiza nada. Com os dois vazios ele não diz nada. Nenhuma das duas ferramentas coloca uma célula vazia em (0, 0).

Trocadas: nada consegue detectar

Mesmo cabeçalho, valores invertidos: 1,-46.63,-23.55,São Paulo. Linha de contagem 3 pontos, sem contador, sem aviso, primeiro par [-23.55, -46.63] — 3.290,4 km de São Paulo em um azimute de 147°, no Atlântico Sul; Manaus cai a 7.934,8 km de Manaus. Nada diz que há algo errado e nada tem como dizer: −46,63 é uma latitude válida e −23,55 é uma longitude válida. O conversor concorda convertendo — -46.63 e -23.55 deixam a linha auxiliar vazia e devolvem -46.63000000 e -23.55000000.

Uma linha pode ser pega, por acidente, quando a troca joga uma longitude além de ±90 na coluna de latitude. Faça a terceira linha virar 3,139.69,35.69,Tokyo e o visualizador mostra 2 pontos · 1 linha sem coordenadas válidas; as outras duas continuam 3.290 km fora do lugar. O conversor recusa 139.69 com Latitude ou longitude inválida.

A coluna errada: o que a regra de magnitude não vê

Mude só o cabeçalho, para id,este,norte,nome. O seletor abre em todo arquivo e pré-seleciona por nome: apelidos conhecidos, depois uma busca por substring em lat e lon, depois as duas primeiras colunas. Nem este nem norte casa, então Coluna de Latitude vem pré-marcada como id e Coluna de Longitude como este. Aceite isso e você recebe 3 pontos, sem contador, sem aviso, primeiro par [-46.63, 1] — a latitude real parada na tabela de atributos sob norte, como -23.55.

A regra de magnitude mais adiante não enxerga esta. As latitudes são 1, 2 e 3, cada uma uma latitude brasileira plausível, e o mapa está 2.729,8 km ao norte de onde deveria estar, com cada número dele passando na inspeção. O indício é o formato da coluna: uma latitude que sobe de um em um é um número de linha.

Coloque metros UTM de verdade sob o mesmo cabeçalho — 1,333283.88,7394643.65,São Paulo — e o resultado se inverte. A pré-seleção é idêntica, mas 333283.88 não é uma longitude, então toda linha reprova na checagem de limites, nenhuma camada é criada, e você recebe Nenhuma coluna de coordenadas válida encontrada. Verifique se as colunas selecionadas contêm valores numéricos de latitude e longitude. Qual dos dois você recebe depende dos valores, não de alguma coisa que a ferramenta entenda. Se os números são metros, você precisa do código EPSG da zona, listado em "Escolhendo uma zona UTM no Brasil" na folha de consulta EPSG.

No conversor não há coluna a escolher e a única checagem é o limite: 90 e 180 convertem, 90.01 e 180 dão Latitude ou longitude inválida. Um easting de seis dígitos fica fora desse limite, então a regra o recusa — este é lido da regra, não digitado no card para este post — enquanto um contador de linha valendo 1 fica dentro dele e converte.

A vírgula decimal que não sobreviveu ao salvamento

Colunas certas, números certos, arquivo errado: 1,-23,55,-46,63,São Paulo sob id,lat,lon,nome. Em um arquivo delimitado por vírgula isso são seis células, não quatro, antes de qualquer parser de coordenada ver o arquivo — lat fica com -23, lon fica com 55, nome fica com -46, e São Paulo cai fora do fim. As duas células de coordenada são números inteiros, então nada é recusado: 3 pontos, sem contador, sem aviso. São Paulo desenha em [55, -23], a 10.096,7 km de distância; Manaus em [12, -3], a 1.374,8 km da origem — o Golfo da Guiné do título. O indício está na tabela de atributos, onde nome lê -46.

As aspas são a diferença inteira: 1,"-23,55","-46,63",São Paulo volta como [-46.63, -23.55] com nome lendo São Paulo. O resgate roda por célula, depois que a linha é dividida, então ele só consegue salvar uma vírgula que nunca foi um delimitador.

O conversor tem o mesmo defeito e o esconde melhor. Digite -23,55 e -46,63 e não há linha de erro nem campo vermelho — e o resultado mostra -23.00000000 e -46.00000000. O validador dele troca a vírgula por ponto antes de checar, então o valor passa; o parser dele não troca, então ele para na vírgula. Isso são 61,2 km ao norte do ponto que você digitou quando só a latitude leva vírgula, 88,8 km em um azimute de 047° quando as duas levam. Com pontos ele dá -23.55000000 e -46.63000000. É um bug, está registrado, e nada avisa você hoje.

O diagnóstico de dez segundos

O Brasil vai de aproximadamente −74° a −29° de longitude e de +5° a −34° de latitude, e a maior parte disto é uma checagem de magnitude contra essa caixa. Uma longitude fora de −74 a −29 é o indício de uma troca: as do arquivo trocado são −23,55, −15,79 e −3,12, todas reprovando, enquanto as do arquivo correto, −46,63, −47,88 e −60,02, passam todas. Uma longitude entre +12 e +79 é o indício de uma vírgula decimal perdida — aquele arquivo exporta 55, 79 e 12. Uma latitude além de ±90 é a única coisa que as duas ferramentas pegam sozinhas.

Duas coisas que a regra não vai contar para você. A coluna errada passa direto por ela: latitudes de 1, 2 e 3 estão dentro da faixa e o mapa continua 2.729,8 km fora do lugar. E (0, 0) significa ausente, e não zero, exceto quando não significa — uma célula em branco nunca chega ao mapa, antes ou depois daquela correção, enquanto uma célula que guarda um 0 literal chega e é desenhada na origem. Então exatamente (0, 0) veio de uma célula que guardava um zero, e um aglomerado apenas perto dele, como [12, -3] a 1.374,8 km, veio de um número que foi encurtado. O quase-acerto é o perigoso, porque parece dado de verdade.

Como corrigir

Uma troca e uma coluna errada se resolvem as duas no seletor, sem reexportar nada. Abra o arquivo de novo no csv-viewer, aponte Coluna de Latitude e Coluna de Longitude para as colunas que realmente as contêm, e clique em Abrir no mapa. No arquivo trocado isso move o primeiro par de [-23.55, -46.63] para [-46.63, -23.55]; no arquivo de coluna errada, escolher norte como latitude faz o mesmo. Olhe o export, não o contador — a linha de contagem mostra 3 pontos antes e depois, então só o par diz que funcionou.

No conversor é o botão entre os dois campos, com o rótulo Trocar latitude e longitude: um clique transforma -46.63 e -23.55 em -23.55 e -46.63.

Para a vírgula a correção está no arquivo, e a parte dela medida aqui são as aspas — dígitos idênticos, entre aspas por célula, são lidos corretamente; sem aspas, não. Qual configuração de planilha produz qual arquivo não foi testado para este post, e nenhuma planilha chegou a ser executada, então trate "salvar com ponto como separador decimal" como o formato da correção e confira os bytes que você realmente obtém.

Fora do navegador o equivalente ao seletor são duas flags do GDAL: ogr2ogr -f GeoJSON out.geojson in.csv -oo X_POSSIBLE_NAMES=lon -oo Y_POSSIBLE_NAMES=lat. No arquivo limpo de três linhas isso termina com código 0 e escreve {"type":"Point","coordinates":[-46.63,-23.55]} para São Paulo — a rodada de controle da linha de comando do guia de CSV, não uma leitura do navegador. Coloque os nomes das suas próprias colunas nas flags.

Linhas de título, acentos Latin-1 e um .xlsx no lugar do CSV dão errado no mesmo arquivo; o guia de CSV no mapa cobre esses casos.

Arquivos de teste que você pode usar

Nada está hospedado — cole as linhas em um editor de texto e salve cada uma como um .csv em UTF-8.

• A célula vazia: id,lat,lon,nome, 1,-23.55,-46.63,São Paulo, 2,,,Brasília, 3,-3.12,-60.02,Manaus.
• Trocadas: 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.
• A coluna errada: id,este,norte,nome, 1,-46.63,-23.55,São Paulo, 2,-47.88,-15.79,Brasília, 3,-60.02,-3.12,Manaus.
• A vírgula decimal: 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.

Para times

Uma troca ou uma coluna errada é um problema de repasse, não de arquivo: acontece onde uma planilha sai das mãos de uma pessoa e chega no mapa de outra. O Geodocs mantém os dados de campo em um mapa compartilhado onde os campos de coordenada são decididos uma vez, na hora em que o formulário é montado.