Alojamiento GeoServer: sus capas en línea sin servidor

Por qué publicar con GeoServer

GeoServer es un servidor de mapas libre, escrito en Java, que publica datos geográficos según los estándares del OGC: WMS para imágenes de mapa, WFS para entidades vectoriales, WCS para ráster y WMTS para teselas. Lee archivos (Shapefile, GeoPackage, GeoTIFF) y bases de datos, entre ellas PostGIS, y aplica estilos SLD.

Su interés está en los estándares: una capa publicada por GeoServer se muestra en QGIS, Lizmap, ArcGIS, Leaflet u OpenLayers sin conversión. Por eso es una opción habitual para compartir datos con socios, alimentar una aplicación web o cumplir una obligación de difusión. Si aún duda entre varios servidores, lea nuestra comparativa GeoServer, MapServer o QGIS Server.

Los casos de uso más habituales

Antes de hablar de alojamiento GeoServer, conviene precisar para qué servirá el servidor. Las necesidades reales determinan su tamaño, los servicios que hay que abrir y el nivel de seguridad. Estas son las situaciones más frecuentes en consultoras, administraciones locales y proyectos de cooperación.

• Difundir datos de referencia a socios. Límites administrativos, red vial, zonificación: una capa WMS o WFS estable evita enviar archivos por correo en cada actualización, y todos ven la misma versión.
• Alimentar una aplicación web. Una aplicación Leaflet u OpenLayers desarrollada internamente lee las capas en WMS para visualizar y en WFS para las fichas de información, sin almacenar ella misma los datos.
• Cumplir una obligación de difusión. Muchos programas de datos abiertos e infraestructuras nacionales exigen servicios conformes a los estándares OGC; GeoServer los ofrece sin desarrollo.
• Compartir ráster voluminosos. Ortofotos, modelos digitales de elevación o mapas escaneados se consultan en WMS o WMTS sin que el usuario descargue gigabytes.
• Completar un portal Lizmap. Un servicio de GeoServer se añade a un proyecto QGIS y se muestra en el mapa publicado con LizPack Map como una capa más.

Si su necesidad se limita a publicar un mapa construido en QGIS, con sus estilos y composiciones, un portal Lizmap servido por QGIS Server suele ser más directo. GeoServer cobra todo su sentido cuando las capas deben vivir con independencia de un proyecto y ser consumidas por herramientas variadas. Ambos se combinan además muy bien: un portal para el público general, servicios GeoServer para los socios técnicos, alimentados por la misma base PostGIS, sin copias de datos ni doble actualización.

Lo que exige un GeoServer propio

Instalar GeoServer está documentado y al alcance de un técnico. Mantenerlo en producción exige más, y de forma continua:

• Un entorno Java compatible con la versión de GeoServer elegida, y un contenedor de servlets si no usa el paquete autónomo.
• Memoria. GeoServer necesita varios gigabytes cuando crecen las capas y los usuarios; ajustar la memoria de Java y la caché de teselas forma parte del trabajo.
• Un nombre de dominio y un certificado HTTPS, renovado a tiempo, con un proxy inverso delante de la aplicación.
• La seguridad: cambiar la contraseña de administrador por defecto, no exponer la consola de administración a todo Internet, ajustar los permisos por espacio de trabajo.
• Las actualizaciones. GeoServer publica con regularidad versiones correctivas, algunas de las cuales cierran fallos graves. Nuestra guía proteger y actualizar GeoServer explica por qué es decisivo.
• La supervisión y las copias de seguridad del directorio de datos, los estilos y la base.

Instalar GeoServer uno mismo: los grandes pasos

Para medir el esfuerzo real, este es el recorrido típico de una instalación en producción en un servidor Linux. Cada paso está documentado en geoserver.org; lo que lleva tiempo es encadenarlos y mantenerlos.

1. Alquilar o preparar una máquina con memoria suficiente para GeoServer y para el sistema, y un disco separado o respaldado para los datos.
2. Instalar la versión de Java indicada en la documentación de la versión de GeoServer elegida y comprobar que ninguna otra versión se impone.
3. Desplegar GeoServer, ya sea con el paquete autónomo que incluye su propio servidor web, ya sea como archivo WAR en un contenedor de servlets.
4. Situar el directorio de datos fuera de la carpeta de instalación, indicándolo con la variable GEOSERVER_DATA_DIR, para que una actualización no lo borre.
5. Ajustar la memoria asignada a Java según la máquina, reiniciar y revisar la página de estado de la consola.
6. Poner un proxy inverso delante de GeoServer, con un nombre de dominio y un certificado HTTPS renovado automáticamente, e indicar a GeoServer su dirección pública para que los GetCapabilities devuelvan las direcciones correctas.
7. Sustituir las credenciales por defecto (admin y geoserver), crear cuentas nominativas y cerrar el acceso público a la consola.
8. Programar copias de seguridad del directorio de datos y de la base, y una supervisión que avise cuando el servicio deje de responder.

Cuente de uno a varios días para una primera instalación limpia, y luego algunas horas al mes para actualizaciones, supervisión e incidencias. Ese tiempo es el verdadero coste del alojamiento propio, mucho más que el precio de la máquina.

Alojamiento GeoServer: propio o gestionado

El alojamiento propio sigue siendo la mejor opción si necesita extensiones concretas de GeoServer, acceso completo al servidor o volúmenes muy grandes. LizPack no sustituye a GeoServer: lo aloja y lo mantiene. Para conservar el control de la máquina, la edición LizPack Entreprise instala GeoServer en su infraestructura.

Publicar su primera capa

Con GeoServer Cloud, la puesta en línea sigue cuatro pasos, sin línea de comandos:

1. Desde el panel de LizPack, abra GeoServer Cloud: su espacio aislado se crea al instante.
2. Suba un Shapefile comprimido en ZIP, un GeoPackage o un GeoTIFF. Si sus datos están en una base PostgreSQL y PostGIS de LizPack, vincúlela a su espacio con un clic.
3. Publique la capa en WMS, WFS o WMTS y elija su estilo en la consola de GeoServer.
4. Copie la dirección del servicio para usarla en sus herramientas.

Si sus datos están en PostGIS, la guía publicar PostGIS en WMS y WFS con GeoServer describe paso a paso el almacén, la capa, el estilo SLD y la prueba en QGIS. Antes de publicar, dé a sus capas nombres sencillos (minúsculas, sin espacios ni tildes): ese nombre aparecerá en las direcciones de los servicios y en los programas de sus usuarios, y cambiarlo después obliga a todos a reconfigurar sus conexiones. Compruebe también que la proyección de sus datos está declarada: un archivo sin proyección conocida se publica mal o aparece en el lugar equivocado.

Consumir el servicio en QGIS, Lizmap o la web

Una vez publicada, la capa tiene una dirección de servicio por estándar. En QGIS, abra el administrador de fuentes de datos, pestaña WMS/WMTS o WFS, cree una conexión con esa dirección y añada la capa.

• QGIS: WMS para visualizar, WFS para consultar o exportar las entidades.
• Lizmap: añada el servicio a su proyecto QGIS y publique el proyecto; la capa aparece como las demás.
• Leaflet, OpenLayers, ArcGIS: cualquier cliente que lea los estándares OGC muestra sus capas.
• Teselas WMTS: la caché de teselas integrada acelera las capas más consultadas.

Prefiera WMTS o WMS para un mapa público, y WFS cuando el usuario necesite los atributos o la geometría.

Para compartir una capa con un socio, envíele la dirección GetCapabilities del servicio en lugar de una captura o una exportación: verá siempre la última versión de los datos, y su programa sabrá listar por sí solo las capas disponibles, sus proyecciones y sus estilos.

Errores frecuentes y cómo corregirlos

Tanto si GeoServer está en sus instalaciones como si está alojado, las mismas dificultades aparecen al publicar o consumir una capa. La mayoría se resuelve en minutos una vez identificada la causa.

Un reflejo útil: pruebe siempre la capa en la vista previa de la consola de GeoServer antes de culpar al cliente. Si la vista previa funciona, el problema está en la dirección, la proyección o los permisos del lado del cliente; si no, está en la propia publicación.

Dimensionar GeoServer y pensar a largo plazo

Antes de elegir, estime lo que realmente va a publicar. Tres factores pesan más que el número de usuarios: el tipo de datos, el número de capas y la forma en que se consultan. Una capa vectorial de unos miles de entidades servida en WMS cuesta poco. Un mosaico de ortofotos de varios gigabytes, consultado a todas las escalas, exige memoria, disco rápido y una caché de teselas bien ajustada. Un WFS abierto sobre una tabla grande puede saturar el servidor por sí solo si un cliente pide todas las entidades de golpe.

• Ráster pesados: prefiera GeoTIFF en teselas y con vistas generales (pirámides), que se leen mucho más rápido que una imagen sin optimizar.
• Capas muy consultadas: sírvalas en WMTS desde la caché de teselas, en lugar de en WMS recalculado en cada petición.
• Tablas grandes: guárdelas en PostGIS, con un índice espacial, en lugar de en archivos Shapefile.
• Crecimiento: vigile el volumen de datos y el número de capas publicadas; es lo que hace pasar de una oferta gratuita a un presupuesto, o de un servidor pequeño a uno mayor.
• Tiempo de respuesta: un mapa que tarda varios segundos en mostrarse casi siempre indica un estilo demasiado costoso, un índice ausente o falta de caché, rara vez falta de potencia.

Piense también en la salida desde el principio. GeoServer se apoya en elementos estándar: archivos de datos o una base PostgreSQL, estilos SLD, servicios con direcciones OGC. Si cambia de alojamiento, exporta sus datos y estilos, vuelve a crear las capas y comunica las nuevas direcciones a sus usuarios. Conserve por tanto una copia de sus estilos SLD y una lista de sus capas publicadas, sea cual sea el proveedor. Con GeoServer Cloud, los datos que sube siguen siendo suyos, y una base PostgreSQL y PostGIS se recupera con las herramientas habituales de PostgreSQL.

Qué opción elegir

Si publica unas decenas de capas sin extensiones particulares, un alojamiento gestionado le ahorra el servidor, Java, el certificado y la vigilancia de seguridad. Conserva un GeoServer estándar: sus estilos SLD y sus direcciones de servicio siguen siendo válidos en otro lugar. Hágase tres preguntas sencillas: cuántas capas y gigabytes publicará dentro de un año, quién en el equipo sabría actualizar el servidor con urgencia y qué extensiones le resultan imprescindibles. Si las respuestas son pocas, nadie y ninguna, el alojamiento gestionado es la opción razonable.

Si GeoServer es el centro de una infraestructura de datos pesada, con un equipo de sistemas, el alojamiento propio se justifica. Para comparar el coste total, vea nuestra guía sobre el coste de un SIG web de código abierto, y para la visión de conjunto, lo que hace LizPack.

Preguntas frecuentes