¿Dónde estamos ahora?

Algunas plataformas propietarias como CARTO (antes CartoDB), Mapbox o ArcGIS Online han crecido mucho y son las que dominan el panorama en el sector comercial. El paso de Mapbox a software propietario en el año 2020 fue un jarro de agua fría para la comunidad geoespacial open source.

En un mundo fuertemente competitivo de computación en la nube, una vez que un proveedor en la nube comienza a ofrecer un servicio, el resto seguramente lo seguirá pronto. Mapbox se había encontrado que estaba subvencionando el I+D para un gigante tecnológico de billones de dólares, Microsoft.

Además, abrir el código fuente pudo ser una estrategia de negocio freemium, para impulsar la adopción. Lo que está claro es que nadie puede decir que hay un motivo concreto para este cambio, sino varios motivos.

A los líderes de las empresas de núcleo abierto no les «importa» el espíritu del código abierto. Los CEOs de las compañías de núcleo abierto ven el código abierto como un “canal de ventas”. Es una manera de que los clientes descubran sus ofertas de pago, no es un fin en sí mismo.

Paul Ramsey

CARTO (antes CartoDB) y Google Maps también han evolucionado en sus planes de negocio, bien eliminando las cuentas gratuitas o limitando el numero de visitas.

Problemas actuales

Problema nº1: La fragmentación del ecosistema de herramientas FOSS4G

El ecosistema FOSS4G ha crecido mucho, pero no de forma siempre cohesionada. Esto ha generado un paisaje disperso, donde abundan herramientas especializadas, pero a veces con solapamientos, falta de interoperabilidad o enfoques muy diferentes.

Ejemplos y causas:

• Demasiadas librerías que hacen “casi” lo mismo: Leaflet, OpenLayers, MapLibre, Tangram, Cesium, etc., cada una con su propia curva de aprendizaje, documentación y ecosistema.
• Falta de estandarización moderna: Aunque existen estándares OGC, muchos proyectos implementan soluciones personalizadas.
• Stackes poco integrados: GeoServer no siempre se lleva bien con todas las librerías JS; MapCache, QGIS Server, PostGIS, etc., requieren bastante trabajo para integrarse fluidamente.

• Evolución asincrónica: Mientras algunas herramientas avanzan rápido (ej. MapLibre), otras quedan estancadas o se actualizan lentamente.

Problema nº2: Falta de mantenimiento de algunos proyectos

Varios proyectos que fueron fundamentales para el web mapping FOSS4G hoy están infrafinanciados, con pocos contribuidores activos, o sin actualizaciones regulares.

Ejemplos:

• CartoCSS / TileMill: Muy innovadores en su momento, pero dejaron de evolucionar con fuerza y fueron superados por otras herramientas.
• Leaflet: Aunque es muy usado, no evoluciona tan rápido, y muchos plugins están desactualizados.

• Algunos módulos de GeoServer también han sido descuidados.

Problema nº3: La experiencia del usuario

Muchas herramientas FOSS4G no están diseñadas con usuarios finales no técnicos en mente. Están pensadas para desarrolladores o expertos SIG, lo que hace que la experiencia de uso sea más árida comparada con soluciones comerciales.

Problemas típicos:

• Interfaces poco pulidas o inconsistentes (ej. paneles de configuración en GeoServer o QGIS Server).
• Falta de asistentes (“wizards”) o procesos guiados para tareas comunes.
• Documentación densa, escasa o desactualizada.

• Interacción menos intuitiva en visualizadores (Zoom, popups, filtros).

En cambio, las comerciales ofrecen:

• Interfaces elegantes y coherentes, diseñadas con mucho estudio de UX (ej. ArcGIS Online, Mapbox Studio, CARTO).
• Onboarding bien cuidado, con tutoriales interactivos.
• Edición WYSIWYG, arrastrar y soltar capas, plantillas listas.

• Flujo de trabajo optimizado para no expertos.

Problema nº4: el rendimiento

Las herramientas FOSS4G funcionan bien, pero muchas veces requieren una buena arquitectura, ajustes finos y conocimiento técnico para rendir igual que una solución comercial «lista para usar».

Problemas comunes:

• Renderizado de teselas más lento sin optimización (ej. con Mapnik o GeoServer o GeoWebCache mal configurados).
• Manejo menos eficiente de grandes volúmenes de datos (miles de features, cargas diferidas, clustering).
• Falta de optimización para dispositivos móviles.

• Ausencia de funcionalidades como precache automático, lazy loading o vector tiles por defecto.

Sin embargo, las soluciones comerciales ofrecen:

• Infraestructura escalable por detrás (CDNs, vector tiles optimizados, procesamiento paralelo).
• APIs pensadas para rendimiento desde el diseño (ej. Mapbox GL, Google Maps JS SDK).
• Compresión automática, retina support o animaciones fluidas.

• Capacidad de renderizado 3D, estilos dinámicos sin apenas esfuerzo.

¿Cómo podemos “hacerlo grande otra vez”?

En este apartado repasaremos las principales opciones de código abierto actuales. Porque sí, ha llegado el momento de recuperar el entusiasmo por los mapas en la web: Make web mapping (open source) great again!

• Apoyar activamente proyectos FOSS (dinero, contribuciones, difusión).
• Modernizar frameworks (ej. Leaflet + Svelte, OpenLayers + React).
• Reforzar el trabajo comunitario y las redes de colaboración.
• Crear documentación y experiencias educativas más accesibles.

• Retomar el espíritu hacker y experimental.

Librerías web mapping open source

Veamos una lista de librerías de mapas web disponibles actualmente. Existen muchas opciones, pero si añadimos la condición de que sean open source (código abierto), el número se reduce a cuatro:

1. Leaflet: probablemente la librería más utilizada en la actualidad. Es ligera, sencilla y con una amplia comunidad de usuarios y desarrolladores.
2. OpenLayers: la más madura y completa, con una trayectoria consolidada en el desarrollo de mapas web.
3. MapLibre: es una bifurcación (fork) del proyecto Mapbox, creado tras el cambio de licencia de este último de código abierto a cerrado.
4. Gleo es una biblioteca de visualización de mapas web basada en JavaScript y WebGL. Según su creador, Iván Sánchez Ortega, «es como reinventar la rueda de Leaflet/OpenLayers/MapLibre«, y ha sido desarrollada solo por él.