GeoServer o QGIS Server, o MapServer: qué servidor de mapas elegir

En resumen

QGIS Server sirve un proyecto QGIS tal como lo construyó en QGIS Desktop, con sus estilos, etiquetas y composiciones. GeoServer publica capas independientes de un proyecto, con sus propios estilos SLD, y apunta a las infraestructuras de datos. MapServer es el más antiguo, muy rápido, configurado mediante un archivo de texto. Martin y pg_tileserv hacen una sola cosa: servir teselas vectoriales, sobre todo desde PostGIS.

Ninguno es mejor en términos absolutos. La elección depende de su herramienta de trabajo, de sus usuarios y del equipo que mantendrá el servidor.

Los servidores frente a frente

Todos estos programas son libres. Los lenguajes y funciones indicados son los de sus respectivos proyectos; consulte la documentación de la versión que instale.

Los estilos: donde más difieren los servidores

Sobre el papel, todos estos servidores publican WMS. En la práctica, la diferencia que más se nota en el día a día es la forma de describir la apariencia de los mapas. Ahí se deciden el tiempo de publicación, la calidad de la representación y la facilidad de mantenimiento.

• QGIS Server lee directamente el proyecto QGIS: simbología, etiquetas, reglas de escala, modos de fusión, composiciones de impresión. Lo que ve en QGIS Desktop es lo que dibuja el servidor, porque ambos comparten las mismas bibliotecas de representación.
• GeoServer usa el estándar SLD, un formato XML extenso pero normalizado. Extensiones oficiales permiten también escribir los estilos en CSS o en YSLD, más legibles. Un estilo de QGIS puede exportarse a SLD, pero las representaciones avanzadas (efectos, generadores de geometría, ciertas etiquetas) suelen perderse por el camino.
• MapServer describe los estilos en el mapfile, con bloques CLASS y STYLE y expresiones que deciden la clase de cada entidad. También sabe leer SLD. El formato es compacto y se revisa bien, pero se escribe a mano.
• Martin y pg_tileserv no aplican estilos: envían geometrías, y el estilo es un documento JSON que interpreta la biblioteca cliente, por ejemplo MapLibre. Cambiar un color no exige ninguna intervención en el servidor.

Consecuencia práctica: si sus mapas son ricos y ya están cuidados en QGIS, cualquier otro servidor le pedirá traducir esos estilos y después mantener dos versiones. Si sus capas son sencillas (rellenos, contornos, unas pocas clases), el formato importa poco y otros criterios, como la cobertura de estándares o el rendimiento, pasan al primer plano. Pruebe con tres de sus capas más complejas antes de decidir: es la forma más rápida de medir el esfuerzo real.

GeoServer o QGIS Server: la verdadera pregunta

Para la mayoría de los equipos que trabajan en QGIS, la elección está entre estos dos. La pregunta decisiva: ¿dónde viven sus estilos?

• Sus mapas se diseñan en QGIS y deben verse en la web igual que en pantalla: QGIS Server, con Lizmap encima para obtener un portal completo (búsqueda, edición, impresión).
• Difunde capas a socios que las usarán en sus propias herramientas (ArcGIS, OpenLayers, catálogo de datos): GeoServer, diseñado para publicar servicios OGC autónomos.
• Necesita los dos: es habitual. Un portal Lizmap para los usuarios, un GeoServer para los servicios de referencia. Una capa de GeoServer se añade además a un proyecto QGIS publicado en Lizmap como cualquier servicio WMS o WFS.

En LizPack, ambos funcionan juntos: LizPack Map incluye QGIS Server, y GeoServer Cloud ofrece un espacio GeoServer aislado que se vincula a su base PostGIS. Para el lado de Lizmap, vea alojar Lizmap o instalarlo uno mismo. Un caso frecuente ilustra el reparto: un ayuntamiento publica su plan urbanístico en un portal Lizmap, con búsqueda por parcela, impresión en A3 y edición de solicitudes por los técnicos. Las mismas zonificaciones se publican en GeoServer para el portal regional de datos, que las recolecta cada noche. Una sola base PostGIS alimenta a ambos, y una corrección hecha por la mañana aparece en todas partes.

MapServer: la velocidad, a cambio de la configuración

MapServer, nacido en la Universidad de Minnesota y hoy proyecto de la fundación OSGeo, sigue siendo una referencia para servir grandes volúmenes de mapas con pocos recursos. Todo se describe en un mapfile, un archivo de texto que define capas, fuentes y estilos.

Es una opción excelente para un equipo técnico cómodo con archivos de configuración y control de versiones. Para técnicos SIG que quieren publicar desde una interfaz, GeoServer o QGIS Server resultarán más accesibles.

MapServer no se limita al modo servidor: sus enlaces MapScript permiten controlar la representación desde Python u otros lenguajes, para generar mapas por lotes o integrar el motor en una aplicación. El proyecto, con licencia de tipo MIT, lo mantiene un comité de dirección dentro de la fundación OSGeo.

Rendimiento: lo que de verdad importa

Las comparativas de velocidad entre servidores circulan mucho, pero rara vez dicen gran cosa de su caso. Con datos reales, la diferencia entre dos servidores bien configurados suele ser menor que la diferencia entre una capa bien preparada y otra mal preparada en el mismo servidor. Antes de culpar al programa, revise estas palancas, válidas para todos:

• La caché de teselas. GeoServer integra GeoWebCache; MapServer suele acompañarse de MapCache; delante de QGIS Server, una caché de teselas evita volver a dibujar las mismas zonas. Un mapa consultado por muchos usuarios casi siempre debe pasar por una caché.
• La fuente de datos. Una tabla PostGIS indexada responde mucho mejor que un Shapefile grande o que un archivo leído desde un disco de red lento.
• Las reglas de escala. Mostrar todas las parcelas de un país a escala pequeña es costoso e ilegible; limite cada capa a las escalas en las que tiene sentido.
• Las etiquetas y los efectos. Las etiquetas con gestión de colisiones, las sombras y los efectos de capa cuestan caro. A menudo son ellos, y no las geometrías, los que ralentizan un proyecto QGIS publicado.
• Los ráster. Un GeoTIFF en teselas, comprimido y con vistas generales se lee mucho más rápido que una imagen sin optimizar del mismo contenido.

Para comparar con honestidad, mida el tiempo de respuesta de una misma petición GetMap, sobre la misma capa, con y sin caché, a dos o tres escalas. Conserve esas mediciones: también servirán para comprobar que una actualización del servidor no ha empeorado nada.

Martin y pg_tileserv: las teselas vectoriales

Las teselas vectoriales (formato MVT) envían al navegador geometrías recortadas, que la biblioteca cliente (MapLibre, OpenLayers) dibuja por sí misma. El resultado es fluido y el estilo cambia sin tocar el servidor. Convienen a los mapas públicos muy consultados, a los mapas base personalizados y a las aplicaciones móviles. Convienen menos cuando el usuario debe imprimir un mapa normalizado, consultar atributos completos u obtener exactamente la misma representación en todos los programas.

• Martin, proyecto de la comunidad MapLibre, sirve teselas desde PostGIS, MBTiles o PMTiles.
• pg_tileserv, publicado por Crunchy Data, expone tablas y funciones PostGIS como teselas con muy poca configuración.
• Ninguno sustituye a un WMS o un WFS: complementan un servidor OGC para mapas web públicos.

Ambos servidores se apoyan en la capacidad de PostGIS para producir por sí mismo teselas en formato MVT. Consecuencia práctica: el rendimiento depende sobre todo de la base, de sus índices y de la complejidad de las geometrías. Martin también sirve archivos GeoJSON y teselas ya generadas, lo que lo convierte en una buena opción para combinar datos vivos y mapas base estáticos.

Lo que exige la explotación de cada servidor

Elegir un servidor compromete durante años. Más allá de las funciones, mire lo que habrá que hacer cada mes para mantenerlo en servicio: quién sabe configurarlo, cómo se actualiza y qué exige de la máquina. Anote también quién, en su equipo, se enterará de un fallo de seguridad y sabrá aplicar la corrección en la semana: a menudo es el criterio que desempata entre dos servidores con funciones equivalentes. Escriba la respuesta antes de elegir, con un nombre junto a cada servidor.

Dos observaciones prácticas. Primero, los servidores no se excluyen: muchas organizaciones usan QGIS Server para sus portales y GeoServer para sus servicios de referencia, sobre la misma base PostGIS. Segundo, el coste real es el tiempo humano. Un servidor que nadie del equipo sabe actualizar acaba siendo un riesgo, por bueno que sea. Es el trabajo que asume LizPack, una infraestructura geoespacial de código abierto que orquesta estos programas sin sustituirlos: lo que hace LizPack detalla este reparto.

Los errores frecuentes al elegir

• Elegir por una lista de funciones. Los cuatro servidores cubren los estándares principales. Lo que marca la diferencia es su cadena de trabajo: dónde nacen los mapas, quién los mantiene, quién los consume.
• Subestimar la traducción de estilos. Pasar de un proyecto QGIS cuidado a estilos SLD equivalentes puede llevar días por mapa. Ese coste debe entrar en la comparación.
• Olvidar a los clientes. Un socio que espera WFS 2.0, un portal de datos que recolecta GetCapabilities, una aplicación móvil que lee teselas vectoriales: parta de lo que saben leer.
• Creer que un solo servidor debe hacerlo todo. Un portal QGIS Server con Lizmap para los usuarios y un GeoServer para los servicios de referencia, sobre la misma base PostGIS, es una arquitectura habitual y sana.
• Descuidar el mantenimiento. El mejor servidor se convierte en un riesgo si nunca se actualiza. Elija el que su equipo sabrá mantener de verdad, o delegue esa parte del trabajo.
• Probar con datos de juguete. Una prueba con diez entidades no dice nada. Use sus capas reales, con sus volúmenes reales y sus estilos.

Un método sencillo funciona bien: quedarse con dos candidatos, publicar las mismas tres capas representativas en cada uno, mostrarlas en los clientes de sus usuarios, medir y estimar el tiempo de mantenimiento anual. En una o dos semanas la respuesta suele ser clara, y se basa en sus datos y no en reputaciones.

Elegir según su necesidad

Sea cual sea el servidor, habrá que mantenerlo: Java o bibliotecas del sistema, certificados, actualizaciones de seguridad. La guía proteger y actualizar GeoServer muestra lo que implica en la práctica. Si mantiene QGIS Server y GeoServer en paralelo, use una regla de nombres común para las capas y documente qué capa se publica dónde: los usuarios sabrán qué dirección usar, y evitará mantener dos versiones divergentes del mismo dato.

Preguntas frecuentes