MapGIS vs QGIS y PostGIS: comparación para Colombia
Qué compara realmente una entidad entre la suite MapGIS y una arquitectura con QGIS, PostGIS, servicios y visores abiertos. Matriz por capas, costos y flujos.
Respuesta corta: MapGIS, QGIS y PostGIS no son productos equivalentes. La suite MapGIS vigente de H&G reúne mapas, indicadores, tableros, reportes y módulos web o móviles. QGIS es un SIG para cartografía, edición, formularios y análisis. PostGIS amplía PostgreSQL para almacenar, indexar y consultar datos espaciales. Comparar MapGIS únicamente contra QGIS o PostGIS deja por fuera aplicaciones, servicios, seguridad, soporte y operación.
La comparación útil es MapGIS contra una arquitectura completa, evaluada flujo por flujo. Esa arquitectura puede combinar QGIS, PostGIS, APIs, servicios OGC, MapLibre u otros componentes, pero usar software abierto no garantiza por sí mismo menor costo, mejor arquitectura ni equivalencia funcional.
GeoSAT es una consultora independiente y no está afiliada, patrocinada ni respaldada por H&G Consultores. MapGIS pertenece a su respectivo titular. Las capacidades de MapGIS citadas son afirmaciones públicas del proveedor; una instalación concreta puede tener otra versión, módulos, personalizaciones e integraciones.
MapGIS vs QGIS: el error de compararlos como si fueran lo mismo
Una entidad puede abrir QGIS, editar una capa y concluir que “ya reemplazó MapGIS”. También puede instalar PostGIS y declarar que su SIG “ya es abierto”. Ninguna conclusión es suficiente.
QGIS resuelve muy bien trabajo de escritorio. PostGIS resuelve persistencia y operaciones espaciales. Una plataforma institucional también puede necesitar:
- visores web y móviles;
- autenticación, roles y auditoría;
- formularios y reglas de negocio;
- servicios e integraciones con otros sistemas;
- reportes, tableros y exportaciones;
- edición multiusuario y control de calidad;
- trabajo offline o captura de campo;
- monitoreo, copias, recuperación, soporte y SLA.
Por eso una alternativa a MapGIS no es una descarga. Es un sistema diseñado, operado y aceptado por los usuarios.
Comparación por capas
| Capa o necesidad | MapGIS | QGIS | PostGIS | Arquitectura abierta completa |
|---|---|---|---|---|
| Consulta web y móvil | La suite publica capacidades web, móviles y módulos especializados | No es una plataforma web por sí solo | No tiene interfaz de usuario | Requiere visor, frontend y servicios definidos |
| Cartografía y edición | Depende de la versión, módulos e integración instalada | Es una capacidad central, con edición, formularios, impresión y análisis | Conserva y valida los datos, pero no diseña mapas | QGIS puede ser el escritorio conectado a datos y servicios comunes |
| Base de datos espacial | Debe auditarse dónde residen los datos y qué dependencias existen | Se conecta a varias fuentes | Es su función principal sobre PostgreSQL | PostGIS puede convertirse en autoridad de datos desacoplada del visor |
| APIs e interoperabilidad | H&G afirma compatibilidad e interoperabilidad; deben verificarse contratos y alcances reales | Consume y publica estándares mediante componentes del ecosistema | Se integra con herramientas como QGIS, GeoServer, MapServer y ArcGIS | APIs y servicios se diseñan como contratos independientes de la interfaz |
| Tableros, reportes y formularios | La suite declara estas capacidades en módulos | Tiene formularios, layouts, atlas y reportes de escritorio | Almacena datos y consultas, no presenta el flujo | Se implementan con componentes web, BI, QGIS u otras aplicaciones |
| Licenciamiento | Depende del contrato, versión, módulos, soporte e infraestructura | GPL; no cobra licencia por usuario | GPL; no cobra licencia por usuario | Sigue teniendo costos de diseño, migración, nube, seguridad, soporte y evolución |
| Soporte y responsabilidad | Pueden estar concentrados en proveedor y contrato | Comunidad y proveedores profesionales | Comunidad y proveedores profesionales | La organización debe definir responsables, SLA y continuidad entre componentes |
La tabla no declara un ganador universal. Explica por qué la decisión debe hacerse por arquitectura y operación.
Cuándo conservar o actualizar MapGIS
Conservar puede ser la mejor decisión cuando los flujos críticos funcionan, la versión y sus componentes tienen soporte, el costo total está justificado y la organización puede recuperar la operación ante una falla.
Actualizar con el proveedor puede ser preferible cuando existe una ruta documentada que reduce dependencias, conserva personalizaciones valiosas y tiene criterios claros de aceptación. La revisión de MapGIS 5, 9 y 10 muestra por qué no debe inferirse la arquitectura actual a partir de una versión histórica.
Las preguntas mínimas son:
- ¿Qué versión y módulos están realmente en producción?
- ¿Dónde viven los datos maestros y quién controla su esquema?
- ¿Qué APIs, servicios, runtimes y SDK utiliza cada flujo?
- ¿Qué código y configuraciones pertenecen a la entidad?
- ¿Cómo se prueban seguridad, respaldo, recuperación y rendimiento?
- ¿Qué costo recurrente desaparecería y cuál permanecería?
Cuándo desacoplar con QGIS y PostGIS
Desacoplar significa retirar dependencias por capas sin apagar de inmediato una aplicación útil. Un programa puede comenzar por mover datos maestros a PostgreSQL/PostGIS, documentar esquemas, publicar APIs y servicios, y conectar QGIS para edición o análisis. El visor existente puede seguir consumiendo esos datos durante la transición.
El caso público de Cornare es importante precisamente porque no demuestra una sustitución total. La entidad reportó bases migradas a PostgreSQL y un cambio de ArcGIS a QGIS, mientras conservó e integró módulos MapGIS. Es evidencia de modernización híbrida, no de una regla universal.
Desacoplar resulta atractivo cuando:
- los datos necesitan ser reutilizados por varias aplicaciones;
- renovar una interfaz obliga a modificar demasiadas capas;
- la organización quiere pruebas independientes del proveedor del visor;
- existen integraciones o automatizaciones que deben sobrevivir al cambio de frontend;
- se necesita migrar por etapas y medir cada resultado.
Cuándo migrar componentes
Migrar es razonable cuando el componente sustituto ya pasó pruebas con datos, usuarios e integraciones reales. No prometemos cero pérdida de funcionalidad: la equivalencia se valida flujo por flujo con sus usuarios, datos e integraciones.
Una matriz de aceptación debe incluir al menos:
| Flujo | Evidencia antes de retirar el componente actual |
|---|---|
| Consultar una geometría | Misma fuente autorizada, atributos necesarios, tiempos y permisos aprobados |
| Editar y validar | Reglas, concurrencia, historial, rechazo y recuperación probados |
| Imprimir o reportar | Plantillas, escalas, leyendas, firmas y salidas aceptadas |
| Compartir un mapa | URL estable, permisos, filtros, metadatos y caducidad definidos |
| Integrar otro sistema | Contrato de API, errores, observabilidad y reintentos documentados |
| Operar en campo | Sincronización, conflicto, offline, dispositivo y soporte verificados |
| Recuperar una falla | Copia, restauración, RTO, RPO y responsables ensayados |
Si un flujo no tiene evidencia, todavía no existe equivalencia demostrada.
¿Cuánto cuesta MapGIS frente a una alternativa abierta?
No encontramos una lista pública universal que permita afirmar “MapGIS cuesta X”. Los contratos pueden incluir versiones, módulos, usuarios, soporte, mantenimiento, infraestructura, desarrollos e integraciones diferentes.
Un contrato público de Medellín documenta gasto recurrente en suscripción, soporte, mantenimiento y actualización de MapGIS 9.0. Sirve como evidencia de un caso contractual específico; no es una tarifa nacional ni la base para prometer porcentajes de ahorro.
La comparación correcta usa costo total de propiedad durante un período común:
Continuar = licencias + soporte + mantenimiento + infraestructura + actualizaciones + operación
Modernizar = diagnóstico + construcción/migración + convivencia + infraestructura + seguridad + soporte + evolución
El software abierto puede retirar licencias por usuario, pero no elimina personas, nube, seguridad, respaldo, pruebas ni mantenimiento. La calculadora de la demo GeoSAT OpenGIS muestra escenarios preliminares y advierte que el ahorro real puede ser cero o negativo.
Una alternativa a MapGIS que sí puede probarse
La demo GeoSAT OpenGIS no intenta reproducir una instalación de MapGIS. Demuestra capacidades aislables con datos abiertos y procedencia visible:
- catálogo nacional y consulta catastral del IGAC;
- amenaza volcánica, construcciones y eventos históricos en Cumbal;
- aptitud cafetera de UPRA en Calarcá;
- corredor 45A04 y puentes publicados por INVÍAS;
- filtros, consulta, medición, URL compartible y exportación GeoJSON.
Los casos tienen páginas propias con la pregunta, cifras de la instantánea, fuentes y límites. Eso permite evaluar evidencia antes de hablar de una plataforma completa.
Decisión recomendada
No empiece por escoger una marca. Empiece por inventariar flujos, datos, integraciones, contratos y riesgos. Después clasifique cada componente en una de cuatro rutas:
- Conservar, si cumple y su costo está justificado.
- Actualizar, si la ruta reduce riesgo con aceptación verificable.
- Desacoplar, si datos, APIs o reglas deben sobrevivir al visor.
- Migrar, cuando el sustituto pasó pruebas completas.
La auditoría de modernización MapGIS de GeoSAT entrega inventario técnico, mapa de dependencias, matriz de portabilidad, escenarios de costo total y una ruta con criterios de aceptación.
Preguntas frecuentes
¿QGIS reemplaza MapGIS?
No por sí solo. QGIS puede sustituir flujos de escritorio, edición, cartografía y análisis. Una plataforma web necesita además datos, servicios, aplicaciones, identidad, permisos, operación y soporte.
¿PostGIS reemplaza MapGIS?
No. PostGIS es una capa de datos y análisis espacial sobre PostgreSQL. Puede desacoplar y centralizar información, pero no ofrece por sí mismo la experiencia web o móvil de una suite.
¿GeoSAT afirma que MapGIS está obsoleto?
No. H&G mantiene una suite activa y ha publicado capacidades actuales. Una versión o dependencia concreta puede necesitar modernización, pero eso solo se determina auditando la instalación real.
¿Una arquitectura abierta garantiza ahorro?
No. Puede retirar algunos costos y crear otros. El resultado depende del alcance, convivencia, infraestructura, seguridad, soporte, equipo y velocidad de evolución.
¿Cómo se evita perder funcionalidad?
No se promete pérdida cero. Se definen criterios de aceptación y cada flujo se prueba con usuarios, datos e integraciones antes de retirar el componente anterior.