El Formato Shapefile: La Guía Completa y Definitiva

Alguien te mandó "un shapefile" y resulta ser una carpeta con cinco archivos que comparten nombre. O una capa que exportaste desde QGIS aparece en el medio del Atlántico. O un colega abrió tu tabla de atributos y cada tilde se convirtió en é. Esta guía es para la persona que tiene que resolver eso hoy, y para el desarrollador al que le dijeron "andá y soportá Shapefiles" y quiere saber en qué se está metiendo. La versión corta primero: un Shapefile es el formato vectorial de ESRI de los años 90 — un .shp con la geometría, un .dbf con los atributos, un índice .shx y, en la práctica, un .prj con el sistema de coordenadas, todos con el mismo nombre base.

Todo lo que se afirma en esta página fue probado, no copiado. Armamos Shapefiles a partir de GeoJSON con GDAL 3.13.3 "Iowa City", borramos sus archivos laterales uno por uno, leímos los bytes del .dbf con un lector hexadecimal, forzamos errores de encoding a propósito y citamos los errores exactos que imprime GDAL. Cuando una afirmación viene de la ESRI Shapefile Technical Description (julio de 1998) y no de nuestra terminal, lo decimos. Todo esto se verificó el 10 de septiembre de 2026.

Una cosa antes de arrancar: el Shapefile es un formato de los años 90 que sigue siendo la forma más aceptada de intercambiar datos vectoriales, y su especificación está congelada, así que ninguno de sus problemas se va a arreglar. Esta guía no está para decirte que dejes de usarlo. Está para que sepas exactamente qué parte de tus datos va a destruir, y cómo sacarlos intactos.

Qué es un Shapefile: los archivos .shp, .shx, .dbf y .prj

Un Shapefile no es un archivo. Es un conjunto de archivos que comparten un nombre base y difieren en la extensión, y un lector necesita varios de ellos a la vez. El Shapefile "roto" más común es un solo archivo que se mandó sin los demás.

• .shp — obligatorio. La geometría. Cada registro es un código de tipo de forma seguido de coordenadas. Acá no hay datos de atributos ni sistema de coordenadas.
• .shx — obligatorio. Un índice de ancho fijo: para cada registro, su offset en bytes dentro del .shp, así un lector puede saltar directo a una entidad.
• .dbf — obligatorio. La tabla de atributos, en formato dBASE. El registro n del .dbf pertenece a la forma n del .shp; lo único que los vincula es la posición.
• .prj — obligatorio en la práctica. Un archivo de texto de una sola línea con el sistema de referencia de coordenadas en WKT. La especificación de 1998 ni lo menciona, por eso tantos Shapefiles viejos se mandan sin uno, y por eso "mi capa está en el océano" es la pregunta de soporte más común en GIS.
• .cpg — opcional. Un archivo de texto de una línea que nombra el encoding del .dbf, por ejemplo UTF-8. Sin él, los lectores adivinan.
• .sbn y .sbx — opcionales. El índice espacial de ESRI; ArcGIS los escribe, las herramientas basadas en GDAL los leen pero nunca los escriben, así que quedan desactualizados después de la primera edición hecha en otro lado.
• .qix — opcional. El índice espacial abierto que escriben GDAL, QGIS y MapServer. Creamos uno con ogrinfo src.shp -sql "CREATE SPATIAL INDEX ON src" y apareció un src.qix al lado del .shp.
• .shp.xml — opcional. Metadatos de ArcGIS (título, resumen, linaje) en XML. ArcGIS también guarda ahí los alias de los campos, y GDAL 3.13 o más nuevo lee el .shp.xml para restaurar nombres de campo de más de 10 caracteres y los alias; un Shapefile escrito por GDAL no tiene ese archivo (ninguna de nuestras exportaciones produjo uno).
• .ain y .aih — opcionales. Archivos viejos de índice de atributos de ArcView. Los podés borrar.

Comprimilos juntos en un zip y tenés un Shapefile portable; tanto GDAL como nuestro visor leen el zip directamente. Corrimos ogrinfo -so /vsizip/src.zip sobre un zip con los cinco archivos de arriba y listó 1: src (Point), exactamente igual que con los archivos sueltos.

Si falta el .shx

GDAL se niega a abrir la capa: ERROR 4: Unable to open src.shx or src.SHX. Set SHAPE_RESTORE_SHX config option to YES to restore or create it. El .shx se puede reconstruir a partir del .shp, así que la solución es lo que dice el mensaje: ogrinfo -so src.shp --config SHAPE_RESTORE_SHX YES reconstruyó el índice, y después había un src.shx nuevo en la carpeta. Cualquier herramienta basada en GDAL, QGIS incluido, acepta la misma opción.

Para las otras seis formas en que un archivo faltante rompe un Shapefile, medidas en el visor y en GDAL, leé Falta el .shx o el .dbf: por qué el Shapefile no abre.

Si falta el .dbf

La capa igual se abre, y esa es la trampa. Borramos el .dbf y ogrinfo -al -so src.shp reportó Geometry: Point, Feature Count: 2 y el CRS completo, con cero campos. Formas en el mapa, sin atributos, sin ninguna advertencia. Si "los atributos desaparecieron", primero fijate si falta el .dbf.

Si falta el .prj

La geometría se abre, los atributos se abren, y el sistema de coordenadas queda desconocido. GDAL imprime Layer SRS WKT: seguido de (unknown). Un GIS de escritorio va a pedirte un CRS, va a asumir uno, o va a cargar la capa con un CRS desconocido y un signo de pregunta al lado — QGIS hace cualquiera de las tres cosas según su configuración — y si el archivo está en metros UTM, una capa tratada como si fueran grados aparece lejísimos del mapa. La sección sobre el .prj de más abajo trata sobre este caso.

Para la guía paso a paso — qué muestran GDAL, QGIS y nuestro visor para un archivo sin .prj, cómo saber en qué CRS están realmente los números, y la diferencia entre asignar y reproyectar — leé Shapefile en el lugar equivocado: falta el .prj.

Si falta el .cpg

El archivo se abre y el texto puede estar mal. El encabezado del .dbf tiene un byte de "language driver" en el offset 29; el default de GDAL es 87, que trata como Latin-1 (su log de debug dice Treating as encoding 'ISO-8859-1'). Si los datos en realidad eran UTF-8, o si el lector ignora ese byte, las tildes salen convertidas en mojibake. La sección del .dbf de más abajo muestra los bytes.

Un solo tipo de geometría por archivo

El encabezado del .shp lleva un solo tipo de forma para todo el archivo, y cada registro tiene que coincidir con él. La especificación de 1998 define catorce códigos de tipo de forma: 0 para Null; 1, 3, 5 y 8 para Point, PolyLine, Polygon y MultiPoint; los mismos cuatro con Z (11, 13, 15, 18) y con M (21, 23, 25, 28); y 31 para MultiPatch, un tipo de superficie 3D de ESRI que casi ninguna herramienta abierta escribe. En la práctica te vas a encontrar con cuatro tipos de archivo — puntos, líneas, polígonos, multipuntos — más sus variantes 3D.

Una capa GeoJSON o GeoPackage puede mezclar puntos y líneas. Un Shapefile no. Convertimos un GeoJSON con un Point y un LineString con ogr2ogr -f "ESRI Shapefile" out mixed.geojson. GDAL creó un Shapefile de puntos a partir de la primera entidad y después se frenó, imprimiendo ERROR 1: Attempt to write non-point (LINESTRING) geometry to point shapefile., ERROR 1: Unable to write feature 1 from layer mixed. y Terminating translation prematurely after failed translation of layer mixed (use -skipfailures to skip errors). El código de salida fue 1 y la salida tenía una sola entidad. Si necesitás las dos geometrías, necesitás dos Shapefiles; si solo necesitás que termine, -skipfailures igual imprime el mismo ERROR 1 por cada entidad que no coincide, pero la descarta y sale con 0, así que leé el log antes de confiar en el conteo.

Dos detalles que no parecen la regla, pero lo son:

• Un archivo de polígonos guarda polígonos simples y multipart uno al lado del otro. El formato no tiene un tipo MultiPolygon separado; un registro Polygon simplemente tiene más de un anillo. GDAL lee los dos casos de vuelta como POLYGON y MULTIPOLYGON en la misma capa, y eso es lo que PostGIS y QGIS reclaman como "tipos de geometría mezclados" al importar. La solución es ogr2ogr -f GPKG out.gpkg in.shp -nlt PROMOTE_TO_MULTI; lo corrimos y la capa GeoPackage salió como Multi Polygon de punta a punta.
• Las formas Null son válidas en cualquier archivo. Un registro con tipo de forma 0 significa "atributos, sin geometría". Exportamos una entidad cuya geometría era null a un Shapefile de puntos y leímos el .shp crudo: el registro 1 tenía tipo de forma 1, el registro 2 tenía tipo de forma 0, y ogrinfo listó los dos, el segundo con atributos y sin POINT. Algunos visores descartan esas filas; contá tus entidades después de importar.

Las variantes Z y M guardan una elevación y una "medida" por vértice. GDAL las escribe si se lo pedís: ogr2ogr -f "ESRI Shapefile" out in.geojson -nlt POINTZ produjo un archivo que ogrinfo reporta como src (3D Point). La mayoría de las herramientas web achatan la Z al leer.

El .prj y la capa en el océano

El .prj es una sola línea de WKT en el dialecto de ESRI del formato 1.0. Para WGS 84, GDAL escribe GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]] — fijate en los prefijos GCS_ y D_ y en que falta la cláusula AUTHORITY. Un .prj de ESRI no lleva el código EPSG; los lectores comparan los parámetros contra una base de datos para recuperarlo. Normalmente funciona; cuando los parámetros están un poco corridos, te queda un "CRS personalizado" con la forma correcta y el nombre equivocado.

El síntoma que todos conocen: la capa carga sin error y aparece a miles de kilómetros, muchas veces en latitud 0, longitud 0 frente a África Occidental — "en el medio del océano". Casi siempre las coordenadas son metros proyectados con northings de siete dígitos, y el lector las está tratando como grados porque el .prj faltaba o estaba mal.

Hay dos soluciones distintas y no son intercambiables:

• Asignar un CRS cuando las coordenadas están bien y solo falta la etiqueta. Esto reescribe el .prj y no toca ninguna coordenada. ogr2ogr -f "ESRI Shapefile" fixed in.shp -a_srs EPSG:31982 — lo corrimos sobre un archivo sin .prj y el punto se quedó en POINT (-48.5 -27.6) mientras el .prj nuevo declaraba SIRGAS_2000_UTM_Zone_22S. (Que, para una coordenada en grados, ahora es mentira. Asignar el CRS equivocado es la segunda forma más común de mandar una capa al océano.)
• Reproyectar cuando las coordenadas están correctas en un CRS y las necesitás en otro. Esto transforma cada vértice. ogr2ogr -f "ESRI Shapefile" out in.shp -s_srs EPSG:4326 -t_srs EPSG:31982 — el mismo punto pasó a ser POINT (746752.990849492 6944611.29529316), en metros.

En QGIS las mismas dos operaciones son "Establecer SRC de la capa…" (asignar) y "Exportar → Guardar objetos como…" con un CRS distinto (reproyectar), y elegir la equivocada produce el mismo desastre desde el escritorio. Si no estás seguro en qué sistema está un archivo, pegá uno de sus pares de coordenadas en nuestro conversor de coordenadas y probá sistemas candidatos hasta que el punto caiga en un lugar que reconozcas.

Datums regionales que te vas a encontrar en archivos .prj

Los nombres de abajo son lo que reporta gdalsrsinfo para cada código en nuestra máquina; el .prj va a mostrar la grafía de ESRI, con guiones bajos.

• EPSG:4686 — MAGNA-SIRGAS, geográfico. El datum nacional de Colombia, el que vas a encontrar en la inmensa mayoría de la cartografía oficial y catastral colombiana; lo mantiene el IGAC (Instituto Geográfico Agustín Codazzi), la autoridad geográfica del país.
• EPSG:9377 — MAGNA-SIRGAS 2018 / Origen-Nacional. La proyección nacional única de Colombia, que reemplaza a los orígenes regionales más viejos; si tu capa colombiana está en metros y no en grados, probablemente sea esta.
• EPSG:4674 — SIRGAS 2000, geográfico. El datum de referencia de casi toda Sudamérica — Brasil y buena parte de la región lo usan como marco oficial — y para fines prácticos coincide con WGS 84, así que un archivo en SIRGAS 2000 leído como WGS 84 no te va a mandar la capa muy lejos. Sus zonas UTM proyectadas son EPSG:31982 (zona 22S) y EPSG:31983 (zona 23S), que entre las dos cubren São Paulo, Paraná, Santa Catarina y Río de Janeiro; la serie 3197x/3198x sigue por el resto de las zonas de Brasil. Es el punto de partida más seguro cuando no sabés en qué datum está un archivo sudamericano y no es colombiano.
• EPSG:4618 — SAD69, geográfico. El datum brasileño que SIRGAS reemplazó; todavía te vas a encontrar Shapefiles municipales y de servicios públicos viejos en esto, con zonas UTM EPSG:29192 (22S) y EPSG:29193 (23S). SAD69 y SIRGAS 2000 difieren en decenas de metros, así que "más o menos" no alcanza.
• EPSG:4225 — Córrego Alegre 1970-72, geográfico. El datum anterior a SAD69; aparece en mapas catastrales viejos y en Shapefiles digitalizados a partir de ellos.
• EPSG:5340 — POSGAR 2007, geográfico. El datum nacional de Argentina; sus zonas proyectadas van de EPSG:5343 a EPSG:5349 (Argentina 1 a 7, Gauss-Krüger).
• EPSG:5360 — SIRGAS-Chile 2002, geográfico. Chile actualiza su marco cada tanto, así que los archivos más nuevos pueden decir SIRGAS-Chile 2010, 2013, 2016 o 2021.
• EPSG:6365 — Mexico ITRF2008, geográfico. El marco nacional mexicano vigente.
• EPSG:4326 (WGS 84), EPSG:3857 (WGS 84 / Pseudo-Mercator, la proyección de los tiles web) y EPSG:4269 (NAD83, el default de los datos públicos de Estados Unidos, a un metro o dos de WGS 84) son los que vas a ver fuera de la región, junto con una zona UTM genérica como EPSG:32622 o EPSG:32722 — la serie 326xx/327xx son las zonas UTM del hemisferio norte y sur sobre WGS 84, con los dos últimos dígitos indicando la zona. Un .prj que diga GCS_WGS_1984 es el primero de estos.

Si un .prj nombra alguno de estos y la capa igual cae en el océano, lo más probable es que se haya asignado el equivocado al exportar; probá los candidatos vecinos antes de tocar los datos.

El .dbf te va a doler

El lado de la geometría de un Shapefile es simplemente viejo. El lado de los atributos es donde tus datos se dañan, en silencio, al exportar. Pasamos un dataset chico — un campo llamado observation_notes, un valor UTF-8 São João, un NULL, una cadena vacía, una nota de 300 caracteres y un timestamp ISO — por ogr2ogr y leímos qué sobrevivió.

Los nombres de campo se cortan a 10 caracteres

El encabezado dBase guarda cada nombre de campo en 11 bytes, uno de los cuales es un terminador. GDAL avisa y después renombra: Warning 6: Normalized/laundered field name: 'observation_notes' to 'observatio'. Cuando dos nombres chocan, inventa un sufijo — observation_notes_final se convirtió en observat_1. Una versión anterior de esta guía decía que Populacao_2026 se convierte en Populaca_26; lo probamos, y está mal. GDAL se queda con los primeros diez caracteres, así que se convierte en Populacao_. Haga lo que haga tu herramienta, el año desaparece.

Esto es permanente. Convertir el Shapefile de vuelta a GeoPackage nos dio campos que seguían llamándose observatio y observat_1. Los nombres no están escondidos en ningún lado; nunca se escribieron.

Para la regla de colisión medida en un segundo dataset, y lo que un .shp.xml completo puede y no puede restaurar, leé Nombre de columna cortado a 10 caracteres.

Latin-1 por default, y el archivo lateral .cpg

Con un ogr2ogr -f "ESRI Shapefile" out in.geojson sin ninguna opción, GDAL no escribió ningún archivo .cpg, puso el byte de language-driver en el offset 29 en 87, y guardó São João como los bytes Latin-1 Jo\xe3o — la secuencia UTF-8 no está en ningún lado del archivo. GDAL lee su propia salida correctamente porque respeta ese byte (la opción ENCODING del driver tiene como default LDID/87). Un lector que asume UTF-8 — la mayoría del código web, la mayoría de los scripts que abren el .dbf directamente — muestra Jo�o; una herramienta que reinterpreta el texto Latin-1 como UTF-8 y lo muestra como Latin-1 muestra João, el daño estilo é que aparece en cualquier tabla de atributos latinoamericana.

La solución del lado de la escritura es una sola opción: ogr2ogr -f "ESRI Shapefile" out in.geojson -lco ENCODING=UTF-8. La salida entonces incluye un src.cpg cuyo contenido entero es UTF-8, el byte del encabezado queda en 0, y los bytes guardados son Jo\xc3\xa3o, UTF-8 genuino. Del lado de la lectura, cuando alguien te pasa un archivo Latin-1 cuyo byte de encabezado no dice nada (0) y que no tiene .cpg, decile a GDAL: ogr2ogr -f GPKG out.gpkg in.shp --config SHAPE_ENCODING ISO-8859-1. Pusimos en cero el byte de language driver de nuestro propio archivo para reproducir ese caso: sin la opción GDAL leyó S�o Jo�o, con ella volvió São João. (En el archivo tal como GDAL lo escribió, byte de encabezado 87, la opción no cambia nada — GDAL ya lee eso como Latin-1.)

Para las dos direcciones del mojibake reproducidas en el visor, más la corrección de una línea con el .cpg, leé Acentos incorrectos en un Shapefile: .cpg, Latin-1 y UTF-8.

NULL y cadena vacía son lo mismo

El .dbf no tiene ningún marcador de NULL. Un campo de texto sin valor se rellena con espacios, y una cadena vacía también. Escribimos dos entidades, una con nota en null y otra con nota en ""; en el .dbf los dos registros tenían ochenta espacios, idénticos byte a byte, y ogrinfo leyó las dos de vuelta como (null). Después de un viaje de ida y vuelta a GeoPackage, SQLite reportó typeof(nota) como null para las dos. "No medido" y "medido, vacío" se convirtieron en un solo valor, y la diferencia no se puede recuperar. Los campos numéricos tienen el mismo problema de otra forma: algunos escritores guardan un número sin valor como blancos, otros como 0, y un lector no puede distinguir el segundo de un cero real.

254 caracteres de texto, fechas sin hora, y números como texto

Un campo de caracteres tiene un ancho de un byte, así que el techo es 254 caracteres. Nuestra nota de 300 caracteres produjo Warning 1: Value '…' of field long_text has been truncated to 254 characters. This warning will not be emitted any more for that layer. — leé la última oración: la primera truncación se anuncia, todas las siguientes son silenciosas. El campo volvió como String (254.0) con exactamente 254 caracteres.

Existe un tipo fecha, D, y guarda una fecha de calendario y nada más. Un valor 2026-09-10 se convirtió en d: Date y sobrevivió. Un timestamp no: Warning 6: Field dt created as String field, though DateTime requested., y el campo se convirtió en String (29.0) — texto que cualquier herramienta río abajo tiene que parsear y esperar lo mejor. No hay zona horaria ni hora. Lo que sí existe es el booleano, digan lo que digan por ahí: el tipo lógico L existe, y un campo true/false que exportamos volvió como Integer(Boolean) con los valores 1 y 0. Esa queja en particular es un mito.

Los números se guardan como texto ASCII con un ancho y una precisión fijos. Un campo de punto flotante volvió como Real (24.15) — 24 caracteres, 15 decimales — y el valor que escribimos, 0.1234567890123456789, se leyó de vuelta como 0.123456789012346. Los enteros se convierten en Integer (9.0) o Integer64 (18.0) según el tamaño. Eso está bien para mediciones y mal para identificadores que tienen que coincidir exactamente.

2 GB, y GDAL no te va a frenar

El .shp guarda los offsets como cuentas de 32 bits de palabras de 16 bits y el .dbf no tiene offsets en absoluto, así que la spec en sí no se frena en los 2 GB — ese techo es lo que imponen el software de ESRI y la mayoría de los lectores, y es el número para el que todo el mundo diseña. Lo que verificamos es la actitud de GDAL: la opción de creación 2GB_LIMIT tiene NO por default, así que GDAL escribe más allá (con un único aviso al cruzarlo) y el que falla es el próximo programa — ArcGIS, un MapServer viejo, un formulario de carga con límite de tamaño. Datos que se acerquen a ese tamaño no deberían ser un Shapefile. Nuestra guía de GeoPackage cubre el formato que arregla todos los problemas de esta sección, con los mismos experimentos del otro lado.

Cómo abrir un Shapefile sin QGIS

No necesitás un GIS de escritorio para mirar un Shapefile, leer sus atributos o averiguar en qué CRS está.

• Comprimí los archivos laterales juntos. Seleccioná el .shp, .shx, .dbf y .prj (y el .cpg si hay uno), y comprimilos en un solo .zip. No comprimas la carpeta que los contiene; comprimí los archivos. Un .shp solo muestra formas sin atributos.
• Arrastrá el zip al visor. Soltalo en nuestro visor gratuito de Shapefiles: acepta un .zip, un .shp solo, o el .shp más el .dbf más el .prj soltados juntos, y dibuja las entidades en un mapa. Hacé clic en una entidad para leer sus atributos, área o longitud y copiar su WKT; abrí la tabla de atributos para buscar y ordenar todo el archivo; elegí una columna como etiqueta del mapa. Hasta diez archivos cargan uno al lado del otro, la forma más rápida de ver si dos capas realmente se superponen.
• Exportá desde el navegador. El visor escribe GeoJSON, KML y CSV, así que "convertir este Shapefile a GeoJSON" es arrastrar y hacer un clic sin instalar nada.
• Privacidad. Todo el procesamiento pasa en tu navegador. Ningún archivo se manda a ningún servidor; tus archivos nunca salen de tu dispositivo. Eso es lo que lo hace usable con datos que no te dejan mandar a ningún lado.

Desde la terminal, ogrinfo -so in.shp lista la capa y su tipo de geometría, y ogrinfo -al -so in.shp suma los campos, el extent y el CRS sin imprimir ninguna entidad. Los dos vienen con GDAL, un solo paquete para instalar en Linux, macOS y Windows.

Convertir a partir de un Shapefile

Todos los comandos de esta sección se ejecutaron contra archivos reales antes de publicar, con GDAL 3.13.3.

• Shapefile a GeoPackage: ogr2ogr -f GPKG out.gpkg in.shp. Los nombres de campo quedan como los tiene el .dbf (ya truncados), el texto se convierte en UTF-8 real, y los NULL son lo que el Shapefile pudo expresar, que no es mucho. Nuestra guía de GeoPackage cubre qué hacer después.
• Shapefile a GeoPackage cuando el origen es Latin-1 (asumí que lo es, salvo que haya un .cpg que diga otra cosa): ogr2ogr -f GPKG out.gpkg in.shp --config SHAPE_ENCODING ISO-8859-1.
• Shapefile a GeoJSON para la web — reproyectá siempre, la especificación de GeoJSON exige WGS 84: ogr2ogr -f GeoJSON -t_srs EPSG:4326 out.geojson in.shp. La salida declara urn:ogc:def:crs:OGC:1.3:CRS84. Si la entrada no tiene .prj, el comando falla con ERROR 1: Can't transform coordinates, source layer has no coordinate system. Use -s_srs to set one. — agregá -s_srs con el CRS que ya estableciste.
• Arreglá polígonos simples y multipart mezclados de paso: ogr2ogr -f GPKG out.gpkg in.shp -nlt PROMOTE_TO_MULTI.
• Shapefile a KML para Google Earth: ogr2ogr -f KML out.kml in.shp. El driver KML reproyecta a WGS 84 por su cuenta — nuestro archivo en UTM salió con <coordinates>-48.5,-27.6 — y escribe los atributos dentro de cada placemark. Un KMZ es el mismo KML adentro de un zip; armar y abrir uno está cubierto en nuestra guía de cómo visualizar archivos KMZ en línea.
• Escribir un Shapefile sin romper las tildes: ogr2ogr -f "ESRI Shapefile" out_dir in.gpkg -lco ENCODING=UTF-8. Igual vas a perder los nombres de campo después de los diez caracteres y todos los timestamps; la opción solo arregla el encoding.
• Solo algunas entidades: ogr2ogr -f GPKG out.gpkg in.shp -where "status = 1" filtra por atributos, y -clipsrc xmin ymin xmax ymax recorta a una caja.
• Reconstruir un índice perdido: ogr2ogr -f "ESRI Shapefile" fixed in.shp --config SHAPE_RESTORE_SHX YES. Lo corrimos sobre una carpeta sin .shx; la copia en fixed tenía uno, y la carpeta de origen también lo tuvo después — la opción restaura el índice en el lugar.

El flag -nln nombra la capa de salida en los formatos que tienen nombres de capa; omitilo y heredás el nombre base del Shapefile, lo cual está bien hasta que ese nombre es export (2) final.

Errores, decodificados

Cada entrada es síntoma, causa, solución. Los mensajes están citados de GDAL 3.13.3; QGIS muestra el mismo texto en su panel de log.

"Unable to open .shx"

Síntoma: ERROR 4: Unable to open in.shx or in.SHX. Set SHAPE_RESTORE_SHX config option to YES to restore or create it. y la capa no carga. Causa: el archivo lateral del índice no se copió junto con el .shp. Solución: ogrinfo -so in.shp --config SHAPE_RESTORE_SHX YES lo reconstruye en el lugar; después copiá el conjunto completo la próxima vez.

"Layer has no CRS" o (unknown)

Síntoma: ogrinfo imprime Layer SRS WKT: y después (unknown); QGIS muestra un signo de pregunta al lado de la capa o pide un CRS. Causa: no hay .prj. Solución: averiguá qué son las coordenadas (dos dígitos antes del punto son grados, EPSG:4326; eastings de seis dígitos con northings de siete dígitos en Brasil son una zona 3198x), y después asigná, no reproyectes: ogr2ogr -f "ESRI Shapefile" fixed in.shp -a_srs EPSG:31982.

"Normalized/laundered field name"

Síntoma: Warning 6: Normalized/laundered field name: 'observation_notes' to 'observatio' al exportar, y un colega después pregunta qué significa observat_1. Causa: el límite de 10 caracteres. Solución: ninguna dentro del .dbf; ArcGIS guarda el nombre largo como alias en el .shp.xml, y GDAL 3.13+ lo lee de vuelta — un Shapefile escrito por GDAL no tiene ese archivo. Renombrá los campos a diez caracteres o menos antes de exportar para elegir vos las abreviaturas, o mantené un GeoPackage y tratá al Shapefile como una copia con pérdida.

Las tildes se muestran como é o �

Síntoma: São João se muestra como São João o S�o Jo�o. Causa: un .dbf Latin-1 leído como UTF-8, o al revés; no hay .cpg que lo resuelva. Solución: al leer, --config SHAPE_ENCODING ISO-8859-1 (o UTF-8, lo que el archivo realmente sea); al escribir, -lco ENCODING=UTF-8 para que se escriba un .cpg y el próximo lector no tenga que adivinar.

"File too large" o un .dbf que otro software rechaza

Síntoma: GDAL escribió el archivo, imprimiendo un único aviso al cruzar los 2 GB; ArcGIS, un formulario de carga o una librería más vieja lo rechaza, o lee basura después de cierta entidad. Causa: un .shp o .dbf que pasó los 2 GB, lo que GDAL permite por defecto (2GB_LIMIT=NO). Solución: dividí los datos, o dejá de usar Shapefile para eso — ogr2ogr -f GPKG out.gpkg in.shp no tiene ese techo.

"Attempt to write non-point geometry to point shapefile"

Síntoma: ERROR 1: Attempt to write non-point (LINESTRING) geometry to point shapefile. seguido de Terminating translation prematurely, y una salida con menos entidades que la entrada. Causa: el origen mezcla tipos de geometría y un Shapefile solo admite uno. Solución: exportá un Shapefile por tipo con el filtro de geometría — ogr2ogr -f "ESRI Shapefile" points in.geojson -where "OGR_GEOMETRY='POINT'" y de nuevo con 'LINESTRING'; corrimos las dos y obtuvimos una capa Point y una capa Line String sin errores. O mantené los datos en un formato que permita mezclar.

Las entidades no se dibujan, o se dibujan en el océano

Síntoma: la capa carga sin error y queda invisible, o aparece en latitud 0, longitud 0. Causa: un .prj que falta o está mal, así que los metros proyectados se leen como grados o al revés. Solución: revisá ogrinfo -al -so in.shp buscando Layer SRS WKT; compará la línea Extent con lo que deberían verse los números en el CRS que esperás; asigná el CRS correcto. Si el extent está bien y la capa sigue invisible, revisá el Feature Count — un archivo de formas Null no tiene nada para dibujar.

Shapefile vs GeoPackage vs GeoJSON

Sin tabla — elegí la frase que coincide con tu situación.

Shapefile sigue siendo la respuesta correcta cuando el otro lado no acepta nada más. Eso es real y común: geoportales gubernamentales, sistemas municipales viejos, software de activos de servicios públicos, paquetes de agrimensura y bastantes instalaciones de ArcGIS importan un Shapefile y nada más, y es el formato con más chances de abrir en una herramienta de la que nunca oíste hablar. Cuando esa es la restricción, exportá con -lco ENCODING=UTF-8, elegí a propósito tus nombres de campo de diez caracteres, mandá el .prj, y guardá el original en un formato que no perdió nada.

GeoPackage es la respuesta correcta cuando los datos son tuyos para guardar: muchas capas, tipos de geometría mezclados, nombres de campo reales, NULLs reales, timestamps reales, un solo archivo con el CRS adentro. Es el default correcto para GIS de escritorio y trabajo de campo, y en lo que debería convertirse un Shapefile apenas llega.

GeoJSON es la respuesta correcta cuando lo va a leer un navegador o una API, o un humano necesita abrirlo en un editor de texto. Está atado a WGS 84 por especificación, no tiene índice y se pone pesado pasados unos pocos megabytes, nada de lo cual importa para el caso "mandale estos cuarenta puntos al frontend" para el que existe.

Y ninguno de los tres es la respuesta cuando varias personas necesitan escribir al mismo tiempo. Eso es una base de datos, no un archivo.

Para el lado medido de esta comparación — tamaños, límites de nombre de campo, encoding, CRS y tiempo de carga en un dataset real — leé Shapefile vs GeoPackage vs GeoJSON: cuál usar.

Dónde entra Geodocs

Construimos Geodocs, una plataforma para equipos de datos de campo y de GIS, y escribimos esta guía porque una buena parte de lo que suben nuestros usuarios es un Shapefile, y una buena parte de las conversaciones de soporte que siguen son uno de los siete errores de arriba. Así que la plataforma los maneja: toma un Shapefile comprimido como una sola carga, detecta el encoding del .dbf en lugar de asumirlo, lee el .prj y reproyecta al mapa, y guarda los datos en un lugar donde un nombre de campo puede ser más largo que diez caracteres y un NULL sigue siendo un NULL. Si tu equipo todavía manda por mail carpetas de cinco archivos rezando para que el .prj haya llegado, ese es el problema que existimos para eliminar.

¿Encontraste un error, o una trampa que se nos pasó? Contanos. Volvemos a correr esta página en vez de copiarla y pegarla.

Última verificación: 10 de septiembre de 2026, GDAL 3.13.3.