GeoParquet vs. GeoJSON: ¿Qué formato GIS es mejor para conjuntos de datos grandes?

Si alguna vez has intentado abrir un archivo GeoJSON de 2 GB en QGIS o cargar un archivo de límites poligonales con varios millones de filas en un mapa interactivo, ya conoces la sensación de hundimiento de una pantalla congelada y un bloqueo por falta de memoria.

Durante más de una década, GeoJSON ha servido como la lengua franca universal de la cartografía web. Es transparente, legible por humanos y compatible de forma nativa con casi todas las bibliotecas de mapeo web y API REST en internet.

Sin embargo, los flujos de trabajo GIS modernos se ven radicalmente diferentes a como eran en 2008. Los profesionales geoespaciales de hoy ingieren rutinariamente gigabytes (o terabytes) de telemetría de movilidad IoT, huellas de edificios a nivel nacional, máscaras de segmentación derivadas de satélites y cuadrículas climáticas de alta frecuencia.

Cuando se aplican a conjuntos de datos a esta escala, GeoJSON no solo se ralentiza, sino que bloquea por completo las arquitecturas de datos.

Presentamos GeoParquet, una extensión geoespacial abierta y estandarizada para Apache Parquet que está incubando dentro del Open Geospatial Consortium (OGC).

En esta guía completa, comparamos GeoParquet y GeoJSON en cuanto a arquitectura, eficiencia de almacenamiento, rendimiento de lectura/escritura, preparación para la nube y ergonomía para desarrolladores para responder a una pregunta crítica: ¿Qué formato deberías elegir para conjuntos de datos grandes?

1. Arquitectura estructural: Texto vs. columna binaria

Para entender por qué estos formatos se comportan de manera tan diferente a gran escala, debes mirar bajo el capó cómo cada uno representa los valores de coordenadas y los metadatos tabulares.

+--------------------------------------------------------------+
| Métrica de Evaluación |
| **Formato de datos** |
| **Representación geométrica** |
| **Relación de compresión** |
| **Proyección de columnas** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Pushdown de predicados espaciales** |
| **Almacenamiento de objetos en la nube (S3/GCS)** |
| **Legibilidad Humana** |
| **Compatibilidad con navegadores web** |
| **Organismo de estandarización** |
+--------------------------------------------------------------+

GeoJSON: orientado por filas, JSON codificado en texto

GeoJSON representa los datos como una matriz de objetos JSON. Cada característica repite explícitamente las claves de atributos junto a una matriz de números de punto flotante codificados como cadenas:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": { "county": "Travis", "state": "TX", "pop_density": 1845.2 },
      "geometry": {
        "type": "Point",
        "coordinates": [-97.74306, 30.26715]
      }
    }
  ]
}

Porque GeoJSON es basado en texto:

• Esquemas repetitivos: Nombres de campo como "properties", "type" y "coordinates" se repiten millones de veces, inflando el tamaño bruto del archivo.
• Conversión costosa de cadena a flotante: Tu CPU debe analizar los caracteres de texto ("-", "9", "7", ".", "7"...) en flotantes de doble precisión IEEE de 64 bits antes de realizar cualquier operación espacial.
• Requisitos de lectura monolítica: Los analizadores JSON estándar deben cargar todo el archivo en memoria para construir el Modelo de Objeto de Documento (DOM). Leer un atributo requiere analizar cada característica.

GeoParquet: orientado por columnas, datos codificados en binario

GeoParquet se basa directamente en Apache Parquet, almacenando tablas espaciales columna por columna en lugar de fila por fila.

Los atributos como county se almacenan en bloques contiguos, lo que permite técnicas avanzadas de compresión como codificación por longitud de ejecución (RLE), empaquetado de bits y compresión por diccionario. Los datos de geometría se estandarizan como Well-Known Binary (WKB), acompañados de metadatos JSON incrustados que detallan los sistemas de referencia espacial (CRS), cajas delimitadoras y tipos de geometría.

Porque GeoParquet es binario y columnar:

• Costo Cero de Análisis de Coordenadas: Las geometrías se almacenan directamente en forma binaria, evitando conversiones costosas de cadena a número flotante.
• Proyección Pushdown: Si tu flujo de trabajo posterior solo necesita las columnas county y pop_density, el lector recupera solo esos desplazamientos de bytes del disco o S3, omitiendo completamente la columna de geometría.
• Particionado por Grupos de Filas: Los archivos Parquet dividen los registros en “Row Groups” autónomos (a menudo de 100,000 a 1,000,000 de filas cada uno) completos con estadísticas de min/max para cada columna.

2. Comparación directa: Métricas clave

3. Eficiencia de almacenamiento y referencias de tamaño de archivo

Al escalar de miles a millones de registros, las disparidades de almacenamiento se amplían dramáticamente.

En pruebas estándar que utilizan registros espaciales abiertos del mundo real (como los contornos de edificios de OpenStreetMap, los límites TIGER del Censo de EE. UU. y los registros AIS de barcos a nivel global), GeoParquet logra rutinariamente reducciones de almacenamiento del 70 % al 85 % en comparación con GeoJSON sin procesar, y supera a .geojson.gz en un 20 % a 40 % adicional.

¿Por qué GeoParquet es mucho más pequeño?

1. Codificación de diccionario: Los atributos de cadena repetidos (p. ej., códigos de estado, clasificaciones de uso del suelo) se indexan en pequeños punteros enteros en lugar de almacenarse repetidamente como cadenas largas.
2. Coordenadas binarias compactas: Un punto 2D en GeoJSON ocupa alrededor de 30 a 45 bytes de texto ASCII ([-122.4194155, 37.7749295]). En WKB, ese mismo par de coordenadas requiere exactamente 16 bytes.
3. Algoritmos de compresión modernos: Zstandard (Zstd) y Snappy comprimen matrices de bytes columnares mucho más eficazmente que el Gzip estándar puede comprimir texto intercalado basado en filas.

4. Rendimiento de consultas y flujos de trabajo nativos en la nube

El mayor diferenciador para conjuntos de datos grandes no es solo el almacenamiento, sino la latencia de consultas y la utilización de memoria.

1. Lecturas selectivas mediante proyección de columnas

Imagine un conjunto de datos nacional de parcelas de 15 GB que contiene 60 atributos (nombres de propietarios, identificaciones fiscales, historial de escrituras, códigos de zonificación y límites multipoligonales complejos).

• En GeoJSON: Si desea calcular el valor promedio tasado de la propiedad por código postal, su motor analítico tiene que descargar y analizar los 15 GB completos, incluidos millones de vértices de límites complejos.
• En GeoParquet: Los motores analíticos como DuckDB, Apache Sedona, Polars o AWS Athena leen solo las columnas zip_code y assessed_value. En lugar de transferir 15 GB, su motor descarga y escanea menos de 80 MB.

2. Solicitudes de rango HTTP en almacenamiento en la nube

GeoParquet funciona sin problemas como un formato geoespacial nativo de la nube.

Debido a que los archivos Parquet almacenan los desplazamientos internos y los metadatos en el pie de archivo, las bibliotecas cliente pueden emitir solicitudes HTTP GET Range: bytes=... a almacenes de objetos en la nube como Amazon S3, Google Cloud Storage o Azure Blob Storage. En lugar de descargar un archivo de varios gigabytes completo, el cliente lee el pie de página, identifica los desplazamientos exactos donde se encuentran los registros relevantes y descarga solo los subconjuntos necesarios.

Client (DuckDB / Python / QGIS)
       │
       ├── 1. Read footer metadata (HTTP Range Request) ───► Cloud Storage (S3 / GCS)
       │                                                              │
       ◄── 2. Returns column offsets & row-group stats ───────────────┘
       │
       ├── 3. Read ONLY requested column chunks & ranges ─────────────►
       │                                                              │
       ◄── 4. Fast binary stream (minimal I/O & egress) ──────────────┘

5. Ecosistema de software y soporte de herramientas

Históricamente, la principal ventaja de GeoJSON era el soporte universal de herramientas. Si bien eso sigue siendo cierto para entornos de navegador, el ecosistema de GeoParquet ha madurado rápidamente:

• GIS de escritorio: Soporte nativo de lectura/escritura en QGIS 3.28+, ArcGIS Pro y GDAL/OGR 3.5+.
• Motores y lenguajes analíticos: Capacidades rápidas de lectura/escritura vectorizada en Python (GeoPandas, pyarrow), R (sf), DuckDB (a través de la extensión espacial), Apache Sedona y Snowflake.
• Canales de Big Data: Integración nativa en Apache Spark, Trino, Presto y Databricks.
• Mapas web del lado del cliente: Bibliotecas ligeras de WebAssembly (como parquet-wasm y duckdb-wasm) ahora permiten que los navegadores web consulten archivos GeoParquet directamente en los dispositivos del cliente sin un servidor middleware GIS dedicado.

6. Matriz de decisión práctica: ¿Cuándo usar cuál?

                                Dataset Size & Use Case
                                           │
             ┌─────────────────────────────┴─────────────────────────────┐
             ▼                                                           ▼
     Under 50–100 MB                                              Over 100 MB
(API payloads, simple maps)                                (Data warehousing, big data)
             │                                                           │
             ▼                                                           ▼
      Use **GeoJSON**                                            Use **GeoParquet**
• Direct Mapbox/Leaflet integration                        • High compression ratios
• Human-readable inspection                                • Sub-second analytical queries
• Standard REST API responses                              • Direct S3/GCS HTTP range reads

Elija GeoJSON si:

• Su conjunto de datos está entre 50 MB y 100 MB.
• Está devolviendo respuestas de carga útil ligeras desde una API REST a los clientes front-end.
• Está creando mapas web ligeros usando Leaflet, MapLibre o Mapbox GL JS sin capas de traducción intermedias.
• Necesita edición o inspección manual rápida en un editor de código o texto estándar.

Elija GeoParquet si:

• Su conjunto de datos supera los 100 MB, o contiene cientos de miles de características espaciales complejas.
• Está almacenando activos vectoriales en almacenamiento de objetos en la nube (S3, GCS, MinIO, Azure Blob).
• Ejecuta análisis SQL espacial, ingeniería de características o pipelines de aprendizaje automático usando Python, DuckDB, Spark o Databricks.
• Desea reducir los costos de almacenamiento, evitar tarifas de salida de red y eliminar fallos de memoria.

7. Ejemplo de migración: Convertir GeoJSON a GeoParquet

Convertir los activos espaciales existentes a GeoParquet requiere solo unas pocas líneas de código.

Usando Python (GeoPandas)

import geopandas as gpd

# 1. Read the legacy GeoJSON file
gdf = gpd.read_file("large_boundaries.geojson")

# 2. Write directly to GeoParquet using modern Zstandard compression
gdf.to_parquet("large_boundaries.parquet", compression="zstd")

Usando GDAL / OGR (CLI)

ogr2ogr -f Parquet \
  -oo LCO:COMPRESSION=ZSTD \
  large_boundaries.parquet \
  large_boundaries.geojson

Usando DuckDB

INSTALL spatial;
LOAD spatial;

-- Direct convert via SQL
COPY (
  SELECT * FROM ST_Read('large_boundaries.geojson')
) TO 'large_boundaries.parquet' 
WITH (FORMAT PARQUET, COMPRESSION 'ZSTD');

8. Resumen: El veredicto sobre conjuntos de datos grandes

Para conjuntos de datos pequeños y puntos finales web directos, GeoJSON sigue siendo un formato utilitario confiable y sin complicaciones.

Sin embargo, para conjuntos de datos grandes, GeoParquet es objetivamente superior en cada categoría operativa. Proporciona huellas de archivo más pequeñas, una sobrecarga de almacenamiento significativamente menor, lecturas espaciales casi instantáneas y una integración nativa con los modernos almacenes de datos en la nube.

Si sus canalizaciones geoespaciales están gemiendo bajo el peso de archivos GeoJSON de gran tamaño, cambiar a GeoParquet es una de las actualizaciones de infraestructura más efectivas que puede realizar.

Preguntas frecuentes (FAQ)

Q1. ¿GeoParquet es un estándar GIS reconocido oficialmente? Sí, GeoParquet es un estándar abierto oficial mantenido bajo la guía del Open Geospatial Consortium (OGC).

Q2. ¿Puedo renderizar un archivo GeoParquet directamente en bibliotecas de mapeo web como Leaflet o Mapbox GL JS? Aunque no se analiza de forma nativa como GeoJSON, puede renderizar GeoParquet en navegadores usando paquetes WebAssembly como parquet-wasm o convirtiendo los archivos a Vector Tiles (PMTiles/MVT) durante la ingestión.

Q3. ¿GeoParquet admite múltiples sistemas de referencia de coordenadas (CRS)? Sí, a diferencia de GeoJSON (que está estrictamente limitado a WGS 84 / EPSG:4326 según RFC 7946), GeoParquet permite definiciones de CRS personalizadas directamente dentro de los metadatos incrustados del archivo.

P4. ¿Cómo se compara GeoParquet con FlatGeobuf para grandes conjuntos de datos espaciales? FlatGeobuf está optimizado para transmitir características espaciales directamente a mapas web interactivos usando indexación espacial R-Tree, mientras que GeoParquet está diseñado para análisis columnar de alto rendimiento, compresión y almacenamiento masivo en lagos de datos.

P5. ¿Puedo abrir archivos GeoParquet dentro del software GIS de escritorio como QGIS? Sí, las versiones modernas de QGIS (versión 3.28 y superiores) admiten arrastrar, soltar, visualizar y aplicar estilos a los archivos GeoParquet sin requerir complementos de terceros.

Ver también

Formatos de archivos GIS en FileFormat.com

Los 5 principales formatos de archivos GIS para Google Maps

Noticias de formatos de archivo

Foros de formatos de archivo