Shapefile en el lugar equivocado (o en el océano): el .prj ausente

Respuesta corta: el archivo no tiene .prj, así que nada sabe qué significan tus números. El .shp guarda doubles desnudos; el .prj al lado es lo único que dice si son grados o metros UTM. Sin él, GDAL no imprime ningún sistema de coordenadas, QGIS pregunta por un CRS, y el visor del navegador asume WGS 84 y advierte sobre ello — lo que coloca un archivo geográfico en el lugar correcto y un archivo UTM fuera del borde del mundo, con el mismo mensaje en ambos casos. A continuación: cómo saber cuál de los dos tienes solo por los números, y las dos líneas de ogr2ogr que resuelven esto, que no son intercambiables.

Todo fue probado el 16 de septiembre de 2026 con GDAL 3.13.3 y el shapefile-viewer en la versión static-page-tools@442f8d8, con su mensaje de septiembre de 2026 para archivos sin .prj, aún no publicado en el momento en que este texto fue escrito. El dataset es la malla de 2022 del IBGE de los 27 estados brasileños en coordenadas geográficas SIRGAS 2000, convertida una vez a SIRGAS 2000 / UTM zona 23S, de modo que los mismos 27 polígonos existen en grados y en metros. La guía del Shapefile cubre este archivo satélite en "Si falta el .prj"; este post es la reproducción y la corrección.

Tres herramientas, tres comportamientos

GDAL no adivina: ogrinfo -so en la capa UTM con el .prj borrado aún reporta Feature Count: 27 y la extensión en metros, y luego imprime Layer SRS WKT: con (unknown) en la línea siguiente. QGIS, con su configuración por defecto de CRS, pregunta por un CRS cuando añades la capa. El visor lee los números como grados WGS 84 y añade una advertencia en la línea de la capa. La advertencia es nueva — aún no estaba publicada cuando esto se escribió y se publica antes de este post — pero la suposición no lo es: un zip sin .prj siempre se leyó como grados; lo que cambió es que ahora la línea avisa.

Cuatro variaciones en el visor

Cada variación fue soltada en el visor y exportada con Exportar GeoJSON; el primer vértice del Acre en esa exportación es el oráculo de posición, porque es la propia geometría dibujada por el visor proyectada de vuelta a grados.

• Zip UTM con su .prj: la línea lee 27 polígonos, el mapa muestra Brasil, y el primer par de la exportación es [-68.7928173712301, -10.999569659337354]. El -t_srs EPSG:4326 del GDAL para el mismo vértice da [-68.792817347, -10.999569268]. El vértice del visor queda a 0,0436 m del vértice del GDAL — ambos tratan SIRGAS 2000 → WGS 84 como una transformación nula (PROJ evalúa esto en 1 m: EPSG:15894,+proj=noop), y los 4 cm son enteramente de la propia rejilla de dibujo de 0,2 m del visor: el vértice exportado en Web Mercator es un múltiplo exacto de 0,2 m en los dos ejes.
• El mismo zip sin su .prj: la línea lee 27 polígonos · CRS desconocido — asumiendo WGS 84, el mapa base sigue visible, y no se dibuja nada donde debería estar Brasil. El primer par de la exportación es [-2171693.959168141, -53.911070387188786]: la longitud exportada es tu easting, dígito por dígito — el .shp almacena -2171693.959168141, 8673426.088929612 para ese vértice — y la latitud es un artefacto de la matemática de Mercator, que es periódica en el northing y devolvió un valor que parece una latitud real en la Patagonia. Un easting de −2.171.693 leído como grados cae como unas 6.032 vueltas alrededor del planeta, hacia el oeste. El mensaje es el único indicio, porque el mapa parece normal.
• Los mismos tres archivos sueltos, no zipeados: idéntico al zip — la misma línea, el mismo mapa transparente, una exportación byte a byte idéntica. Esa paridad también es nueva: hasta el cambio de septiembre de 2026, archivos sueltos sin .prj eran dibujados como metros brutos en Web Mercator sobre una pantalla gris con el mapa base oculto, lo que ponía un archivo en grados en una caja de 45 m por 39 m junto al origen, irreconocible y sin ningún mensaje.
• El archivo geográfico sin su .prj: la línea muestra la misma advertencia, y la forma está en Brasil. El primer par de su exportación es [-68.7928173712301, -10.999569659337354], bit a bit el mismo par del zip original del IBGE. Funciona, y el visor avisa que supuso: la suposición está correcta porque grados es lo que el archivo contiene, y el mensaje existe para que una suposición afortunada no se confunda con un CRS conocido.

Cómo saber el CRS de un archivo sin .prj

Mira los números antes del mapa. Valores dentro de ±180 y ±90 son grados, y la suposición del visor está bien. Valores de seis o siete dígitos son metros proyectados, y la suposición está equivocada: un easting UTM dentro de su zona queda entre 166.000 y 834.000, un northing del hemisferio sur llega a 10.000.000 por la false northing, y un archivo que atraviesa varias zonas, como este, tiene eastings que se vuelven negativas o pasan de un millón (en esta capa, de −2.839.536 a 2.201.621). Metros en Web Mercator llegan a cerca de 20.037.508. Exportar y mirar es un diagnóstico de un solo paso: si el visor dice que asumió WGS 84 y la longitud exportada es un número de seis o siete dígitos, eso es tu easting, y el archivo estaba proyectado. Luego, encuentra la zona — la guía de códigos EPSG lista los códigos de Brasil y de América Latina.

Atribuir o reproyectar: dos comandos, dos verbos

Atribuir dice qué son ya los números; reproyectar cambia los números. En el archivo cuyo ogrinfo -so imprimió (unknown) bajo Layer SRS WKT:, ogr2ogr -a_srs EPSG:31983 fixed.shp in.shp escribe un .prj y no mueve nada: ogrinfo -so en el resultado imprime PROJCRS["SIRGAS 2000 / UTM zone 23S" terminando en ID["EPSG",31983], la extensión continúa igual, y el primer vértice sigue siendo -2171693.95916814 8673426.08892961. Soltado de nuevo en el visor, el archivo con el CRS atribuido cae en Brasil con la línea de vuelta a 27 polígonos y sin advertencia. ogr2ogr -s_srs EPSG:31983 -t_srs EPSG:4326 out.shp in.shp hace el otro trabajo: -s_srs es lo que el .prj que falta habría dicho, -t_srs es adónde quieres ir, y ogrinfo -so del resultado muestra GEOGCRS["WGS 84" con la extensión en grados y el primer vértice en -68.792817347 -10.999569268 — el double almacenado en el archivo de origen, recuperado. Atribuye un archivo que ya está en grados y le mentiste; reproyecta con -s_srs equivocado y cada vértice se mueve a un lugar incorrecto que ahora tiene un .prj como aval. Revisa el código antes: gdalsrsinfo -o wkt1 EPSG:31983 | grep -m1 -o '^\(GEOGCS\|PROJCS\)\["[^"]*"' imprime PROJCS["SIRGAS 2000 / UTM zone 23S"; el vecino 31984 imprime la zona 24S.

Si el visor dice que asumió WGS 84 y la forma no está donde debería, corrige el .prj antes de exportar — y si ya exportaste, la columna de la longitud es tu easting, sin alteración.

La misma falla en GeoJSON

Un GeoJSON con un miembro crs nombrando EPSG:31983 falla de la misma forma en el navegador: el miembro no es entendido, la transformación se ignora, y el primer vértice del Acre se exporta en [-19.5086591263066, 61.20664023081724], en el Atlántico Norte — la guía de GeoJSON explica en "El miembro CRS desapareció" por qué el formato ya no tiene ese miembro.

Archivos de prueba que puedes usar

El dataset es la malla estatal de 2022 del IBGE, 13.717.460 bytes, SHA-256 282ec7f0f0beeeead45e6609f4ffffce161bda04cb8ee0afcad2316d1c841bcb; el listado del directorio no imprime ninguna línea de licencia, así que acredita al IBGE y revisa los términos del portal antes de republicar.

https://geoftp.ibge.gov.br/organizacao_do_territorio/malhas_territoriais/malhas_municipais/municipio_2022/Brasil/BR/BR_UF_2022.zip

Para generar la variante rota, proyecta el archivo con ogr2ogr -f "ESRI Shapefile" -t_srs EPSG:31983 -lco ENCODING=UTF-8 utm/BR_UF_2022_utm.shp BR_UF_2022.shp, luego borra utm/BR_UF_2022_utm.prj y suelta los otros tres archivos en el visor, zipeados o sueltos. El -lco ENCODING=UTF-8 está ahí por un motivo fuera de este post: sin él ogr2ogr escribe una tabla de atributos en Latin-1 sin .cpg, y los acentos en los nombres de los estados se rompen en el navegador — un problema de .cpg, no de .prj.

Para equipos

Un .prj se pierde en un adjunto de chat, en una carpeta copiada, en una exportación que nunca lo escribió — y el mapa que recibe el archivo no puede preguntar a quien lo envió. Geodocs mantiene el sistema de coordenadas junto con los datos en un mapa compartido, así que el equipo dibuja y recoge en un único CRS y la pregunta solo aparece en la exportación, cuando ya sabes la respuesta.