Shapefile en el lugar equivocado (o en el océano): falta el .prj
Respuesta corta: el archivo no tiene .prj, así que nada sabe qué significan sus números. El .shp guarda dobles sin más; el .prj que va al lado es lo único que dice si son grados o metros UTM. Sin él, GDAL no imprime ningún sistema de coordenadas, QGIS te pregunta por un CRS, y el visor del navegador asume WGS 84 y lo dice — lo que coloca un archivo geográfico en el lugar correcto y uno en UTM fuera del borde del mundo, con el mismo mensaje en los dos casos. Abajo: cómo distinguir cuál tenés mirando los números, y las dos líneas de ogr2ogr que lo arreglan, que no son intercambiables.
Todo esto se probó el 16 de septiembre de 2026 con GDAL 3.13.3 y el visor de Shapefile, con su mensaje de .prj faltante de septiembre de 2026, que todavía no estaba publicado al momento de escribir esto. El dataset es la malla 2022 del IBGE con los 27 estados brasileños en coordenadas geográficas SIRGAS 2000, convertida una vez a SIRGAS 2000 / UTM zona 23S para que los mismos 27 polígonos existan en grados y en metros. La guía de Shapefile cubre el archivo lateral en "Si falta el .prj"; este post es la reproducción y el arreglo.
Tres herramientas, tres comportamientos
GDAL no adivina: ogrinfo -so en la capa UTM con el .prj borrado igual reporta Feature Count: 27 y la extensión en metros, y después imprime Layer SRS WKT: con (unknown) en la línea siguiente. QGIS, con su configuración de CRS por defecto, te pide un CRS cuando agregás la capa. El visor lee los números como grados WGS 84 y agrega un aviso a la fila de la capa. El aviso es nuevo — sin desplegar cuando esto se escribió y desplegado 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 fila te avisa.
Cuatro variantes en el visor
Cada variante se soltó en el visor y se exportó con Exportar GeoJSON; el primer vértice de Acre en esa exportación es el oráculo de ubicación, porque es la geometría que dibujó el propio visor, proyectada de vuelta a grados.
- El zip UTM con su
.prj: la fila muestra27 polígonos, el mapa muestra Brasil, y el primer par exportado es[-68.7928173712301, -10.999569659337354]. El-t_srs EPSG:4326de GDAL para el mismo vértice da[-68.792817347, -10.999569268]. El vértice del visor está a 0,0436 m del de GDAL — los dos tratan SIRGAS 2000 → WGS 84 como una transformación nula (PROJ la califica en 1 m:EPSG:15894,+proj=noop), y los 4 cm son enteramente la propia grilla 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 fila muestra27 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 exportado es[-2171693.959168141, -53.911070387188786]: la longitud exportada es tu easting, dígito por dígito — el.shpguarda-2171693.959168141, 8673426.088929612para 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 a unas 6.032 vueltas al planeta hacia el oeste. El mensaje es la única pista, porque el mapa se ve normal. - Los mismos tres archivos soltados sueltos, sin zipear: idéntico al zip — la misma fila, el mismo mapa transparente, una exportación idéntica byte por byte. Esa paridad también es nueva: hasta el cambio de septiembre de 2026, los archivos sueltos sin
.prjse dibujaban como metros Web Mercator crudos sobre un lienzo gris con el mapa base oculto, lo que dejaba 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 fila lleva el mismo aviso, y la forma está en Brasil. El primer par de su exportación es[-68.7928173712301, -10.999569659337354], bit por bit el mismo par del zip original del IBGE sin tocar. Funciona, y el visor te dice que adivinó: la suposición es correcta porque el archivo tiene grados, y el mensaje está ahí para que una adivinanza afortunada no se confunda con un CRS conocido.
Cómo saber en qué CRS está un archivo sin .prj
Mirá los números antes que el mapa. Los valores dentro de ±180 y ±90 son grados, y la suposición del visor es correcta. Los valores de seis o siete dígitos son metros proyectados, y la suposición es incorrecta: un easting UTM dentro de su zona queda entre 166.000 y 834.000, un northing del hemisferio sur llega hasta 10.000.000 por el false northing, y un archivo que abarca varias zonas, como este, tiene eastings que se vuelven negativos o superan el millón (los de esta capa van de −2.839.536 a 2.201.621). Los metros de Web Mercator llegan a unos 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, es tu easting, y el archivo estaba proyectado. Después buscá la zona — la hoja de referencia de EPSG lista los códigos para Brasil y América Latina.
Asignar o reproyectar: dos comandos, dos verbos
Asignar dice lo que los números ya son; reproyectar los cambia. 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: el ogrinfo -so del resultado imprime PROJCRS["SIRGAS 2000 / UTM zone 23S" terminando en ID["EPSG",31983], la extensión no cambia, y el primer vértice sigue siendo -2171693.95916814 8673426.08892961. Soltado en el visor, el archivo asignado cae en Brasil con la fila de vuelta en 27 polígonos y sin aviso. ogr2ogr -s_srs EPSG:31983 -t_srs EPSG:4326 out.shp in.shp hace el otro trabajo: -s_srs es lo que el .prj faltante habría dicho, -t_srs es adónde querés ir, y el 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 mismo double guardado del archivo original, recuperado. Asignale a un archivo que ya está en grados y le mentiste; reproyectá con el -s_srs equivocado y cada vértice se mueve a un lugar equivocado que un .prj ahora avala. Revisá el código primero: 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, arreglá el .prj antes de exportar — y si ya exportaste, la columna de longitud es tu easting, sin cambios.
La misma falla en GeoJSON
Un GeoJSON con un miembro crs que nombra EPSG:31983 falla de la misma manera en el navegador: el miembro no se entiende, la transformación se salta, y el primer vértice de 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 podés usar
El dataset es la malla de estados 2022 del IBGE, 13.717.460 bytes, SHA-256 282ec7f0f0beeeead45e6609f4ffffce161bda04cb8ee0afcad2316d1c841bcb; el listado del directorio no imprime ninguna línea de licencia, así que dale crédito al IBGE y revisá los términos del portal antes de republicar.
Para crear la variante rota, proyectalo con ogr2ogr -f "ESRI Shapefile" -t_srs EPSG:31983 -lco ENCODING=UTF-8 utm/BR_UF_2022_utm.shp BR_UF_2022.shp, y después borrá utm/BR_UF_2022_utm.prj y soltá los otros tres archivos en el visor, zipeados o sueltos. El -lco ENCODING=UTF-8 está ahí por una razón que queda fuera de este post: sin él, ogr2ogr escribe una tabla de atributos en Latin-1 sin .cpg, y las tildes de 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, una carpeta copiada, una exportación que nunca lo escribió — y el mapa que recibe el archivo no le puede preguntar a quien lo mandó. Geodocs mantiene el sistema de coordenadas junto con los datos en un mapa compartido, así el equipo dibuja y recolecta en un solo CRS y la pregunta solo aparece al exportar, cuando ya sabés la respuesta.