GeoServer, PostGIS, WMS y WFS: publicar sus tablas paso a paso

El principio: una tabla, una capa, dos servicios

PostGIS guarda las geometrías en tablas PostgreSQL. GeoServer se conecta a ellas mediante un almacén (store) y expone cada tabla elegida como una capa. Esa capa se sirve a la vez en WMS, que devuelve una imagen dibujada con un estilo, y en WFS, que devuelve las propias entidades con sus atributos.

La ventaja de PostGIS como fuente: la capa refleja la base en directo. Una fila añadida o corregida en la tabla aparece en el servicio en la siguiente petición, sin volver a publicar. Por eso la combinación GeoServer, PostGIS, WMS y WFS está tan extendida en las infraestructuras de datos espaciales.

¿Cuándo elegir uno u otro? El WMS conviene para visualizar: el cliente recibe una imagen ligera, sea cual sea el número de entidades, y el estilo es el mismo para todos. El WFS conviene para analizar y reutilizar: el cliente recibe geometrías y atributos, puede filtrar, calcular, exportar e incluso modificar si la edición está abierta. En la práctica, se suele publicar la misma capa en los dos servicios, y cada usuario elige según su uso.

Preparar la tabla PostGIS

Algunas precauciones en la base evitan la mayoría de los errores de publicación: Tras una importación masiva, ejecute también VACUUM ANALYZE sobre la tabla: PostgreSQL actualiza sus estadísticas y elige entonces el plan de consulta adecuado, índice espacial incluido.

• Una clave primaria. Sin ella, GeoServer no puede identificar las entidades de forma estable y la edición por WFS-T se vuelve imposible.
• Una columna geométrica tipada, con un sistema de coordenadas (SRID) declarado, por ejemplo geometry(MultiPolygon, 4326) o la proyección nacional.
• Un índice espacial sobre la geometría, imprescindible a partir de unos miles de entidades.
• Nombres sencillos: minúsculas, sin espacios ni tildes, para la tabla y las columnas.
• Un usuario de lectura dedicado si es posible, en lugar del propietario de la base.

CREATE INDEX parcelles_geom_idx ON parcelles USING GIST (geom);
SELECT Find_SRID('public', 'parcelles', 'geom');

Crear el almacén PostGIS en GeoServer

En la consola de GeoServer, un almacén PostGIS pertenece a un espacio de trabajo. El procedimiento habitual:

1. Crear o elegir el espacio de trabajo que agrupará las capas.
2. Añadir un nuevo almacén de tipo PostGIS.
3. Indicar el host, el puerto, la base, el esquema, el usuario y la contraseña.
4. Guardar: GeoServer prueba la conexión y lista las tablas disponibles.

En GeoServer Cloud, la base PostGIS de una instancia LizPack Map se vincula a su espacio con un clic, sin formulario de conexión. Las bases PostgreSQL y PostGIS dedicadas funcionan con PostgreSQL 17 y PostGIS 3.5, con conexión cifrada.

El formulario del almacén ofrece también ajustes de conexión que se suelen olvidar: el número máximo de conexiones abiertas hacia la base, la validación de las conexiones antes de usarlas (útil cuando la base se reinicia de noche) y la exposición de las claves primarias, necesaria si quiere filtrar o editar por identificador. Si publica varios esquemas, cree un almacén por esquema: los permisos y los nombres de capas siguen siendo legibles.

Publicar la capa y darle un estilo SLD

Desde la lista de tablas del almacén, publique la que le interesa. En la página de la capa: Aproveche esta página para completar el título, el resumen y las palabras clave de la capa: aparecen en el GetCapabilities y es lo que leen sus socios en su programa, antes incluso de mostrar el mapa. Un nombre técnico como parcelles_v2 no dice nada; un título claro y un resumen fechado evitan muchas preguntas.

1. Comprobar el sistema de coordenadas declarado y el nativo.
2. Calcular las extensiones a partir de los datos (nativa y luego en latitud y longitud).
3. En la pestaña de publicación, elegir el estilo por defecto.
4. Guardar y revisar la vista previa de la capa.

El estilo es un archivo SLD (Styled Layer Descriptor). Puede escribirlo a mano, partir de una plantilla de la consola o exportarlo desde QGIS (propiedades de la capa, simbología, guardar estilo como SLD). Un estilo mínimo para polígonos:

<PolygonSymbolizer>
  <Fill><CssParameter name="fill">#2F7A3E</CssParameter></Fill>
  <Stroke><CssParameter name="stroke">#083D44</CssParameter></Stroke>
</PolygonSymbolizer>

Sistemas de coordenadas: las trampas más frecuentes

GeoServer distingue el sistema nativo, en el que se guarda la tabla, del sistema declarado, el que anuncia a los clientes. En la mayoría de los casos son el mismo y corresponden al SRID de la columna geométrica. Cuando PostGIS no conoce el SRID (columna declarada como geometry sin más, o SRID a 0), GeoServer no puede adivinar la proyección: la capa aparece en el lugar equivocado o no aparece. La corrección adecuada se hace en la base, declarando el SRID correcto, en lugar de forzar una proyección en GeoServer.

• Reproyección al vuelo. Un cliente puede pedir la capa en otro sistema distinto del de almacenamiento, por ejemplo EPSG:3857 para un mapa web. GeoServer reproyecta cada petición: es práctico, pero cuesta cálculo en las capas grandes. Si todos sus mapas web trabajan en EPSG:3857, una tabla o vista ya proyectada acelera la representación.
• Orden de los ejes en WFS. Con EPSG:4326, las versiones 1.1.0 y 2.0.0 del WFS devuelven las coordenadas en orden latitud y luego longitud, mientras que la versión 1.0.0 y la mayoría de las herramientas web esperan longitud y luego latitud. Puntos que aparecen invertidos, en medio del océano, casi siempre vienen de ahí. Pida la versión del servicio adecuada para su cliente, o un sistema proyectado.
• Lista de sistemas anunciados. Por defecto, el documento GetCapabilities del WMS puede anunciar miles de sistemas de coordenadas, lo que lo hace pesado y ralentiza algunos clientes. Los parámetros del servicio WMS permiten limitar esa lista a los pocos sistemas que sus usuarios utilizan de verdad.
• Extensiones recalculadas. Tras una reproyección o una carga masiva de datos fuera de la zona anterior, vuelva a calcular las extensiones de la capa: si no, los clientes se acercan a una zona demasiado pequeña o ignoran parte de las entidades.

Una regla sencilla evita la mayoría de estos problemas: guarde sus datos en la proyección oficial de su país o territorio, declárela correctamente en PostGIS y deje que GeoServer reproyecte para los usos web. Conserva medidas de distancia y superficie correctas en la base, y mapas web compatibles con los mapas base habituales.

Las direcciones de los servicios WMS y WFS

GeoServer expone cada servicio en su propia dirección, normalmente limitada a un espacio de trabajo. El documento GetCapabilities describe las capas disponibles; es el que leen los clientes.

En GeoServer Cloud, cada servicio tiene su propia dirección en su espacio. Para WFS, conviene limitar el número de entidades devueltas por petición si la tabla es grande.

Consultar los servicios: filtros y formatos

Una vez publicada la capa, los clientes no se limitan a mostrarla: la consultan. Conocer la forma de las peticiones ayuda a documentar sus servicios para desarrolladores y a diagnosticar lo que un programa pide realmente. Esta es una petición WFS 2.0 que devuelve como máximo cincuenta parcelas de un municipio, en GeoJSON:

https://ejemplo.org/geoserver/miespacio/wfs?service=WFS&version=2.0.0
  &request=GetFeature&typeNames=miespacio:parcelles
  &count=50&outputFormat=application/json
  &CQL_FILTER=commune='Dakar'

• typeNames designa la capa, con el prefijo de su espacio de trabajo; en WFS 1.x el parámetro se llama typeName.
• count limita el número de entidades en WFS 2.0; el equivalente en WFS 1.x es maxFeatures. Junto con startIndex, permite paginar una tabla grande.
• outputFormat elige el formato de salida: GML por defecto, application/json para GeoJSON, más fácil de usar en JavaScript.
• CQL_FILTER es un parámetro propio de GeoServer que acepta filtros legibles, de atributos o espaciales. Los filtros OGC en XML siguen siendo la vía estándar, reconocida por todos los servidores.
• bbox restringe la respuesta a una extensión, lo que QGIS y las bibliotecas web hacen automáticamente al desplazarse por el mapa.
• propertyName limita los atributos devueltos, útil cuando la tabla tiene decenas de columnas.

En el lado WMS, la petición GetFeatureInfo devuelve los atributos de la entidad pulsada en el mapa: es la que usan Lizmap, QGIS u OpenLayers para mostrar una ficha de información. Su contenido depende de los atributos publicados: si un campo no debe verse, retírelo de la vista publicada en lugar de confiar en que el cliente lo oculte.

Rendimiento y buenas prácticas WMS y WFS

Una capa que funciona con cien entidades puede hundirse con un millón. La mayoría de las lentitudes vienen de la base o de la consulta, no del propio GeoServer. Unos pocos ajustes marcan la diferencia, y se hacen una sola vez, en el momento de publicar.

• Publicar una vista en lugar de una tabla en bruto. Una vista PostgreSQL, o una vista SQL declarada en GeoServer, solo devuelve las columnas y filas útiles: menos datos transferidos y menos riesgo de exponer un campo interno.
• Limitar las entidades devueltas por el WFS. Fije un tope en la configuración del servicio y pida a los clientes que filtren por extensión o por atributo en lugar de descargarlo todo.
• Simplificar para escalas pequeñas. A escala de país no hace falta enviar contornos al metro: una tabla simplificada, o reglas de escala en el estilo SLD, aligeran la representación.
• Almacenar en caché lo que cambia poco. Los mapas base y las capas de referencia ganan al servirse en WMTS desde la caché de teselas integrada. Recuerde vaciar la caché cuando cambien los datos.
• Indexar las columnas filtradas. Si los usuarios filtran por municipio o por fecha, un índice en esas columnas cuenta tanto como el índice espacial.
• Acotar la edición WFS-T. La escritura en línea es potente, pero requiere una cuenta de base autorizada a escribir, permisos por capa en GeoServer y una clave primaria fiable.

Mantenga por último una regla sencilla de seguridad: el usuario PostgreSQL del almacén solo debe tener los derechos que la capa necesita. Un almacén de solo lectura no puede modificar nada, aunque un servicio esté mal configurado. Para las demás precauciones, vea la guía proteger y actualizar GeoServer.

Probar en QGIS

1. En QGIS, abrir el administrador de fuentes de datos.
2. Pestaña WMS/WMTS: crear una conexión con la dirección WMS, conectar y añadir la capa. Debe verse el estilo SLD.
3. Pestaña WFS: crear una conexión con la dirección WFS, añadir la capa y abrir su tabla de atributos para revisar los campos.
4. Modificar una fila en PostGIS y actualizar el mapa: el cambio aparece.

Si la capa está vacía, revise las extensiones y el SRID; si es lenta, el índice espacial. Para alojarlo todo sin servidor, vea el alojamiento GeoServer en línea. Para elegir entre GeoServer y QGIS Server, lea nuestra comparativa.

Errores frecuentes y soluciones

Los mismos problemas se repiten de un proyecto a otro. La tabla siguiente parte del síntoma observado, en QGIS o en un navegador, para llegar a la causa más probable.

Cuando el síntoma no figura en esta tabla, mire primero la respuesta en bruto del servidor: abra la dirección de la petición en un navegador. GeoServer devuelve un mensaje de excepción explícito (capa desconocida, atributo inexistente, error SQL) que los clientes cartográficos suelen ocultar tras un mapa vacío. Los registros de GeoServer y de PostgreSQL completan el diagnóstico, en especial para los errores SQL de una vista mal escrita.

Preguntas frecuentes