La transición hacia la tecnología geoespacial nativa de la nube: acceso, escalabilidad y el ecosistema de código abierto
Marco Hernandez
Autor: Ing. Marco Hernández · Geólogo, GIS Consultant & Data Engineer · Linkedin · Julio 2026
Introducción
Uno de los cambios más importantes que vive hoy el mundo geoespacial es el colapso del viejo flujo de trabajo “descargar → preprocesar → unir → analizar”.
Las arquitecturas SIG tradicionales se construyeron sobre un supuesto que ya no se sostiene: que los datos deben descargarse a la máquina local antes de trabajar con ellos. Durante décadas, el flujo estándar consistía en navegar por un portal FTP, descomprimir gigabytes de shapefiles o TIFF multibanda y cargarlos en un software de escritorio. Si se quería analizar una serie satelital de varios años o una cuenca hidrográfica regional, la máquina podía alcanzar su límite de memoria en cuestión de minutos.
El enfoque geoespacial nativo de la nube invierte por completo esa lógica. En lugar de llevar los datos al cómputo, llevamos el cómputo a los datos.
Gracias a especificaciones de archivo estándar, APIs de catálogo y herramientas modernas de Python, el ecosistema geoespacial se ha convertido en un conjunto componible de herramientas de ciencia de datos. Buena parte de esta democratización se debe al software de código abierto, en particular al trabajo de Qiusheng Wu y de la comunidad geoespacial abierta en general.
A continuación se explica cómo encajan las piezas de este nuevo stack, por qué importa y cómo se ve en un caso real: el análisis de un incendio forestal resuelto casi por completo con SQL espacial.
1. Los formatos base: COG, STAC y GeoParquet
El enfoque nativo de la nube se apoya en tres estándares abiertos diseñados específicamente para solicitudes HTTP por rangos y consultas sin servidor.
Cloud Optimized GeoTIFF (COG)
Un COG es un archivo TIFF estándar organizado internamente en teselas y con vistas generales submuestreadas (pirámides). Cuando está alojado en un bucket de S3 o de Google Cloud Storage, el cliente no necesita descargar el ráster completo de 500 MB para visualizar o analizar un área concreta. Mediante solicitudes HTTP GET por rangos, pide únicamente los bytes necesarios para la extensión de la vista o la resolución del análisis.
SpatioTemporal Asset Catalog (STAC)
Si los COG resuelven el problema del formato, descubrir millones de escenas en archivos globales requiere metadatos estandarizados. STAC ofrece una especificación basada en JSON para indexar activos geoespaciales en el espacio y en el tiempo. En lugar de mantener bases de datos de catálogo propietarias, los grandes archivos públicos (Landsat del USGS, Sentinel de la ESA, NOAA, Planet) exponen APIs STAC consultables.
GeoParquet
Los flujos de trabajo vectoriales se habían quedado atrás respecto a los ráster en eficiencia en la nube, dependiendo de shapefiles, GeoJSON o pesadas exportaciones de bases de datos. GeoParquet lleva a las geometrías la compresión columnar de Apache Parquet, la codificación por diccionario y la poda rápida de particiones. Al almacenar los metadatos de la envolvente (bounding box) en el pie de los archivos Parquet, los motores pueden omitir archivos o bloques completos que no intersectan el polígono de consulta.
2. Tender puentes: el ecosistema Python de código abierto
Los estándares abiertos necesitan software accesible para ser útiles. La comunidad geoespacial de código abierto, con contribuidores como Qiusheng Wu, ha dedicado los últimos años a conectar los activos en la nube con el entorno de ciencia de datos de Python.
Leafmap y geemap
La biblioteca geemap sitio web, desarrollada por Qiusheng Wu, abrió inicialmente Google Earth Engine al entorno interactivo de Jupyter. Su siguiente proyecto, leafmap, funciona como un paquete unificado de mapeo interactivo pensado desde el inicio para la nube.
Lo que distingue a leafmap sitio web es su integración estrecha con los formatos nativos de la nube. Basta con pasarle la URL de un COG remoto o apuntar a un ítem STAC público para que lo renderice dinámicamente, ya sea en el cliente o mediante servidores de teselas ligeros como TiTiler, sin almacenar archivos ráster locales.
import leafmap
m = leafmap.Map()
cog_url = "https://opendata.digitalglobe.com/events/mauritius-oil-spill/post-event/2020-08-12/105001001A085400/105001001A085400.tif"
m.add_cog_layer(cog_url, name="Escena satelital remota")
m
SQL espacial en proceso: DuckDB Spatial
Uno de los avances más relevantes de los últimos años es la combinación de DuckDB con su extensión espacial.
Ya no hace falta levantar una instancia de PostGIS ni configurar un servidor de base de datos empresarial solo para hacer uniones espaciales entre capas vectoriales. DuckDB puede evaluar predicados espaciales directamente sobre archivos Parquet remotos en almacenamiento de objetos, transmitiendo por HTTP solo los rangos de bytes relevantes.
INSTALL spatial;
LOAD spatial;
INSTALL httpfs;
LOAD httpfs;
-- Consultar un GeoParquet remoto sin descargar el archivo
SELECT
name,
ST_Area(
ST_Transform(geometry, 'EPSG:4326', 'EPSG:32618', always_xy := true)
) AS area_m2
FROM read_parquet('s3://my-spatial-bucket/building_footprints.parquet')
WHERE ST_Intersects(geometry, ST_Point(-77.0369, 38.9072));
Visualización vectorial de alto rendimiento: Lonboard
Renderizar millones de vértices vectoriales en un navegador solía congelar el DOM. Con bibliotecas como lonboard, construida sobre GeoArrow y deck.gl, es posible enviar millones de puntos, líneas y polígonos directamente a la memoria de la GPU dentro de un notebook de Jupyter, con una latencia de serialización prácticamente nula.
3. Caso práctico: SQL espacial e imágenes nativas de la nube a escala
Para ver cómo funciona todo esto en la práctica, vale la pena revisar el análisis que publicó el equipo de Apache Sedona sobre el incendio forestal de Gironde y Landes, en Francia Ver aqui. El ejemplo muestra lo que ocurre cuando las imágenes satelitales se convierten en datos nativos de la nube: todo el proceso se reduce a SQL y NumPy, ejecutado con SedonaDB.
Imágenes como tablas consultables
Planet publica sus imágenes de crisis como Cloud Optimized GeoTIFF con metadatos en formato STAC-GeoParquet. SedonaDB lee ese catálogo directamente por HTTPS, y una consulta con ST_Intersects selecciona las 11 escenas PlanetScope que se superponen con el área de estudio: ocho previas al incendio y tres posteriores. La selección de escenas tomó unos dos segundos y no se descargó nada.
Alineación ráster en SQL
Cada escena se abre de forma diferida con RS_FromPath: los metadatos se cargan de inmediato y los píxeles permanecen en la nube hasta que se necesitan. Luego, RS_Clip y RS_ReprojectMatch alinean todas las escenas sobre una grilla de referencia de 12 m, promediando los píxeles originales de 3 m. Las seis consultas ráster (rojo, infrarrojo cercano y máscaras de datos válidos para ambas fechas) tardaron unos 11,5 minutos de principio a fin, en una sola máquina.
NumPy compone el mosaico con los ráster alineados, conservando el primer píxel despejado de cada celda. La cobertura alcanzó cerca del 87 % a pesar de las nubes, el humo y los huecos entre escenas.
Pérdida de vegetación como operación NumPy respaldada por SQL
Como era de esperar, la caída del NDVI entre ambas fechas señala la pérdida de vegetación. El método de Otsu estableció un umbral de 0,225 para los píxeles con NDVI saludable antes del incendio. La máscara de área quemada se convierte en un ráster dentro de la base de datos mediante Raster.from_numpy, lista para operar con SQL.
De píxeles a polígonos y estadísticas
Con RS_Polygonize, la máscara de 7 millones de celdas se transformó en 3.769 parches en unos tres segundos. Al filtrar los parches de 1 ha o más quedan 173 polígonos que cubren 24.091 ha; el mayor es una cicatriz de 21.090 ha entre Le Porge y Lanton. Finalmente, RS_ZonalStats calcula la superficie quemada por comuna en unos 14 segundos y produce una clasificación clara: Le Porge (6.202 ha), Saumos (4.045 ha), Lanton (3.499 ha), Arès (3.498 ha), entre otras.
Así se ve, en concreto, el análisis geoespacial a escala. Los datos permanecen en la nube y SQL transmite solo lo necesario. Las operaciones ráster se vuelven declarativas, en lugar de una maraña de scripts. NumPy actúa como motor de cómputo sin copias, no como un proceso separado. Los resultados son transparentes y versionables (polígonos, GeoParquet, GeoTIFF). Y el rendimiento es predecible: todo el procesamiento ráster tomó unos 12 minutos en una sola máquina.
La distancia entre la imagen en bruto y la información útil para decidir se está acortando, no porque las máquinas sean más grandes, sino porque por fin las abstracciones son las correctas.
4. Por qué importa este cambio de arquitectura
El paso hacia lo geoespacial nativo de la nube no es solo un cambio de herramientas: redefine la economía operativa y las capacidades de los equipos.
El primer efecto es la reducción de costos de infraestructura. Para el análisis exploratorio ya no se necesitan clústeres de bases de datos espaciales encendidos de forma permanente; las consultas sin servidor y el almacenamiento de objetos cuestan centavos frente a instancias de cómputo dedicadas.
El segundo es la reproducibilidad. Un script de análisis puede referenciar directamente registros STAC públicos y COG remotos, de modo que cualquier persona con acceso a internet puede ejecutarlo sin descargar gigabytes de insumos previos. El caso del incendio lo demuestra: cada paso, desde la selección de escenas hasta las estadísticas por comuna, queda expresado en consultas auditables.
El tercero es la separación entre cómputo y almacenamiento. Los equipos pueden hacer transformaciones puntuales con DuckDB en local, escalar a clústeres distribuidos con Dask o Apache Sedona cuando crece el volumen de datos y escribir los resultados de vuelta en GeoParquet sin alterar los esquemas de almacenamiento.
En conjunto, el SQL espacial sobre ráster nativos de la nube no es solo una comodidad: es la base de un análisis ambiental auditable, escalable y operativamente sensato.
5. El camino a seguir
El ecosistema geoespacial nativo de la nube madura con rapidez. A medida que estándares como GeoParquet alcancen una adopción empresarial amplia, y que tecnologías como WebAssembly y WebGPU permitan el procesamiento espacial dentro del navegador, la frontera entre la ingeniería de datos y el análisis espacial seguirá desdibujándose.
Para quienes buscan modernizar sus flujos de trabajo espaciales, el punto de partida es sencillo: dejar de descargar archivos. Catalogar los activos en STAC, convertir los archivos ráster a COG, almacenar los datos vectoriales en GeoParquet y usar bibliotecas como leafmap, DuckDB o SedonaDB para consultar los datos donde viven.
Para una demostración práctica de cómo funcionan estos formatos, se recomienda el tutorial de leafmap sobre integración de COG y STAC, en el que Qiusheng Wu muestra cómo consultar metadatos STAC y transmitir Cloud Optimized GeoTIFF directamente a un mapa interactivo sin descargar los ráster localmente.