Ingeniería de datos para SIG en 2026: el stack que está reemplazando al SIG de escritorio

Marco Hernandez

marzo 20, 2026

Ingeniería de datos para SIG en 2026: el stack que está reemplazando al SIG de escritorio

Un panorama técnico, pensado para arquitectos de datos, sobre cómo el ecosistema geoespacial está migrando de formatos propietarios y bases de datos monolíticas hacia un stack columnar, cloud-native e interoperable con el resto del mundo de datos.

El cambio de fondo: de “capas que se visualizan” a “datos que se consultan”

Durante dos décadas, la ingeniería de datos SIG estuvo dominada por un supuesto implícito: los datos espaciales viven en un sistema aparte —un geodatabase, un PostGIS, un servidor de mapas— que se consulta con herramientas especializadas y se conecta al resto de la organización mediante exportaciones puntuales (shapefiles, GeoJSON, servicios WFS). Ese modelo funcionó mientras los volúmenes eran manejables y el consumo era mayormente cartográfico.

Ese supuesto se está rompiendo. La razón no es una moda: es que los volúmenes de datos espaciales (imágenes satelitales, huellas de edificios a escala planetaria, flotas de sensores IoT, trayectorias GPS) crecieron a un ritmo que los formatos y arquitecturas clásicas de SIG no fueron diseñados para sostener, mientras que en paralelo el resto de la industria de datos resolvía exactamente ese problema —almacenamiento columnar, cómputo distribuido, motores serverless— para datos tabulares. La ingeniería de datos SIG de los últimos dos años consiste, en gran medida, en llevar la geometría a esa infraestructura ya madura, en lugar de mantener un universo paralelo.

Esto se traduce en cuatro frentes concretos, que son el cuerpo de este artículo: formatos cloud-native para reemplazar shapefile/geodatabase, catálogos de datos autodescriptivos (STAC), motores de consulta espacial que se ejecutan sobre almacenamiento de objetos sin servidor dedicado, y esquemas de indexación espacial pensados para partición y escalado horizontal.

1. GeoParquet y el fin del shapefile como formato de intercambio

GeoParquet extiende Apache Parquet —el formato columnar creado en 2013 para el ecosistema Hadoop— con una forma estandarizada de almacenar geometría. No es un nuevo formato SIG: es Parquet con tipos geométricos.

Esa diferencia, aparentemente menor, tiene consecuencias arquitectónicas serias:

Lectura selectiva de columnas. Una consulta que solo necesita geometría y una columna de atributo no tiene que escanear el resto del esquema, algo imposible con shapefile o GeoJSON, que son formatos orientados a fila.
Streaming sobre almacenamiento de objetos. Un motor de consulta puede leer únicamente los row groups relevantes de un archivo Parquet alojado en S3 o GCS, sin descargar el archivo completo, gracias al footer con metadatos que Parquet incluye por diseño.
Interoperabilidad con el stack de datos general. El mismo archivo GeoParquet puede leerse desde Apache Spark, BigQuery, Snowflake o DuckDB sin capas de traducción, porque para esos motores sigue siendo “solo Parquet” con una extensión de metadatos que ya saben interpretar.

Overture Maps Foundation —el consorcio detrás del dataset abierto de edificios, direcciones, lugares y transporte a escala global, con participación de Amazon, Meta, Microsoft y TomTom— distribuye su catálogo completo exclusivamente en GeoParquet, particionado por tema y tipo, servido directamente desde buckets públicos en AWS y Azure. Es, hoy, probablemente el mayor caso de uso en producción del formato.

Un desarrollo técnico relevante de los últimos meses: Apache Parquet incorporó tipos GEOMETRY y GEOGRAPHY nativos en el propio sistema de tipos de la especificación, en lugar de depender —como hacía GeoParquet 1.x— de metadatos “sidecar” adjuntos a columnas binarias. Esto importa especialmente para arquitecturas de lakehouse: formatos de tabla como Apache Iceberg requieren tipos de dato de primera clase para garantizar interoperabilidad entre motores, algo que los metadatos adjuntos no podían sostener con solidez. Esta dirección —a veces referida informalmente como “GeoParquet 2.0”— mueve la geometría al núcleo del sistema de tipos en lugar de tratarla como una extensión.

Una precisión importante para quien esté evaluando una migración: GeoParquet no reemplaza a PostGIS ni a un geodatabase transaccional. Está optimizado para cargas de lectura intensiva —reporting, análisis exploratorio, feature engineering, distribución de datos entre equipos— no para edición interactiva, actualizaciones transaccionales ni flujos multiusuario con bloqueo de registros. La arquitectura que está emergiendo como patrón no es “GeoParquet en vez de PostGIS”, sino “PostGIS (u otro sistema operacional) para la escritura, GeoParquet en almacenamiento de objetos para el análisis y la distribución”.

2. STAC: el catálogo como capa de gobierno, no como documentación

SpatioTemporal Asset Catalog (STAC) es una especificación —impulsada originalmente por la comunidad de observación de la Tierra— para describir colecciones de activos espacio-temporales de forma estandarizada y navegable programáticamente: qué extensión espacial cubre un dataset, qué rango temporal, qué bandas o columnas contiene, y dónde están físicamente los archivos.

Lo que cambió en el último año es el rol que ocupa STAC en los pipelines de producción. Dejó de ser un artefacto de publicación —un catálogo generado al final del proceso, para que humanos lo navegaran— para convertirse en la fuente de verdad que orquesta el propio pipeline. Overture Maps es el ejemplo más citado: su cliente Python, su herramienta de exploración, sus procesos internos de control de calidad y sus pipelines de datos usan ahora el catálogo STAC de Overture como mecanismo de sincronización con cada release, en lugar de rutas de archivo codificadas manualmente.

Para un arquitecto de datos, la implicancia práctica es que un catálogo STAC bien construido resuelve tres problemas de gobierno de datos que antes se resolvían con documentación separada y, por lo tanto, se desactualizaban: descubribilidad (qué existe y dónde), versionado (qué cambió entre releases, mediante extensiones de changelog), y contratos de esquema (qué columnas y tipos garantiza cada colección). Existen ya extensiones de STAC orientadas específicamente a modelar pipelines como grafos de dependencias (DAGs), de forma que un cambio en un dataset de origen pueda propagar automáticamente qué productos derivados requieren reprocesamiento.

3. El motor de consulta se desacopla del almacenamiento

Quizás el cambio arquitectónico más significativo es la ruptura del vínculo histórico entre “dónde viven los datos” y “con qué motor los consulto”. El patrón emergente —descrito como spatial lakehouse o flujo zero-copy— consiste en mantener los datos espaciales en almacenamiento de objetos, en un formato columnar optimizado, y permitir que múltiples motores de cómputo los consulten directamente, sin copias intermedias para cada herramienta o equipo.

El panorama de motores que resuelven consulta espacial sobre este almacenamiento se ha vuelto denso en poco tiempo:

PostGIS sigue siendo el estándar de facto para cargas operacionales y transaccionales, y el punto de referencia de madurez funcional (funciones espaciales, índices GiST, soporte topológico) contra el que se miden las alternativas nuevas.
La extensión spatial de DuckDB se consolidó como herramienta esencial para análisis exploratorio local, conversión de formatos y consultas rápidas sobre archivos GeoParquet sin levantar infraestructura de servidor. Su madurez funcional todavía es menor que la de PostGIS, pero para el caso de uso de “un analista con un laptop y un bucket S3” ya es, de hecho, el estándar.
Apache Sedona, que nació como GeoSpark en 2015 y se graduó como proyecto top-level de Apache en 2023, resuelve el extremo distribuido del problema: procesamiento espacial a gran escala sobre Spark, Flink y Snowflake. En 2025 el proyecto lanzó SedonaDB, un motor analítico de nodo único, escrito en Rust sobre Apache DataFusion, pensado como alternativa nativa-espacial a DuckDB para cargas medianas que no justifican un clúster distribuido.
Los tres grandes data warehouses en la nube —BigQuery GIS, Snowflake y Redshift— incorporaron tipos GEOGRAPHY nativos y funciones espaciales en SQL estándar, permitiendo consultar GeoParquet directamente sin motor especializado adicional.
Apache Iceberg, el formato de tabla dominante para arquitecturas lakehouse, incorporó soporte nativo para tipos geoespaciales, lo que permite aplicar sobre datos espaciales las mismas garantías de time travel, evolución de esquema y transacciones ACID que ya existían para datos tabulares —una pieza que faltaba para tratar la geometría como ciudadana de primera clase en un lakehouse corporativo, en lugar de un anexo.

Para quien diseña arquitectura, la pregunta ya no es “¿qué base de datos espacial elijo?” sino “¿qué motor de consulta uso para cada carga de trabajo, sobre el mismo almacenamiento base?”. Es exactamente el patrón que la industria de datos general adoptó hace una década con Parquet y los motores de consulta SQL sobre almacenamiento de objetos; el ecosistema geoespacial lo está adoptando ahora, con varios años de retraso pero con la ventaja de partir de formatos y patrones ya probados.

4. Indexación espacial para partición y escalado horizontal

Un dataset de miles de millones de geometrías no rinde bien si se particiona arbitrariamente. El patrón que se está consolidando como buena práctica combina dos capas de indexación:

Rejillas jerárquicas discretas como H3 (hexagonal, desarrollada originalmente en Uber) o S2 (esférica, de Google) para partición: los datos se agrupan por celda de rejilla a una resolución elegida según el volumen, lo que permite distribuir el almacenamiento y paralelizar el cómputo por partición geográfica de forma predecible, algo que una partición por coordenadas continuas no ofrece.
Curvas de llenado del espacio, especialmente el orden de Hilbert, para el ordenamiento físico de los registros dentro de cada partición o row group. Ordenar filas espacialmente contiguas de forma físicamente contigua en el archivo reduce drásticamente el número de row groups que un motor debe leer para responder una consulta de proximidad o de bounding box —herramientas recientes del ecosistema GeoParquet automatizan esto por defecto (ordenamiento Hilbert, columnas de bounding box precalculadas, tamaño de row group ajustado) precisamente porque es la optimización de mayor impacto y la más fácil de omitir por descuido.

En el extremo de la capa de servicio, PMTiles —un formato de archivo único para colecciones completas de vector tiles, consultable directamente desde almacenamiento de objetos sin servidor de teselas dedicado— se ha convertido en el estándar de facto para publicar cartografía a escala planetaria sin mantener infraestructura de tile server. Overture Maps publica PMTiles listos para usar junto a su catálogo STAC en cada release; motores distribuidos como Apache Sedona ya generan tiles PMTiles de datasets de miles de millones de features en el orden de minutos, no de horas.

5. Qué significa esto para una arquitectura de datos SIG en 2026

Sintetizando los cuatro frentes anteriores en un patrón de referencia:

Almacenamiento: GeoParquet particionado (por H3 o por región administrativa) sobre almacenamiento de objetos, con Iceberg o Delta Lake como capa de formato de tabla si se necesita versionado y evolución de esquema.
Catálogo: STAC como capa de descubribilidad y contrato de esquema, integrado al pipeline de orquestación, no como documentación posterior.
Cómputo: motor elegido según la carga —DuckDB o SedonaDB para exploración local, Apache Sedona sobre Spark para procesamiento distribuido, un warehouse cloud (BigQuery/Snowflake) para SQL espacial ad hoc— todos apuntando al mismo almacenamiento base, sin duplicar datos por herramienta.
Capa operacional: PostGIS (u otro sistema transaccional) sigue siendo necesario donde hay edición interactiva, flujos multiusuario o reglas transaccionales; el lakehouse espacial no lo reemplaza, lo complementa como destino de lectura analítica.
Servicio: PMTiles para cartografía servida directamente desde object storage, sin tile server dedicado.

La migración completa de una organización grande hacia este patrón no es trivial —las estimaciones de la industria hablan de 6 a 12 meses para una migración bien ejecutada— y no todos los casos de uso lo justifican: un equipo de SIG de escritorio con cargas de trabajo moderadas puede no ver beneficio suficiente para justificar el costo de migración. Pero para cualquier organización que ya esté operando a escala de terabytes de datos espaciales, evaluando estos componentes como piezas de un mismo stack de datos —en lugar de mantener un universo geoespacial aislado del resto de la infraestructura de datos de la organización— es, a esta altura, el consenso técnico de facto.

Panorama elaborado a partir de documentación técnica y publicaciones de la comunidad geoespacial (Cloud Native Geospatial Forum, Overture Maps Foundation, Apache Sedona, Apache Parquet, DuckDB) durante 2025–2026. Artículo original para geologiaymapas.