UTM a latitud y longitud: la zona, el hemisferio y el punto a 611 km
Respuesta corta: un easting y un northing son metros medidos dentro de una única zona de 6° de ancho, así que sin el número de zona y la letra del hemisferio no son una ubicación. Dale los dos al conversor de coordenadas y el punto cae sobre sí mismo; cambiá la zona en uno y se corre 611.563 m — 611,563 km — al este o al oeste sobre el mismo paralelo; sacá el falso norte de 10.000.000 m y los mismos metros caen a 9.981.808 m de distancia, en la costa antártica. Abajo: los tres errores — el segundo es la letra del hemisferio que el conversor ahora sí lee, y lo que la letra equivocada todavía te cuesta — y la exportación que se niega a devolverte tu easting como longitud.
Cada número de abajo se midió el 23 de septiembre de 2026 con GDAL 3.13.3, PROJ 9.8.1 y las dos herramientas de navegador — salvo las dos constantes de proyección de la sección siguiente, que son definiciones y no lecturas, y el rechazo de la exportación más abajo, que entró después de esa medición. Las lecturas de zona y hemisferio de "Error dos" y "Error tres" se volvieron a medir el 28 de septiembre de 2026, después de que el conversor empezara a resolver la letra del hemisferio y el selector ganara las zonas del norte de Brasil. El punto de referencia es São Paulo, -46.6388 -23.5489 en SIRGAS 2000, cuyos metros UTM 23S son 332724.396065356 7394759.09232324: gdaltransform convierte uno en el otro y de vuelta sin mover un solo dígito impreso, así que cada distancia de abajo es el error y nada más.
Qué deja afuera un par UTM
UTM parte el mundo en sesenta zonas de 6° de longitud de ancho y mide metros dentro de cada una. Dos constantes mantienen esos metros positivos, y las dos son parámetros de la proyección y no algo que este post haya medido: el meridiano central de cada zona recibe un falso este de 500.000 m, y las zonas al sur del ecuador suman un falso norte de 10.000.000 m, cosa que las del norte no hacen. El falso este es además de donde sale el rango que tenés que esperar, y es una cuenta que podés hacer vos mismo — una zona llega a 3° a cada lado de su meridiano central, y 3° de longitud son unos 334 km en el ecuador y menos cuanto más lejos estés de él, así que un easting dentro de su propia zona queda a unos 334 km de la línea central de 500.000 m: entre unos 166.000 y 834.000 en el caso más ancho. Entonces 332724.396065356 7394759.09232324 es una respuesta completa solo cuando además decís 23 y S — los mismos dos números son un punto válido en cada una de las sesenta zonas y en los dos hemisferios, y nada en el archivo ni en la celda de la planilla dice cuál. La tarjeta UTM del conversor pide las tres cosas: Zona, Este (E) y Norte (N).
Error uno: la zona equivocada
Con Proyección de origen (CRS) en SIRGAS 2000 (EPSG:4674) y Proyección destino (CRS) en WGS 84 (EPSG:4326), la casilla Zona es la que decide, y los mismos metros bajo tres zonas dan tres respuestas: 22S devuelve -23.54890000 -52.63880000, 23S devuelve -23.54890000 -46.63880000, 24S devuelve -23.54890000 -40.63880000. La latitud no se mueve nada. La longitud se corre exactamente 6° por zona — un ancho de zona — que a la latitud de São Paulo son 611.563 m medidos sobre una esfera, o 612.575 m sobre el elipsoide GRS80; cada distancia de este post es la esférica salvo que diga otra cosa. gdaltransform -s_srs EPSG:31982 -t_srs EPSG:4674 y sus vecinos EPSG:31983 y EPSG:31984 imprimen los mismos tres pares, dígito por dígito.
No hay ningún mensaje de por medio — la línea de ayuda debajo de la tarjeta UTM queda vacía en los tres casos — y una zona equivocada no desparrama tus datos: los corre de costado sobre un paralelo verosímil, que es por lo que nadie lo detecta en el mapa.
Error dos: la letra del hemisferio, y lo que cuesta la equivocada
La casilla Zona lee la letra, y la lee en todas partes. Los mismos metros de São Paulo bajo 23S devuelven -23.54890000 -46.63880000; bajo 23N — y bajo 23n, porque a la casilla no le importan las mayúsculas — devuelven 66.62602328 -48.78030358, que queda en Groenlandia, porque ese es el mismo northing contado desde el ecuador hacia arriba y no hacia abajo. 16N y 16S también difieren, y 26N y 26S igual. La letra elige además el datum: dentro de Brasil la letra del sur resuelve al código SIRGAS 2000 de esa zona, y de la zona 17 a la zona 22 la letra del norte ahora hace lo mismo — 20N resuelve a EPSG:31974. Arriba de la zona 22 la lista SIRGAS del norte del conversor se termina, y la letra cae a la zona WGS 84 de ese número: el mismo lugar en el terreno, un datum distinto en tus metadatos.
Eso vale una letra. Boa Vista, en Roraima, está en -60.6714 2.8235, al norte del ecuador, en la zona 20N; gdaltransform -s_srs EPSG:4674 -t_srs EPSG:31974 da sus metros como 758873.827731744 312343.360559676. Tipeados en el conversor con esa zona correcta 20N, la respuesta es 2.82350000 -60.67140000 — Boa Vista, dígito por dígito. Tipeá 20S en su lugar, una letra, y la respuesta es -86.38145844 -23.14479495 — a 400 km del Polo Sur, a 10.002.260 m (10.002,3 km) de donde querías, sin ningún mensaje de ninguna clase, porque una zona 20 del sur es un lugar real y nada en tus metros dice que no la quisiste. GDAL imprime la misma lectura hasta el octavo decimal cuando le pasás EPSG:31980, zona 20S, a propósito. El selector ahora te lleva la letra: SIRGAS 2000 / UTM 20N (EPSG:31974) está en su grupo Brasil, al lado de las zonas del sur, y elegirlo llena la casilla Zona y la traba. Revisá el código de una manera o de la otra — gdalsrsinfo -o wkt1 EPSG:31974 imprime PROJCS["SIRGAS 2000 / UTM zone 20N".
El mismo error llega de una segunda manera, en archivos y no en un selector: un northing del sur que perdió su falso norte. Meté -2605240.90767676 — el northing de São Paulo menos 10.000.000 — con la zona 23S y la respuesta es -66.58959006 138.77474853, la costa antártica al sur de Australia, a 9.981.808 m (9.981,8 km) de distancia, otra vez con la línea de ayuda vacía. La lectura de zona automática de la propia página vuelve a etiquetar el punto como 54S, y esa lectura, y no un mensaje de error, es la señal más legible que vas a tener.
Error tres: ninguna zona, y una zona que no puede leer
Son dos estados distintos, y la herramienta dice dos cosas distintas. Dejá la casilla Zona vacía y la línea de ayuda dice Completa zona, easting y northing para convertir., una indicación sin ningún campo marcado en rojo: la conversión ni siquiera se intentó. Escribí algo que no pueda interpretar y en cambio obtenés Valores UTM inválidos. — 23 sin letra y zona 23 ponen en rojo solo la casilla Zona, mientras que 99S, con forma de zona pero sin serlo, pone en rojo las tres casillas.
Una cosa sobre esa casilla, porque define si algo de lo anterior te aplica: cuando Proyección de origen (CRS) es de por sí un código UTM, el selector ya carga la zona y la casilla deja de aceptar texto. Elegí SIRGAS 2000 / UTM 23S (EPSG:31983) y la casilla Zona se llena sola con 23S y queda de solo lectura — tipeá 22S adentro y sigue diciendo 23S, y ningún error aparece al lado de un resultado correcto, porque no quedó nada para discrepar. La casilla vuelve a estar viva en el momento en que el CRS de origen es geográfico: de vuelta en SIRGAS 2000 (EPSG:4674), un 22S tipeado corre el punto 6° y 99S pone en rojo la tarjeta con Valores UTM inválidos. en la línea de ayuda. Así que en el conversor hay una regla y no dos — la zona viene de aquel de los dos campos en el que te dejan escribir.
Cuál es tu zona
La hoja de referencia de EPSG lo responde en "Cómo elegir una zona UTM en Brasil", con una lista de códigos "Zona por zona" y una sección sobre los estados que abarcan dos. Después verificá en vez de confiar: gdalsrsinfo -o wkt1 EPSG:31983 imprime PROJCS["SIRGAS 2000 / UTM zone 23S" y el vecino 31984 imprime la zona 24S, así que un solo comando te dice si el código de tus metadatos es la zona que creés.
La trampa: el mapa igual lo dibuja, la exportación lo rechaza
Si los metros te llegan como un Shapefile sin .prj, el visor de Shapefile los lee como grados y lo dice: la fila de capas muestra 27 polígonos · CRS desconocido — asumiendo WGS 84. Igual dibuja la capa, en algún lugar donde tus estados no están, y la imagen en pantalla no te da nada para discutir — el sistema de coordenadas se adivinó, y la adivinanza está mal.
La exportación es donde obtenés una respuesta directa. Hacé clic en Exportar GeoJSON y no se escribe ningún archivo; el visor se detiene y dice por qué: Exportación bloqueada: este Shapefile no tiene .prj, por lo que sus coordenadas se leyeron como grados y quedan fuera del rango válido de longitud. Asigna el CRS correcto (por ejemplo, con ogr2ogr -a_srs EPSG:31983) y vuelve a cargar el archivo. Ese es el diagnóstico y el arreglo en el mismo mensaje — la etiqueta que falta queda nombrada, y el comando que la aporta es el -a_srs de la sección siguiente.
Vale la pena saber qué habría traído ese archivo, porque los mismos números te siguen llegando por cualquier otra vía. Su primer par habría sido [-2171693.959168141, -53.911070387188786]: la longitud es tu easting, dígito por dígito, y la latitud es un artefacto de la matemática de Mercator, que empuja el northing a través de una tan periódica y devuelve algo que parece un lugar real. Ese par se leyó en el laboratorio de septiembre de 2026 detrás del post del .prj ausente, que tiene la reproducción completa, y se volvió a medir para este post, idéntico en los dobles. Una longitud de −2.171.693 es un número que ninguna longitud puede ser, y ese es exactamente el test que hace el rechazo.
Leé el rechazo en sentido estricto. Se dispara cuando exportás, y solo cuando las coordenadas salen del rango de longitud de ±180° — algo que un easting UTM hace por cuatro órdenes de magnitud y que una coordenada en grados de verdad nunca hace, así que un archivo sin .prj cuyos números sí son grados sigue exportando con normalidad. No mueve tu punto: la capa sigue dibujada en el lugar equivocado y sigue marcada como una adivinanza, y el visor sigue sin poder saber a qué zona pertenecen los metros. Te dice que el archivo está sin etiquetar; no lo etiqueta. Buscá la zona en la hoja de referencia y etiquetalo vos.
Asignar o reproyectar: dos verbos
ogr2ogr -a_srs EPSG:31983 fixed.shp in.shp asigna. Antes, ogrinfo -so imprime (unknown) bajo Layer SRS WKT:; después, PROJCRS["SIRGAS 2000 / UTM zone 23S", con el mismo Feature Count: 27, la misma extensión (-2839536.828905, 6233605.421945) - (2201621.719307, 10603897.119783) y el mismo primer vértice -2171693.95916814 8673426.08892961. Nada se movió; el archivo quedó etiquetado.
ogr2ogr -s_srs EPSG:31983 -t_srs EPSG:4326 out.shp in.shp reproyecta: la extensión del resultado es (-73.990450, -33.751178) - (-28.847640, 5.271841) y su primer vértice -68.792817347 -10.999569268, en Acre. -s_srs es lo que habría dicho el .prj faltante; -t_srs es adónde querés ir.
No son intercambiables, y -a_srs nunca controla: asignale EPSG:4326 al mismo archivo UTM y ogr2ogr sale con 0 y sin ninguna advertencia, dejando una extensión de ±2,8 millones de "grados" etiquetada como WGS 84. Acertá el código antes de escribirlo.
Archivos de prueba que podés usar
La malla 2022 del IBGE con los 27 estados brasileños, 13.717.460 bytes, SHA-256 282ec7f0f0beeeead45e6609f4ffffce161bda04cb8ee0afcad2316d1c841bcb. El directorio de descarga no trae una línea de licencia propia, así que acreditá al IBGE y revisá los términos del portal antes de republicar.
Para armar la variante rota que se usó arriba, proyectalo una vez con ogr2ogr -f "ESRI Shapefile" utm/BR_UF_2022_utm.shp shp/BR_UF_2022.shp -t_srs EPSG:31983, y después soltá el .shp, el .shx y el .dbf resultantes en el visor sin el .prj.
Para equipos
Un número de zona viaja en un nombre de archivo, en un correo o en la memoria de alguien, y el mapa que recibe el archivo no puede preguntar. Geodocs mantiene el sistema de coordenadas pegado a los datos en un mapa compartido, así que el equipo de campo releva y la oficina lee en un solo CRS, y la letra del hemisferio nunca es algo que alguien tenga que acordarse de tipear.