Arquitectura GIS estado del arte en 2026: dos blueprints completos

Fuentes revisadas: 2026-08-11. Esta guía distingue estándares aprobados, especificaciones comunitarias, funciones generalmente disponibles, capacidades beta y recomendaciones de arquitectura de GeoSAT. Una tecnología reciente no es automáticamente adecuada para producción; una tecnología madura tampoco es obsoleta si sigue resolviendo el trabajo con seguridad, trazabilidad y un costo controlado.

La conclusión en una página

El GIS estado del arte de 2026 no es un visor, una geodatabase ni una marca. Es una plataforma de datos espaciales en la que cada carga de trabajo tiene un lugar deliberado:

• los datos editables y autorizados viven en un sistema transaccional de registro;
• los rásteres, vectores analíticos, cubos, nubes de puntos y escenas 3D se distribuyen en formatos adecuados para lecturas parciales;
• los catálogos describen propietario, licencia, calidad, linaje, vigencia y localización;
• el procesamiento puede ser local, distribuido, batch o streaming según una medición, no según una moda;
• las APIs, teselas y archivos estáticos separan los datos de las aplicaciones;
• identidad, seguridad, observabilidad, recuperación y costos atraviesan todas las capas;
• la IA propone, clasifica o automatiza, pero opera con herramientas controladas y resultados evaluables.

Este artículo desarrolla dos sistemas completos. El Blueprint A es abierto y cloud-native, con PostGIS como registro transaccional y object storage como plano analítico. El Blueprint B está centrado en ArcGIS Enterprise 12.1 y conserva interfaces abiertas hacia los demás sistemas corporativos. No hay un ganador universal. La decisión depende de flujos especializados, talento, licenciamiento, requisitos de soporte, capacidad operativa y libertad de salida.

La arquitectura híbrida también puede ser el resultado correcto. No consiste en instalar dos plataformas para todo: consiste en definir qué capacidad especializada permanece en ArcGIS, qué información se gobierna en sistemas abiertos, qué contrato las conecta y cómo se prueba que ninguna interfaz guarda la única copia de una regla o un dato crítico.

Qué significa “estado del arte” en 2026

“Estado del arte” debe describir cualidades verificables, no una lista de productos. Una arquitectura merece el término cuando demuestra:

1. Interoperabilidad. Los consumidores acceden mediante contratos documentados y los datos pueden salir con geometría, atributos, relaciones, historial y metadatos útiles.
2. Ajuste a la carga. Editar un predio, explorar mil millones de observaciones y transmitir una escena 3D no se fuerzan dentro del mismo motor.
3. Gobierno. Cada producto tiene responsable, fuente, licencia, fecha de corte, reglas de calidad y política de retención.
4. Seguridad verificable. La identidad se propaga, el privilegio es mínimo, los secretos no viven en código y los accesos sensibles quedan auditados.
5. Operabilidad. Existen métricas, logs y trazas; objetivos de nivel de servicio; alertas accionables; respaldos y restauraciones probadas.
6. Resiliencia. La degradación es explícita. La caída de un mapa no destruye el acceso a información esencial y la recuperación tiene RTO y RPO acordados.
7. Automatización. Infraestructura, configuración, pruebas y despliegue son repetibles; una instalación artesanal no es el único conocimiento del sistema.
8. Costo visible. Se conocen costos por almacenamiento, consulta, transferencia, cómputo, licencias y operación, incluidos cinco años de evolución.
9. Preparación para IA. Datos y evaluaciones están versionados; los modelos no evaden permisos, CRS, reglas de calidad ni aprobación humana.
10. Reemplazabilidad. Cambiar un visor, un motor analítico o un proveedor no obliga a reconstruir la identidad territorial desde cero.

Un monolito puede seguir siendo útil, y un clúster de Kubernetes puede estar mal diseñado. La modernidad arquitectónica no se mide por el número de contenedores, sino por la claridad de responsabilidades y la evidencia operacional.

Qué cambió: de servidores de mapas a plataformas de datos espaciales

El primer cambio es la evolución de los contratos. El catálogo oficial de estándares OGC ya reúne OGC API Features, Tiles, Maps, Records, Processes y Environmental Data Retrieval, además de SensorThings, Moving Features, 3D Tiles y formatos geoespaciales. El programa OGC API usa recursos HTTP, JSON y descripciones OpenAPI. WMS, WFS y otros servicios anteriores no desaparecen: siguen siendo necesarios para clientes y contratos existentes. La decisión responsable es publicar la interfaz que requieren los consumidores y diseñar una transición, no renombrar un endpoint como “moderno”.

La publicación de JSON-FG en 2026 amplió el modelo familiar de GeoJSON para soportar sistemas de referencia distintos a WGS 84, geometrías adicionales y semántica de tipos. Eso reduce una tensión histórica entre la sencillez web y los requisitos de datos profesionales, pero la compatibilidad de cada cliente todavía debe probarse.

El segundo cambio es el acceso parcial sobre object storage. Un Cloud Optimized GeoTIFF organiza teselas y pirámides para reducir solicitudes durante lecturas remotas; el driver COG de GDAL también permite crear y validar el resultado. GeoParquet 1.1 almacena vector en Parquet y puede incluir coberturas bbox por fila para que estadísticas y filtros eviten leer grupos irrelevantes. COPC 1.0 organiza LAZ 1.4 en un octree dentro de un solo archivo para seleccionar subconjuntos de una nube de puntos. 3D Tiles 1.1 transmite fotogrametría, edificios, BIM/CAD, entidades y point clouds mediante una jerarquía espacial.

Ninguno de esos formatos reemplaza una base transaccional. Optimizan lectura, distribución y análisis. Sobrescribir un COG o un GeoParquet por cada edición multiusuario sería confundir un artefacto de publicación con el registro autorizado.

El tercer cambio es la convergencia columnar. GeoArrow 0.2 define layouts y metadatos de tipos espaciales para Apache Arrow, facilitando intercambio en memoria y potencialmente menos copias entre motores. Su versión 0.2 exige prudencia: es una especificación prometedora y ya cuenta con implementaciones, pero no debe venderse como un contrato tan asentado como Simple Features. GeoParquet es una especificación de archivo; GeoArrow cubre representación en memoria y transporte. Son complementarios, no sinónimos.

El cuarto cambio es que “big data” dejó de significar “clúster primero”. DuckDB Spatial lleva operaciones geoespaciales a un motor embebido; Apache Sedona ofrece ejecución local y distribuida sobre Spark o Flink, además de soporte vectorial y ráster. La arquitectura de 2026 comienza con el motor más simple que cumple tiempos, concurrencia y volumen medidos. Distribuye cuando la evidencia muestra que una sola máquina, el particionamiento o la ventana operacional ya no bastan.

Finalmente, 3D, tiempo real y GeoAI dejaron de ser demostraciones aisladas. Deben compartir identidad, catálogo, observabilidad y políticas con el resto del GIS. Un gemelo digital sin vigencia ni enlace al activo autorizado es una escena bonita; un modelo geoespacial sin evaluación local es una hipótesis; un feed en tiempo real sin retención, reloj y manejo de eventos tardíos es una animación.

El modelo común de diez capas

Los dos blueprints usan el mismo modelo para que la comparación sea honesta.

Hay, además, tres planos transversales. Identidad debe viajar desde la persona o sistema hasta la operación autorizada. Proveniencia debe unir salida, proceso, versión de código e insumo. Telemetría debe conectar la acción del usuario con API, motor y almacenamiento sin registrar datos personales innecesarios.

Blueprint A: GIS abierto y cloud-native

El flujo de referencia es:

campo · sensores · EO · drones · LiDAR · BIM · sistemas corporativos
                              ↓
              validación, identidad y contratos de ingestión
                              ↓
       PostgreSQL/PostGIS ←→ object storage geoespacial
               ↓                         ↓
       cambios autorizados      COG · GeoParquet · Zarr
                                  COPC · 3D Tiles
               └──────────→ catálogo y linaje ←──────────┘
                                      ↓
                jobs · SQL espacial · streaming · GeoAI
                                      ↓
          OGC API · REST · vector tiles · CDN · descargas
                                      ↓
             QGIS · web 2D/3D · móvil · integraciones
                                      ↓
                       métricas y retroalimentación

“Cloud-native” aquí significa que los activos pueden aprovechar object storage, lecturas por rango, escalado independiente y automatización. No significa que todo deba estar en nube pública ni que una instalación on-premises quede descartada. Un almacenamiento compatible con S3 puede operar en infraestructura propia; el patrón importa más que el logotipo.

Separar edición, análisis y publicación

La frontera más importante está entre el registro y los productos. Una edición aprobada entra en PostGIS; un proceso incremental produce GeoParquet o teselas; el catálogo registra versión y fecha; los consumidores leen el producto apropiado. Si una aplicación necesita el estado más reciente y una transacción consistente, consulta una API conectada al registro. Si necesita recorrer toda la historia o unir grandes conjuntos, consulta la copia analítica.

Esta separación permite escalar lectura sin multiplicar réplicas operativas, pero introduce obligaciones: definir latencia aceptable, hacer idempotente la publicación, reconciliar conteos, retirar versiones y alertar cuando un producto queda atrasado.

Procesamiento sin sobrearquitectura

Una consulta interactiva sobre archivos particionados puede resolverse en DuckDB Spatial o SedonaDB. Un join nacional periódico puede requerir partición y ejecución distribuida. Un feed continuo puede justificar Flink. La decisión se toma con datos representativos y objetivos como duración, concurrencia, memoria, costo y ventana de recuperación. “Tenemos muchos gigabytes” no es una arquitectura.

Kubernetes tampoco es un requisito. Es útil cuando la organización ya opera la plataforma, necesita reconciliación declarativa, aislamiento y escalado de servicios, y puede sostener upgrades, políticas y observabilidad. Para un equipo pequeño, servicios administrados o máquinas automatizadas pueden ofrecer mayor confiabilidad con menos superficie.

GeoAI como plano gobernado

El modelo no debe conectarse sin límites a la base productiva. Un patrón seguro presenta herramientas con esquemas, permisos, límites espaciales y temporales; registra solicitud, versión de modelo y herramienta; valida CRS y geometría; ejecuta análisis determinista; y devuelve evidencia para revisión. Entrenamiento, inferencia y evaluación usan conjuntos separados. Las métricas incluyen exactitud por territorio y clase, no solo una media global.

Cuatro errores invalidan este blueprint:

• usar object storage como base editable multiusuario;
• instalar Spark o Kubernetes antes de medir la carga;
• asumir que todo dato geográfico debe ser público;
• tratar “open source” como sinónimo de operación gratuita o soporte automático.

Blueprint B: ArcGIS Enterprise 12.1 como núcleo

ArcGIS Enterprise 12.1 para Windows y Linux fue presentado por Esri en mayo de 2026 como la primera versión de soporte prolongado de la generación 12.x. La publicación oficial de ArcGIS Enterprise 12.1 documenta, entre otras funciones, Metrics API para Windows/Linux, integración con Prometheus y Grafana, mejoras de caché y disponibilidad general de Data Pipelines. ArcGIS Enterprise 12.1 on Kubernetes se publicó después con su propia descripción oficial. No se debe asumir paridad de roles ni una ruta de migración idéntica: la matriz de funcionalidad y los requisitos vigentes mandan.

La Architecture Center de Esri plantea arquitecturas de referencia como blueprints lógicos que se adaptan a flujos reales. Esa es la lectura correcta: ArcGIS Enterprise tampoco es “instalar el base deployment y listo”.

ArcGIS Pro · campo · sensores · imagery · BIM · sistemas empresariales
                                  ↓
          enterprise geodatabase · hosted data · object store
                                  ↓
        Portal: identidad · grupos · ítems · metadatos · gobierno
                                  ↓
 feature · map · image · scene · tile · geoprocessing · stream services
                                  ↓
 Map Viewer · Scene Viewer · Experience Builder · Field Maps · SDKs
                                  ↓
      métricas · auditoría · automatización · backup · recuperación

        ↔ APIs y storage/lakehouse externos mediante contratos

Interfaces abiertas dentro de una plataforma propietaria

“ArcGIS-centered” no tiene que significar “ArcGIS-only”. El diseño conserva:

• datos exportables en formatos con geometría, relaciones, adjuntos y metadatos;
• código, notebooks, expresiones, configuraciones y automatización bajo control de versiones cuando el producto lo permita;
• APIs REST u OGC documentadas para consumidores externos;
• integración con object storage, data lake, warehouse, bus de eventos o API management corporativos;
• pruebas de que un consumidor alternativo puede leer un conjunto representativo;
• cláusulas contractuales de entrega, conocimiento, soporte y salida.

Las funciones de IA requieren la misma cautela. El asistente de ArcGIS Pro 3.7 fue anunciado como beta; puede ayudar con acciones, ArcPy o consultas, pero no reemplaza revisión de permisos, CRS, lógica ni resultado. Una beta no debe convertirse en dependencia de un proceso misional sin una alternativa documentada.

Comparación capa por capa

Cuándo gana cada blueprint —y cuándo conviene un híbrido

El blueprint abierto suele encajar cuando la organización necesita integrar muchos dominios, publicar datos a múltiples ecosistemas, controlar infraestructura y código, ejecutar analítica sobre grandes archivos, o evitar que el costo crezca por usuario. Requiere un equipo capaz de operar bases, APIs, seguridad, pipelines y observabilidad. Si ese equipo no existe ni está presupuestado, la libertad teórica puede convertirse en fragilidad.

ArcGIS Enterprise suele encajar cuando los flujos de edición, cartografía, campo, redes, parcelas, imagery o aplicaciones Esri ya tienen valor probado; cuando se necesita soporte de fabricante; o cuando el talento institucional está concentrado en ArcGIS. La integración reduce tiempo de ensamblaje, pero no elimina diseño, gobierno, pruebas, recuperación ni administración de licencias.

El híbrido se justifica cuando una capacidad ArcGIS especializada aporta más que su costo, mientras una capa abierta permite analítica, intercambio o aplicaciones independientes. Debe tener un límite pequeño y observable. Si cada dato se copia en ambos lados, cada regla se implementa dos veces y nadie puede explicar cuál manda, no es híbrido: es deuda duplicada.

Aplicación en Colombia

CRS, exactitud y atributos de área

El ABC de Origen Nacional del IGAC identifica MAGNA-SIRGAS / Origen Nacional como EPSG:9377 y documenta sus parámetros. Una arquitectura colombiana debe almacenar el CRS de origen, validar transformaciones con puntos de control, probar orden de ejes y registrar la versión de PROJ o rejilla utilizada. Convertir coordenadas no autoriza recalcular silenciosamente atributos de área: en procesos catastrales, el área reportada puede provenir de una proyección local con mayor exactitud y debe conservar su linaje.

Los frontends web seguirán usando con frecuencia WGS 84 o Web Mercator. Eso no convierte esos CRS en el registro técnico. La API debe declarar CRS y precisión; el proceso de publicación debe probar desplazamientos; los asistentes de IA no pueden decidir una reproyección por intuición.

LADM-COL donde corresponde

El Modelo Núcleo LADM-COL del IGAC establece una base semántica común para administración de tierras y modelos extendidos compatibles con ISO 19152. Es crítico en catastro y otros objetos territoriales relacionados; no es un esquema universal para inventarios ambientales, movilidad o telemetría. El blueprint debe incorporar LADM-COL cuando el dominio legal y operativo lo exige y conservar capas de integración para los demás sistemas.

ICDE, apertura y protección

El Acuerdo 003 de 2025 de la ICDE, publicado por la entidad en 2026, establece lineamientos para apertura y publicación de datos geoespaciales. Promueve acceso, interoperabilidad y reutilización, pero también protección de información sensible y privacidad. Por tanto, “open by default” no significa “publicar sin clasificación”.

Cada producto público debe identificar custodio, licencia o condición de uso, cobertura, resolución o escala, CRS, fecha de corte, frecuencia, calidad, endpoint y contacto institucional. Los datos restringidos necesitan fundamento, audiencia, control y auditoría. El catálogo debe permitir descubrir ambos sin exponer el contenido protegido.

Arquitectura empresarial y seguridad pública

El Marco de Arquitectura Empresarial de MinTIC conecta estado actual, estado objetivo y hoja de ruta de transformación. El Modelo de Arquitectura Empresarial integra el dominio de seguridad con la arquitectura institucional. Para una entidad pública, el GIS no es una excepción departamental: debe alinearse con identidad, interoperabilidad, seguridad, privacidad, gestión de TI, contratación y continuidad institucional.

Campo desconectado y sincronización

En zonas con conectividad intermitente, offline es un modo operativo, no una caché accidental. El diseño define paquetes, vigencia, tamaño, cifrado local, quién puede extraerlos, qué ocurre si dos brigadas editan el mismo objeto, cómo se resuelve un conflicto y qué evidencia demuestra sincronización. También ofrece formularios, tablas y estados comprensibles cuando el mapa base no carga.

Contratación con salida verificable

Un pliego o contrato de arquitectura GIS debería exigir resultados comprobables:

• exportación representativa de geometrías, atributos, adjuntos, relaciones, historial y metadatos;
• pruebas de API, rendimiento, concurrencia, accesibilidad y seguridad con datos del proyecto;
• inventario de componentes, versiones, licencias, cuentas, certificados y dependencias;
• código, IaC, pipelines, configuraciones y manuales bajo control de la entidad según el alcance;
• respaldos cifrados y una restauración observada contra RTO y RPO;
• métricas, alertas, runbooks y responsables;
• transferencia de conocimiento medida mediante una operación ejecutada por el equipo receptor;
• costo total a cinco años: licencia, infraestructura, transferencia, soporte, personal, upgrades, almacenamiento y salida.

Antipatrones: lo que ya no es estado del arte

• Visor como sistema. Identificadores, permisos y reglas solo existen en JavaScript o widgets.
• Geoportal sin catálogo. Se publican capas sin custodio, fecha, licencia, calidad ni política de retiro.
• Una base para todo. Edición, analítica masiva, tiles, temporales y logs compiten en el mismo recurso.
• Copia sin autoridad. Dos plataformas editan el mismo objeto y la reconciliación depende de una persona.
• Nube sin gobierno. Buckets públicos, transferencia impredecible, secretos locales y ausencia de lifecycle.
• Kubernetes ornamental. El equipo no puede actualizar, observar o recuperar el clúster que adoptó.
• IA sin evaluación local. Una demo global se convierte en decisión territorial sin muestras colombianas ni revisión experta.
• Backup declarado. Existen archivos, pero nadie ha medido una restauración completa.
• Interoperabilidad nominal. Hay WMS o REST, pero no contrato, límites, versión, ejemplos ni consumidor alternativo probado.
• Compra por lista. Se adquieren módulos antes de documentar usuarios, decisiones, cargas y criterios de aceptación.

Hoja de ruta: 90 días, 12 meses y 24 meses

Primeros 90 días: establecer verdad y límites

Inventariar datos, aplicaciones, servicios, integraciones, contratos, licencias y responsables. Identificar el registro autorizado por dominio. Medir cargas y fallos. Clasificar información. Probar exportación, respaldo y restauración de una muestra. Definir arquitectura objetivo, ADRs, SLO, RTO/RPO, modelo de identidad y un producto vertical pequeño que atraviese las diez capas.

El resultado no es una compra: es una línea base con riesgos, costos, flujos, dependencias y criterios de aceptación.

Doce meses: construir una plataforma operable

Implementar catálogo y metadatos mínimos, automatizar ambientes, separar un producto analítico del registro, publicar APIs o servicios versionados, incorporar observabilidad end-to-end y ejecutar restauraciones. Migrar uno o dos flujos de mayor valor sin Big Bang. Para IA, crear un conjunto de evaluación colombiano y aprobar un caso de uso con humano responsable.

El hito es que otro equipo pueda desplegar, operar y recuperar la plataforma usando repositorios y runbooks.

Veinticuatro meses: optimizar con evidencia

Retirar duplicados después de validar consumidores, ajustar partición y cachés con telemetría, automatizar calidad y linaje, escalar únicamente cargas que lo requieran, negociar licencias con uso medido y probar portabilidad. Incorporar 3D, streaming o GeoAI donde exista una decisión operacional y un dueño del resultado.

El hito no es “terminar la transformación”. Es tener un ciclo de arquitectura que mide, decide, cambia y vuelve a verificar.

Checklist de arquitectura y contratación

Antes de aprobar un diseño, pregunte:

1. ¿Cuál es el sistema de registro de cada objeto y qué componente puede editarlo?
2. ¿Qué productos son derivados, con qué latencia y cómo se detecta que quedaron atrasados?
3. ¿CRS, precisión, área, tiempo, fuente y licencia viajan sin pérdida?
4. ¿Cada API tiene versión, autenticación, autorización, límites, ejemplos y consumidores conocidos?
5. ¿Los archivos grandes permiten acceso parcial y tienen catálogo, checksum y lifecycle?
6. ¿La escala exigió el motor elegido o la tecnología llegó antes que la medición?
7. ¿Identidad y privilegios se aplican hasta la operación y se prueba la revocación?
8. ¿Se observa una solicitud desde la aplicación hasta datos y proceso sin filtrar información personal?
9. ¿Cuándo se restauró por última vez y qué RTO/RPO se midió?
10. ¿Qué ocurre cuando no hay red, falla WebGL o un servicio externo no responde?
11. ¿La IA tiene evaluación local, límites, registro y una persona que responde por el resultado?
12. ¿La entidad recibe datos, código, configuración, documentación y capacidad real de operar?
13. ¿Cuál es el costo total a cinco años y cuánto cuesta salir?
14. ¿Una prueba demuestra que un consumidor alternativo puede usar los activos críticos?

La decisión que debe quedar documentada

No elija entre “open source” y “Esri” en abstracto. Documente dominios, cargas, niveles de servicio, restricciones, capacidad del equipo y criterios de salida. Después asigne cada capa al componente que mejor cumple el contrato. Eso produce una arquitectura defendible y evita que una preferencia tecnológica reemplace el diseño.

GeoSAT puede ayudar a levantar el estado actual, diseñar el blueprint objetivo y convertirlo en una migración o implementación con criterios de aceptación. Revise nuestros servicios de SIG con ArcGIS y QGIS, interoperabilidad de datos geoespaciales, geoportales y visores WebGIS e IA geoespacial. Para profundizar, compare la arquitectura WebGIS sostenible y el análisis de modelos fundacionales y copilotos GIS en 2026.

La buena arquitectura no elimina decisiones. Hace visibles sus consecuencias, permite verificarlas y conserva una salida.