Volver al Blog

Shapefile vs GeoPackage vs GeoJSON: Cuál Usar

Respuesta corta: recopilá y editá en GeoPackage, publicá en la web en GeoJSON, y entregá un Shapefile solo cuando el otro lado insista. El resto es evidencia: un dataset convertido de tres formas el 15 de septiembre de 2026, ocho preguntas hechas a cada copia, el comando detrás de cada respuesta.

El dataset es la malla 2022 del IBGE de los 27 estados brasileños: 27 polígonos, cinco campos. Llega como un zip de 13.717.460 bytes cuyo SHA-256 es 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.

Cómo se hicieron las tres copias

El zip tiene cinco archivos: BR_UF_2022.shp, .shx, .dbf, .prj y .cpg. ogrinfo -so reporta 27 polígonos en SIRGAS 2000, que GDAL identifica como EPSG:4674 — no WGS 84, lo cual importa más abajo. El GeoPackage salió de ogr2ogr -f GPKG uf.gpkg BR_UF_2022.shp, manteniendo el CRS. El GeoJSON salió de ogr2ogr -f GeoJSON uf.geojson BR_UF_2022.shp -t_srs EPSG:4326 -lco RFC7946=YES, más una segunda copia con -lco COORDINATE_PRECISION=6. Solo el GeoJSON fue reproyectado, porque RFC 7946 no deja otra opción: un GeoJSON "en SIRGAS 2000" no tiene forma de decirlo. GDAL 3.13.3 en todos los casos; cada conjunto suelto se comprimió después con zip -9.

El comando GPKG simple también avisa que se está insertando un MULTIPOLYGON en una capa declarada POLYGON: el formato Shapefile tiene un solo tipo de forma poligonal, así que estados multi-parte como Pará llegan etiquetados como simples polígonos. -nlt MULTIPOLYGON silencia el aviso y es la declaración correcta.

Los ocho criterios

Las mismas tres viñetas, en el mismo orden, siempre. Donde se midió, el número está citado; donde es una afirmación sobre la especificación, la introducción lo aclara.

Tamaño del archivo

Suelto es el peso en disco; comprimido son los mismos archivos después de zip -9. El peso suelto del Shapefile es la suma de sus cinco archivos.

  • Shapefile — 18.227.115 bytes suelto (17,38 MiB), de los cuales 18.224.100 son el .shp y 2.543 el .dbf; 13.794.222 bytes comprimido (13,16 MiB). El propio zip del IBGE pesa 13.717.460 bytes — los mismos cinco archivos, un archivo comprimido distinto.
  • GeoPackage — 18.386.944 bytes suelto (17,54 MiB), 13.828.105 comprimido (13,19 MiB). Son 159.829 bytes más que el Shapefile suelto y 33.883 más comprimido: la estructura de páginas de SQLite y el índice espacial cuestan más que el .shx que reemplazan. La sabiduría popular de que GeoPackage ahorra bytes no es cierta acá.
  • GeoJSON — 29.108.343 bytes suelto con el default de RFC 7946 de siete decimales (27,76 MiB) y 26.839.688 con seis (25,60 MiB); pero comprimido es el más chico de los tres por unos 5 MiB — 8.457.365 bytes (8,07 MiB) y 7.132.808 (6,80 MiB). El texto se comprime a 71–73 %, las formas binarias a 24–25 %. Seis decimales son unos 0,11 m en el ecuador, así que el primer vértice de Acre moviéndose de [-68.7928173,-10.9995693] a [-68.792817,-10.999569] es invisible a cualquier zoom.

Nombres de campo

La tabla de atributos del Shapefile es un archivo dBase, y dBase limita un nombre de campo a diez caracteres. El archivo del IBGE nunca llega a ese límite — sus cinco campos son CD_UF, NM_UF, SIGLA_UF, NM_REGIAO y AREA_KM2, el más largo con nueve caracteres — así que lo provocamos: un alias de 26 caracteres, -sql "SELECT *, NM_UF AS nome_da_unidade_federativa FROM BR_UF_2022", escrito en cada formato.

  • Shapefile — GDAL imprimió Warning 6: Normalized/laundered field name: 'nome_da_unidade_federativa' to 'nome_da_un' y la tabla salió con una columna llamada nome_da_un. Un alias de exactamente diez caracteres no generó ningún aviso, así que es la longitud y nada más.
  • GeoPackage — nome_da_unidade_federativa sobrevivió intacto; sqlite3 lo lista como una columna TEXT(50).
  • GeoJSON — nome_da_unidade_federativa también sobrevivió, como clave de propiedad en cada uno de los 27 estados. Un nombre de propiedad es un string de JSON, tan largo como quieras.

Encoding

El texto de un Shapefile vive en el .dbf, y el encabezado del .dbf de este archivo no declara ningún codepage (su byte de language-driver es 0). El único lugar donde dice UTF-8 es en el sidecar .cpg de cinco bytes, cuyo contenido entero es UTF-8. Lo borramos y volvimos a pedir los nombres de los estados.

  • Shapefile — con el .cpg presente, GDAL reporta ENCODING_FROM_CPG=UTF-8 e imprime Pará, Amapá y Maranhão correctamente. Sin él, GDAL reporta un encoding de origen vacío y pasa los bytes tal cual, así que Amapá todavía se ve bien en una terminal UTF-8 — suerte, no certeza. En el momento en que un lector asume el codepage que los Shapefiles cargaron durante veinte años, Latin-1 o Windows-1252 (--config SHAPE_ENCODING ISO-8859-1 lo reproduce), los mismos bytes se imprimen como Amapá y São Paulo, y el mojibake pasa a cada archivo exportado desde ahí. No apareció ningún signo de interrogación en ninguna corrida: letras equivocadas, no faltantes.
  • GeoPackage — UTF-8 por especificación; file lo lee del encabezado de SQLite, y ogrinfo imprime Pará, Amapá y Paraíba sin ningún sidecar que se pueda perder.
  • GeoJSON — UTF-8 por especificación, porque JSON lo es; grep -c Amapá encuentra el nombre en las dos copias, bytes C3 A1.

CRS que lleva el archivo

Dónde dice el archivo en qué sistema de coordenadas están sus números, y si lo hace con un código que una máquina pueda buscar.

  • Shapefile — el .prj son 151 bytes de WKT de ESRI que empiezan con GEOGCS["GCS_SIRGAS_2000", y grep -c 'AUTHORITY\|EPSG' sobre él devuelve 0: ningún código de autoridad en el archivo. Cuando ogrinfo imprime ID["EPSG",4674] es GDAL comparando el texto contra su propia base de datos, no leyendo un número. Nuestra hoja de referencia de EPSG explica por qué "mi archivo no tiene código EPSG" es una queja tan común.
  • GeoPackage — el CRS es una fila en gpkg_spatial_ref_sys con autoridad y código, EPSG / 4674, y gpkg_geometry_columns vincula la capa a esa fila. Dos filas indefinidas y 4326 están al lado porque la especificación las exige.
  • GeoJSON — nada. grep -c '"crs"' devuelve 0 en las dos copias. RFC 7946 §4 fija el CRS de todo GeoJSON en WGS 84, longitud primero, por eso la conversión tuvo que reproyectar — y por eso un GeoJSON que sigue en SIRGAS 2000 o en metros UTM se dibuja en el lugar equivocado sin ningún error. Nuestra guía de GeoJSON cubre ese caso.

Uno o varios archivos

Qué tenés que mantener junto para que los datos abran.

  • Shapefile — cinco archivos del IBGE: .shp, .shx, .dbf, .prj, .cpg. Tres son obligatorios para que el formato abra; los otros dos llevan el CRS y el encoding, y son los que más se pierden. El IBGE no distribuye índice .sbn/.sbx ni metadata .shp.xml.
  • GeoPackage — un solo archivo, uf.gpkg. SQLite puede dejar un -journal o -wal transitorio al lado mientras escribe; acá no quedó ninguno.
  • GeoJSON — un solo archivo, uf.geojson.

Techo de tamaño

Una afirmación de la propia documentación de cada formato, no una medición — el archivo más grande acá pesa 29 MB.

  • Shapefile — 2 GB por .shp y por .dbf. La página del driver Shapefile de GDAL lo plantea como "it is not recommended to use a file size over 2GB for both .SHP and .DBF files" y documenta un aviso que se emite al llegar al límite.
  • GeoPackage — el límite de SQLite, que la página de límites de SQLite plantea como "about 281 terabytes". En la práctica, el disco.
  • GeoJSON — sin techo en RFC 7946. El límite práctico es lo que sea que el parser pueda tener en memoria: el visor gratuito de abajo no tiene tope de bytes ni de entidades, así que decide la memoria del navegador.

Editabilidad

También una afirmación, no una medición — lo que cuesta editar en cada formato.

  • Shapefile — editable in situ desde un GIS de escritorio, pero cada edición reescribe .shp, .shx y .dbf juntos, porque el .shx es un índice de offsets hacia el .shp. Renombrar un campo está limitado por los diez caracteres de arriba, y un cambio de texto por el codepage.
  • GeoPackage — una base de datos SQLite: las ediciones son transacciones con rollback si algo falla, los lectores concurrentes son seguros, y cualquier cliente SQLite puede actualizar un atributo sin necesidad de un GIS. Acá es donde el archivo único recupera los bytes que costó.
  • GeoJSON — texto plano, así que cualquier editor cambia una propiedad; pero no hay índice ni transacción, y un archivo de 27 MiB es una reescritura de 27 MiB por el cambio de un solo carácter. Está bien a mano, mal para un flujo de trabajo.

Tiempo de carga en los visores gratuitos

Medido en las herramientas en producción con un Chromium headless a 1280×1000, un navegador nuevo por corrida, tres corridas por archivo, el archivo local entregado al input de archivo de la página; el reloj corre desde la entrega hasta que el panel de capas, expandido con un clic después de que el archivo se registra, lista los 27 estados — así que cada número incluye ese clic y su re-render. Leé las medianas como "más o menos un segundo y medio" y "más o menos tres segundos": una máquina, una tarde.

  • Shapefile — el zip (13.794.222 bytes) soltado en el shapefile-viewer: mediana 1.621 ms (corridas 1.621 / 1.621 / 1.404).
  • GeoPackage — sin visor. tools.geodocs.io tiene ocho visores y ninguno abre un .gpkg, por la razón que da la guía de GeoPackage: una base de datos SQLite necesita un motor SQLite. Abrilo en QGIS.
  • GeoJSON — el archivo de siete decimales (29.108.343 bytes) soltado en el geojson-viewer: mediana 3.559 ms (corridas 2.770 / 3.559 / 4.735). La mediana del archivo de seis decimales fue 2.740 ms, pero sus corridas van de 2.435 a 4.158 ms — tan ancho como la diferencia entre las dos precisiones — así que no afirmamos que seis decimales cargue más rápido. Las dos son más o menos el doble que el Shapefile comprimido.

Cuál elegir, entonces

Si recopilás o editás datos — un equipo de campo, un relevamiento, un inventario que cambia cada semana — usá GeoPackage. Un solo archivo, transacciones, el CRS guardado como código, UTF-8 sin sidecar, nombres de campo tan largos como la columna se lo merezca. Cuesta 159.829 bytes más que el Shapefile de acá y a cambio te da todo lo demás de esta página. Su único punto flojo es el navegador: no tiene visor gratuito, así que mantené QGIS a mano.

Si el destino es la web o una API — un mapa en una página, un fetch desde JavaScript, un payload entre servicios — usá GeoJSON. Es el más chico de los tres en la red una vez comprimido, se abre en el visor gratuito sin instalar nada, y toda librería web lo lee. Reproyectá a WGS 84 primero, porque el formato no puede registrar otra cosa, y prestá atención al peso suelto: 29 MB en una pestaña está bien, diez veces eso es una decisión.

Si el otro lado insiste con un Shapefile, mandá uno — los cinco archivos en un zip, y aclará el encoding y el CRS en el mensaje, porque el .cpg y el .prj son los dos archivos que más se pierden y los dos cuya ausencia da un mapa que queda mal en vez de un mapa que falla. Nuestra guía de Shapefile explica cada sidecar.

Para equipos

Un formato es lo que entregás; el flujo de trabajo es donde se va el tiempo. Geodocs está hecho para el lado del flujo de trabajo — recolección de campo con atributos que conservan sus nombres y sus tildes, compartida por un equipo en un solo mapa — así que la pregunta del formato aparece recién al exportar, el momento justo para hacerla.

Artículos Relacionados

Navegação