Falta el .shx o el .dbf: por qué no abre el Shapefile (y qué hace cada archivo)
Tres archivos son el Shapefile: .shp, .shx y .dbf. Todo lo demás con el mismo nombre base (.prj, .cpg, .sbn, .qix, .shp.xml) es un archivo lateral. Cuando "el Shapefile no abre", falta uno de los tres, y cuál decide qué ves: sin .shx GDAL se niega mientras el navegador abre el archivo como si nada pasara; sin .dbf todo abre con cero atributos y sin aviso; sin .shp no hay nada para abrir. Abajo, qué es cada archivo, si podés reconstruirlo, y qué dicen el shapefile-viewer y ogrinfo cuando falta.
Probado el 16 de septiembre de 2026 contra el shapefile-viewer en vivo en static-page-tools@442f8d8 y GDAL 3.13.3 "Iowa City", sobre los límites estatales 2022 del IBGE (27 polígonos, cinco campos), soltados como zip y como archivos sueltos. La sección "Qué es un Shapefile" de la Guía de Shapefile describe cada archivo byte por byte; este post es sobre lo que se rompe.
Un párrafo por archivo
.shp es la geometría: cada registro es un código de tipo de forma seguido de coordenadas. Obligatorio, porque es el dato, y no se puede regenerar a partir de nada más. En el navegador es el único archivo que tiene que existir.
.shx es un índice de ancho fijo: para cada registro, su desplazamiento en bytes dentro del .shp. La especificación de 1998 lo llama obligatorio y GDAL lo trata así; el navegador nunca lo lee (el parser shpjs recorre el .shp de forma secuencial). Es una función pura del .shp, así que es totalmente regenerable: GDAL reconstruyó el .shx de 316 bytes del IBGE idéntico byte a byte al original (caso 2).
.dbf es la tabla de atributos, en formato dBASE; el registro n del .dbf es la entidad n del .shp. La especificación lo llama obligatorio, pero GDAL y el navegador abren la capa sin él igual, en silencio, con cero campos. No es regenerable: los atributos no viven en ningún otro lado.
.prj es un archivo de texto de una línea con el sistema de referencia de coordenadas en WKT. Opcional en la especificación, obligatorio en la práctica: sin él GDAL reporta Layer SRS WKT: como (unknown) y nada sabe si los números son grados o metros. Regenerable solo si conocés el CRS (ogr2ogr -a_srs), el tema del primer post de esta serie.
.cpg es un archivo de una línea que nombra la codificación del .dbf (la del IBGE dice UTF-8, cinco bytes). Opcional; regenerable si conocés la codificación (echo UTF-8 > BR_UF_2022.cpg). El segundo post de esta serie es sobre lo que sale mal sin él.
.sbn y .sbx (el índice espacial de ESRI, escrito por ArcGIS y nunca por GDAL), .qix (el índice espacial abierto de GDAL, QGIS y MapServer) y .shp.xml (metadatos de ArcGIS) son opcionales, regenerables o descartables, y ninguno lo lee el visor del navegador.
Qué se ve en cada archivo faltante
El conjunto completo (caso 1)
El zip y los archivos sueltos dan la misma fila en el visor: 27 polígonos y 5 campos, CRS GCS_SIRGAS_2000 en Detalles, GeoJSON exportado que arranca en [-68.7928173712301, -10.999569659337354]. GDAL: Feature Count: 27, GEOGCRS["SIRGAS 2000", cinco campos. Cada caso de abajo es este conjunto menos un archivo; "abre" significa que la fila y la exportación son idénticas a esta.
Sin .shx (caso 2)
En el visor, nada cambia. Zip o suelto, la fila y la exportación son idénticas a las del conjunto completo. El parser nunca abre el .shx, y la ruta de archivos sueltos ni siquiera lo busca, así que el navegador es una forma rápida de confirmar que el .shp en sí está sano.
GDAL se niega, y dice por qué: ERROR 4: Unable to open cases/2-no-shx/BR_UF_2022.shx or cases/2-no-shx/BR_UF_2022.SHX. Set SHAPE_RESTORE_SHX config option to YES to restore or create it. El arreglo es el que nombra: ogrinfo -so BR_UF_2022.shp BR_UF_2022 --config SHAPE_RESTORE_SHX YES abre la capa (27 registros, cinco campos) y aparece un BR_UF_2022.shx de 316 bytes al lado del .shp. Comparado con el original del IBGE usando cmp: idéntico byte a byte. SHAPE_RESTORE_SHX es una opción de --config, no una opción de apertura del driver. La sección "Errores, decodificados" de la Guía de Shapefile cita la misma línea.
Sin .dbf (caso 3)
El visor lo abre y no dice nada. La fila muestra 27 polígonos y 0 campos, el CRS se muestra, no hay aviso, y la exportación es la misma geometría con "properties": null en cada entidad; zip y suelto se comportan igual. La propia descripción de la herramienta lo admite: "Un .shp individual muestra solo la geometría, sin atributos."
GDAL la abre y tampoco dice nada. ogrinfo -so imprime Feature Count: 27 y el CRS sin líneas de campos y sin metadato DBF_DATE_LAST_UPDATE; -fid 0 imprime el polígono sin atributos. No hay arreglo: el .dbf no se puede reconstruir a partir de la geometría, así que pedile el conjunto completo a quien exportó la capa.
Sin .shp (caso 4)
El visor se detiene con un aviso: No se encontró ningún archivo .shp. Arrastra un .shp o un ZIP que contenga uno. La misma cadena aparece ya sea que los archivos restantes vengan como zip o como archivos sueltos.
GDAL no puede abrir una capa (ogrinfo BR_UF_2022.shp termina en No such file or directory), pero abre el .dbf huérfano como tabla: ogrinfo BR_UF_2022.dbf reporta Geometry: None, Feature Count: 27, Layer SRS WKT: (unknown) y los cinco campos, y -fid 0 imprime NM_UF (String) = Acre. Los atributos sobreviven a la pérdida del .shp; la geometría no.
Sin .prj (caso 5)
Un .prj faltante es una falla distinta, la capa abre y nada sabe qué significan sus coordenadas, y tiene su propio post: Shapefile en el lugar equivocado: falta el .prj.
Falta o está mal el .cpg (caso 6)
Un .cpg faltante o incorrecto no impide que nada abra; convierte los acentos en é, y ese es el segundo post: Shapefile con acentos incorrectos: .cpg, Latin-1 y UTF-8.
El zip de macOS (caso 7)
Un zip hecho en Finder trae una carpeta __MACOSX/ con un archivo ._BR_UF_2022.shp de metadatos por cada archivo (datos de resource fork del Finder, no una copia). El visor salta cada entrada __MACOSX, así que un zip cuyo único .shp es ese archivo de metadatos recibe el mismo aviso que el caso 4: No se encontró ningún archivo .shp. Arrastra un .shp o un ZIP que contenga uno. Con los archivos reales al lado de la carpeta (el zip típico de Finder) abre exactamente igual que el conjunto completo. GDAL coincide: el zip con solo los archivos de metadatos es not recognized as being in a supported file format; el completo lista BR_UF_2022 (Polygon) a través de /vsizip/.
Cuando el aviso miente (caso 8)
Una nota de honestidad: para un zip, el visor reporta cualquier falla del parser como "No se encontró ningún archivo .shp.", incluyendo un .prj que el parser no puede leer y un tipo de forma que no conoce. Si estás seguro de que el .shp está ahí, sospechá primero del .prj. GDAL, por su parte, abre los mismos archivos y no imprime ningún aviso: trata en silencio un .prj no legible como si no existiera y reporta Layer SRS WKT: como (unknown); solo gdalsrsinfo BR_UF_2022.prj nombra el problema (ERROR 1: missing [).
Archivos de prueba que podés usar
El conjunto de datos: 13.717.460 bytes, SHA-256 282ec7f0f0beeeead45e6609f4ffffce161bda04cb8ee0afcad2316d1c841bcb, SIRGAS 2000 (EPSG:4674). El listado del directorio no imprime ninguna línea de licencia; dale crédito al IBGE y revisá los términos del portal.
Para armar cualquiera de los casos de arriba, descomprimilo, borrá uno de los archivos y soltá el resto en el visor (o volvé a comprimirlos con zip -j para que no se agregue ninguna carpeta):
unzip -o BR_UF_2022.zip(cinco archivos:.cpg,.dbf,.prj,.shp,.shx).rm BR_UF_2022.shxpara el caso 2,rm BR_UF_2022.dbfpara el caso 3,rm BR_UF_2022.shppara el caso 4.
Si los atributos abren pero los nombres de columna se ven cortados, eso no es un archivo faltante sino el límite de 10 caracteres del formato, el tercer post de esta serie: Nombres de columna de Shapefile cortados a 10 caracteres.
Para equipos
Encontrar el archivo faltante es la mitad fácil. Alguien te mandó un Shapefile porque un equipo tiene que hacer algo con esos polígonos: un estado por entidad, fotos y un formulario desde el campo, un informe para el viernes. Geodocs importa el mismo conjunto a un mapa de equipo, mantiene las columnas del .dbf como campos que el equipo completa, corre la revisión y produce el informe con el mapa adentro. El visor es donde revisás el archivo; el espacio de trabajo es donde se convierte en trabajo.