UTM para latitude e longitude: a zona, o hemisfério e o ponto a 611 km de distância
Resposta curta: um leste e um norte são metros medidos dentro de uma única zona de 6° de largura, então, sem o número da zona e a letra do hemisfério, eles não são um local. Dê os dois ao conversor de coordenadas e o ponto cai sobre si mesmo; mude a zona em uma unidade e ele desliza 611.563 m — 611,563 km — para leste ou para oeste, ao longo do mesmo paralelo; tire o falso norte de 10.000.000 m e os mesmos metros caem a 9.981.808 m de distância, na costa da Antártida. Abaixo: os três erros, o caso em que o próprio conversor está errado hoje, e a exportação que se recusa a devolver o seu leste como longitude.
Todo número abaixo foi medido em 23 de setembro de 2026 com GDAL 3.13.3, PROJ 9.8.1 e as duas ferramentas de navegador em static-page-tools@79fc1f6 — exceto as duas constantes de projeção da próxima seção, que são definições e não leituras, e a recusa de exportação mais adiante, que entrou depois desse commit. O ponto de referência é São Paulo, -46.6388 -23.5489 em SIRGAS 2000, cujos metros em UTM 23S são 332724.396065356 7394759.09232324: o gdaltransform converte um no outro e de volta sem mover um dígito impresso, então toda distância abaixo é o erro e nada mais.
O que falta em um par UTM
A UTM corta o mundo em sessenta zonas de 6° de longitude de largura e mede metros dentro de cada uma. Duas constantes mantêm esses metros positivos, e as duas são parâmetros da projeção, não algo que este post tenha medido: o meridiano central de cada zona recebe um falso leste de 500.000 m, e as zonas ao sul do equador somam um falso norte de 10.000.000 m, o que as do norte não fazem. O falso leste também é de onde vem a faixa que você deve esperar, e é uma conta que você mesmo pode fazer — uma zona alcança 3° para cada lado do seu meridiano central, e 3° de longitude são cerca de 334 km no equador e menos quanto mais longe dele você estiver, então um leste dentro da própria zona fica a uns 334 km da linha central de 500.000 m: entre uns 166.000 e 834.000 no caso mais largo. Então 332724.396065356 7394759.09232324 só é uma resposta completa depois que você também diz 23 e S — os mesmos dois números são um ponto válido em cada uma das sessenta zonas e nos dois hemisférios, e nada no arquivo ou na célula da planilha diz qual. O cartão UTM do conversor pede os três: Zona, Leste (E) e Norte (N).
Erro um: a zona errada
Com Projeção de origem (CRS) em SIRGAS 2000 (EPSG:4674) e Projeção de destino (CRS) em WGS 84 (EPSG:4326), quem decide é a caixa Zona, e os mesmos metros sob três zonas dão três respostas: 22S retorna -23.54890000 -52.63880000, 23S retorna -23.54890000 -46.63880000, 24S retorna -23.54890000 -40.63880000. A latitude não se move nem um pouco. A longitude se move exatamente 6° por zona — a largura de uma zona — o que, na latitude de São Paulo, é 611.563 m medidos sobre uma esfera, ou 612.575 m sobre o elipsoide GRS80; toda distância neste post é a esférica, salvo quando dito o contrário. O gdaltransform -s_srs EPSG:31982 -t_srs EPSG:4674 e seus vizinhos EPSG:31983 e EPSG:31984 imprimem os mesmos três pares, dígito a dígito.
Nenhuma mensagem entra em cena — a linha de ajuda embaixo do cartão UTM fica vazia nos três casos — e uma zona errada não espalha os seus dados, ela os desliza de lado para um paralelo plausível, e é por isso que ninguém percebe no mapa.
Erro dois: o hemisfério que a caixa Zona não consegue dizer
Aqui a ferramenta está errada, e você deveria saber disso antes de confiar nela. A caixa Zona aceita uma letra, mas para os números de zona 17 a 25 a letra é descartada: 23N e 23n retornam os dois -23.54890000 -46.63880000, a resposta de 23S, byte a byte, com a linha de ajuda vazia, e o resultado somente leitura devolve 23S para você. Fora dessa faixa a letra funciona — 16N e 16S diferem, e 26N e 26S também. As zonas 17 a 25 são exatamente o Brasil.
Isso custa um ponto real. Boa Vista, em Roraima, fica em -60.6714 2.8235, ao norte do equador, na zona 20N; o gdaltransform -s_srs EPSG:4674 -t_srs EPSG:31974 dá os metros dela como 758873.827731744 312343.360559676. Digitados no conversor com essa zona correta, 20N, a resposta é -86.38145844 -23.14479495 — a 400 km do Polo Sul, 10.002.260 m (10.002,3 km) de Boa Vista, sem mensagem de tipo nenhum. 20S retorna o par idêntico, o que prova que é a letra sendo descartada e não a aritmética, e o GDAL reproduz a mesma leitura errada até a oitava casa decimal quando recebe EPSG:31980, zona 20S, de propósito. O seletor não salva você: o grupo Brasil dele é inteiramente do sul, e as únicas quatro entradas UTM do norte na lista toda são europeias e norte-americanas. Até isso ser corrigido, uma coordenada brasileira ao norte do equador tem de ser convertida na linha de comando, e o gdalsrsinfo -o wkt1 EPSG:31974 imprime PROJCS["SIRGAS 2000 / UTM zone 20N" para você conferir o código antes de confiar nele.
O mesmo erro chega por um segundo caminho, em arquivos e não num seletor: um norte do hemisfério sul que perdeu o seu falso norte. Digite -2605240.90767676 — o norte de São Paulo menos 10.000.000 — com a zona 23S e a resposta é -66.58959006 138.77474853, a costa da Antártida ao sul da Austrália, a 9.981.808 m (9.981,8 km) de distância, linha de ajuda vazia de novo. O indicador de zona automática da própria página reetiqueta o ponto como 54S, e esse indicador, não uma mensagem de erro, é o sinal mais legível que você recebe.
Erro três: nenhuma zona, e uma zona que ele não consegue ler
São dois estados diferentes, e a ferramenta diz duas coisas diferentes. Deixe a caixa Zona vazia e a linha de ajuda mostra Preencha zona, easting e northing para converter., um pedido sem nenhum campo marcado em vermelho: a conversão nem foi tentada. Digite algo que ela não consiga interpretar e você recebe Valores UTM inválidos. — 23 sem letra e zona 23 avermelham apenas a caixa Zona, enquanto 99S, com cara de zona mas sem ser uma, avermelha as três caixas.
Uma ressalva sobre essa caixa, porque é ela que decide se algo do que está acima se aplica a você: quando a Projeção de origem (CRS) já é um código UTM, a caixa Zona não é lida de jeito nenhum. Com SIRGAS 2000 / UTM 23S (EPSG:31983) selecionado, 22S ainda dá a resposta de 23S e 99S a dá sem reclamar, enquanto zona 23 mostra Valores UTM inválidos. em vermelho ao lado de um resultado que está correto. No conversor, ajuste o seletor quando o seletor estiver em um código UTM, e use a caixa Zona quando o CRS de origem for geográfico, como nos casos acima.
Qual é a sua zona
O guia rápido de códigos EPSG responde isso em "Escolhendo uma zona UTM no Brasil", com uma lista "Zona por zona" dos códigos e uma seção sobre os estados que atravessam duas delas. Depois, verifique em vez de confiar: o gdalsrsinfo -o wkt1 EPSG:31983 imprime PROJCS["SIRGAS 2000 / UTM zone 23S" e o vizinho 31984 imprime a zona 24S, então um comando diz se o código nos seus metadados é a zona que você pensa que é.
A armadilha: o mapa ainda desenha, a exportação recusa
Se os metros chegam até você como um Shapefile sem .prj, o visualizador de shapefile os lê como graus e diz isso: a linha de camadas mostra 27 polígonos · CRS desconhecido — assumindo WGS 84. Ele desenha a camada mesmo assim, em algum lugar onde os seus estados não estão, e a imagem na tela não te dá nada para contestar — o sistema de coordenadas foi adivinhado, e o palpite está errado.
A exportação é onde você recebe uma resposta direta. Clique em Exportar GeoJSON e nenhum arquivo é escrito; o visualizador para e diz por quê: Exportação bloqueada: este Shapefile não tem .prj, então suas coordenadas foram lidas como graus e estão fora do intervalo válido de longitude. Defina o CRS correto (por exemplo, com ogr2ogr -a_srs EPSG:31983) e carregue o arquivo novamente. Esse é o diagnóstico e o conserto na mesma mensagem — o rótulo que falta é nomeado, e o comando que o fornece é o -a_srs da próxima seção.
Vale saber o que aquele arquivo teria trazido, porque os mesmos números ainda chegam até você por todos os outros caminhos. O primeiro par dele teria sido [-2171693.959168141, -53.911070387188786]: a longitude é o seu leste, dígito por dígito, e a latitude é um artefato da matemática de Mercator, que empurra o norte por uma tan periódica e devolve algo que parece um lugar de verdade. Esse par foi lido no laboratório de setembro de 2026 por trás do post do .prj que faltou, que tem a reprodução completa, e medido de novo para este post em static-page-tools@79fc1f6, idêntico nos doubles. Uma longitude de −2.171.693 é um número que longitude nenhuma pode ter, e é exatamente esse o teste que a recusa faz.
Leia a recusa em sentido estrito. Ela dispara quando você exporta, e só quando as coordenadas saem da faixa de longitude de ±180° — o que um leste UTM faz por quatro ordens de grandeza e o que uma coordenada em graus de verdade nunca faz, então um arquivo sem .prj cujos números são mesmo graus continua exportando normalmente. Ela não move o seu ponto: a camada continua desenhada no lugar errado e continua marcada como palpite, e o visualizador continua sem ter como saber a que zona os metros pertencem. Ela diz que o arquivo está sem rótulo; ela não o rotula. Encontre a zona no guia rápido e rotule você mesmo.
Atribuir ou reprojetar: dois verbos
O ogr2ogr -a_srs EPSG:31983 fixed.shp in.shp atribui. Antes dele, o ogrinfo -so imprime (unknown) sob Layer SRS WKT:; depois dele, PROJCRS["SIRGAS 2000 / UTM zone 23S", com o mesmo Feature Count: 27, a mesma extensão (-2839536.828905, 6233605.421945) - (2201621.719307, 10603897.119783) e o mesmo primeiro vértice -2171693.95916814 8673426.08892961. Nada se moveu; o arquivo foi rotulado.
O ogr2ogr -s_srs EPSG:31983 -t_srs EPSG:4326 out.shp in.shp reprojeta: a extensão do resultado é (-73.990450, -33.751178) - (-28.847640, 5.271841) e o seu primeiro vértice, -68.792817347 -10.999569268, no Acre. O -s_srs é o que o .prj faltante teria dito; o -t_srs é para onde você quer ir.
Eles não são intercambiáveis, e o -a_srs nunca confere: atribua EPSG:4326 ao mesmo arquivo UTM e o ogr2ogr sai com 0 sem nenhum alerta, deixando uma extensão de ±2,8 milhões de "graus" rotulada como WGS 84. Acerte o código antes de anotá-lo.
Arquivos de teste que você pode usar
A malha de 2022 dos 27 estados brasileiros do IBGE, 13.717.460 bytes, SHA-256 282ec7f0f0beeeead45e6609f4ffffce161bda04cb8ee0afcad2316d1c841bcb. O diretório de download não traz uma linha de licença própria, então dê o crédito ao IBGE e confira os termos do portal antes de republicar.
Para montar a variante quebrada usada acima, projete-a uma vez com ogr2ogr -f "ESRI Shapefile" utm/BR_UF_2022_utm.shp shp/BR_UF_2022.shp -t_srs EPSG:31983, depois solte o .shp, o .shx e o .dbf resultantes no visualizador sem o .prj.
Para times
Um número de zona viaja num nome de arquivo, num e-mail ou na memória de alguém, e o mapa que recebe o arquivo não tem como perguntar. O Geodocs mantém o sistema de coordenadas preso aos dados num mapa compartilhado, então a equipe de campo coleta e o escritório lê num único CRS, e a letra do hemisfério nunca é algo que alguém precise lembrar de digitar.