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 caso en el que hoy el propio conversor se equivoca, 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 en static-page-tools@79fc1f6 — 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 ese commit. 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: el hemisferio que la casilla Zona no puede decir

Acá la herramienta se equivoca, y conviene que lo sepas antes de confiar en ella. La casilla Zona acepta una letra, pero para los números de zona 17 a 25 la letra se descarta: 23N y 23n devuelven las dos -23.54890000 -46.63880000, la respuesta de 23S, byte por byte, con la línea de ayuda vacía, y el resultado de solo lectura te repite 23S. Fuera de esa franja la letra funciona — 16N y 16S difieren, y 26N y 26S también. Las zonas 17 a 25 son exactamente Brasil.

Eso cuesta un punto real. 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 -86.38145844 -23.14479495 — a 400 km del Polo Sur, a 10.002.260 m (10.002,3 km) de Boa Vista, sin ningún mensaje de ninguna clase. 20S devuelve el par idéntico, lo que prueba que lo que se descarta es la letra y no la aritmética, y GDAL reproduce la misma lectura errónea hasta el octavo decimal cuando le pasás EPSG:31980, zona 20S, a propósito. El selector no te saca del apuro: su grupo Brasil es enteramente del sur, y las únicas cuatro entradas UTM del norte de toda la lista son europeas y norteamericanas. Hasta que eso se arregle, una coordenada brasileña al norte del ecuador hay que convertirla en la línea de comandos, y gdalsrsinfo -o wkt1 EPSG:31974 imprime PROJCS["SIRGAS 2000 / UTM zone 20N" para que puedas revisar el código antes de confiar en él.

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 salvedad 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, la casilla Zona no se lee en absoluto. Con SIRGAS 2000 / UTM 23S (EPSG:31983) seleccionado, 22S sigue dando la respuesta de 23S y 99S la da sin quejarse, mientras que zona 23 muestra Valores UTM inválidos. en rojo al lado de un resultado que está bien. En el conversor, usá el selector cuando el selector está en un código UTM, y usá la casilla Zona cuando el CRS de origen es geográfico, como en los casos de arriba.

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 en static-page-tools@79fc1f6, 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.

Artículos Relacionados

Navegação