GeoServer, PostGIS, WMS et WFS : publier vos tables pas à pas

Le principe : une table, une couche, deux services

PostGIS stocke les géométries dans des tables PostgreSQL. GeoServer s'y connecte par un entrepôt (store), puis expose chaque table choisie comme une couche. Cette couche est servie à la fois en WMS, qui renvoie une image dessinée avec un style, et en WFS, qui renvoie les entités elles-mêmes avec leurs attributs.

L'avantage de PostGIS comme source : la couche reflète la base en direct. Une ligne ajoutée ou corrigée dans la table apparaît dans le service à la requête suivante, sans republier. C'est pourquoi la combinaison GeoServer, PostGIS, WMS et WFS est si répandue dans les infrastructures de données.

Quand choisir l'un ou l'autre ? Le WMS convient à l'affichage : le client reçoit une image légère, quel que soit le nombre d'entités, et le style est le même pour tous. Le WFS convient à l'analyse et à la réutilisation : le client reçoit les géométries et les attributs, peut filtrer, calculer, exporter, voire modifier si l'édition est ouverte. Dans la pratique, on publie souvent la même couche dans les deux services, et chacun choisit selon son usage.

Préparer la table PostGIS

Quelques précautions dans la base évitent la plupart des erreurs de publication : Après un import massif, lancez aussi VACUUM ANALYZE sur la table : PostgreSQL met à jour ses statistiques et choisit alors le bon plan de requête, index spatial compris.

• Une clé primaire. Sans elle, GeoServer ne peut pas identifier les entités de façon stable, et l'édition par WFS-T devient impossible.
• Une colonne géométrique typée, avec un système de coordonnées (SRID) déclaré, par exemple geometry(MultiPolygon, 4326) ou dans la projection nationale.
• Un index spatial sur la géométrie, indispensable dès quelques milliers d'entités.
• Des noms simples : minuscules, sans espaces ni accents, pour la table et les colonnes.
• Un utilisateur de lecture dédié si possible, plutôt que le propriétaire de la base.

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

Créer l'entrepôt PostGIS dans GeoServer

Dans la console GeoServer, un entrepôt PostGIS se rattache à un espace de travail. La procédure classique :

1. Créer ou choisir l'espace de travail qui regroupera les couches.
2. Ajouter un nouvel entrepôt de type PostGIS.
3. Renseigner l'hôte, le port, la base, le schéma, l'utilisateur et le mot de passe.
4. Enregistrer : GeoServer teste la connexion et liste les tables disponibles.

Sur GeoServer Cloud, la base PostGIS d'une instance LizPack Map se relie à votre espace en un clic, sans formulaire de connexion. Les bases PostgreSQL et PostGIS dédiées fonctionnent en PostgreSQL 17 et PostGIS 3.5, en connexion chiffrée.

Le formulaire d'entrepôt propose aussi des réglages de connexion qu'on oublie souvent : le nombre maximal de connexions ouvertes vers la base, la validation des connexions avant usage (utile quand la base redémarre la nuit) et l'exposition des clés primaires, nécessaire si vous voulez filtrer ou éditer sur l'identifiant. Si vous publiez plusieurs schémas, créez un entrepôt par schéma : les droits et les noms de couches restent lisibles.

Publier la couche et lui donner un style SLD

Depuis la liste des tables de l'entrepôt, publiez celle qui vous intéresse. Sur la page de la couche : Profitez de cette page pour renseigner le titre, le résumé et les mots-clés de la couche : ils apparaissent dans le GetCapabilities et c'est ce que lisent vos partenaires dans leur logiciel, avant même d'afficher la carte. Un nom technique comme parcelles_v2 ne dit rien ; un titre clair et un résumé daté évitent bien des questions.

1. Vérifier le système de coordonnées déclaré et natif.
2. Calculer les emprises à partir des données (emprise native, puis emprise en latitude et longitude).
3. Dans l'onglet de publication, choisir le style par défaut.
4. Enregistrer, puis contrôler l'aperçu de la couche.

Le style est un fichier SLD (Styled Layer Descriptor). Vous pouvez l'écrire à la main, partir d'un modèle de la console, ou l'exporter depuis QGIS (propriétés de la couche, symbologie, enregistrer le style au format SLD). Un style minimal pour des polygones :

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

Systèmes de coordonnées : ce qui piège le plus souvent

GeoServer distingue le système natif, celui dans lequel la table est stockée, et le système déclaré, celui qu'il annonce aux clients. Dans la grande majorité des cas, les deux sont identiques et correspondent au SRID de la colonne géométrique. Quand PostGIS ne connaît pas le SRID (colonne déclarée en geometry sans précision, ou SRID à 0), GeoServer ne peut pas deviner la projection : la couche s'affiche au mauvais endroit, ou pas du tout. La bonne correction se fait dans la base, en déclarant le bon SRID, plutôt qu'en forçant une projection dans GeoServer.

• Reprojection à la volée. Un client peut demander la couche dans un autre système que celui de stockage, par exemple en EPSG:3857 pour une carte web. GeoServer reprojette chaque requête : c'est pratique, mais cela coûte du calcul sur les grosses couches. Si toutes vos cartes web travaillent en EPSG:3857, une table ou une vue déjà projetée accélère le rendu.
• Ordre des axes en WFS. Avec EPSG:4326, les versions 1.1.0 et 2.0.0 du WFS renvoient les coordonnées dans l'ordre latitude puis longitude, alors que la version 1.0.0 et la plupart des outils web attendent longitude puis latitude. Des points qui apparaissent au milieu de l'océan, inversés, viennent presque toujours de là. Demandez la version du service adaptée à votre client, ou une projection métrique.
• Liste des systèmes annoncés. Par défaut, le document GetCapabilities du WMS peut annoncer des milliers de systèmes de coordonnées, ce qui l'alourdit et ralentit certains clients. Les paramètres du service WMS permettent de limiter cette liste aux quelques systèmes que vos utilisateurs emploient réellement.
• Emprises recalculées. Après une reprojection ou un ajout massif de données hors de l'ancienne zone, recalculez les emprises de la couche : sinon les clients zooment sur une zone trop petite ou ignorent une partie des entités.

Une règle simple évite la plupart de ces soucis : stockez vos données dans la projection officielle de votre pays ou de votre territoire, déclarez-la proprement dans PostGIS, et laissez GeoServer reprojeter pour les usages web. Vous gardez des mesures de distance et de surface justes dans la base, et des cartes web compatibles avec les fonds habituels.

Les adresses des services WMS et WFS

GeoServer expose chaque service à une adresse propre, généralement limitée à un espace de travail. Le document GetCapabilities décrit les couches disponibles ; c'est lui que lisent les clients.

Sur GeoServer Cloud, chaque service a son adresse propre à votre espace. Pour WFS, pensez à limiter le nombre d'entités renvoyées par requête si la table est grosse.

Interroger les services : filtres et formats

Une fois la couche publiée, les clients ne se contentent pas de l'afficher : ils l'interrogent. Connaître la forme des requêtes aide à documenter vos services pour des développeurs et à diagnostiquer ce qu'un logiciel demande réellement. Voici une requête WFS 2.0 qui renvoie au plus cinquante parcelles d'une commune, en GeoJSON :

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

• typeNames désigne la couche, préfixée par son espace de travail ; en WFS 1.x, le paramètre s'appelle typeName.
• count limite le nombre d'entités en WFS 2.0 ; l'équivalent en WFS 1.x est maxFeatures. Associé à startIndex, il permet de paginer une grosse table.
• outputFormat choisit le format de sortie : GML par défaut, application/json pour du GeoJSON, plus simple à exploiter en JavaScript.
• CQL_FILTER est un paramètre propre à GeoServer qui accepte des filtres lisibles, attributaires ou spatiaux. Les filtres OGC en XML restent la voie standard, reconnue par tous les serveurs.
• bbox restreint la réponse à une emprise, ce que font automatiquement QGIS et les bibliothèques web quand on se déplace sur la carte.
• propertyName limite les attributs renvoyés, utile quand la table compte des dizaines de colonnes.

Côté WMS, la requête GetFeatureInfo renvoie les attributs de l'entité cliquée sur la carte : c'est elle qu'utilisent Lizmap, QGIS ou OpenLayers pour afficher une fiche d'information. Son contenu dépend des attributs publiés : si un champ ne doit pas être vu, retirez-le de la vue publiée plutôt que de compter sur le client pour le masquer.

Performances et bonnes pratiques WMS et WFS

Une couche qui fonctionne avec cent entités peut s'effondrer avec un million. La plupart des lenteurs viennent de la base ou de la requête, pas de GeoServer lui-même. Quelques réglages font l'essentiel de la différence, et ils se font une fois pour toutes au moment de la publication.

• Publier une vue plutôt qu'une table brute. Une vue PostgreSQL, ou une vue SQL déclarée dans GeoServer, ne renvoie que les colonnes et les lignes utiles : moins de données transférées, moins de risques d'exposer un champ interne.
• Limiter les entités renvoyées par le WFS. Fixez un plafond dans la configuration du service, et demandez aux clients de filtrer par emprise ou par attribut plutôt que de tout télécharger.
• Simplifier pour les petites échelles. À l'échelle d'un pays, inutile d'envoyer des contours au mètre près : une table simplifiée, ou des règles d'échelle dans le style SLD, allègent le rendu.
• Mettre en cache ce qui change peu. Les fonds et les couches de référence gagnent à être servis en WMTS depuis le cache de tuiles intégré. Pensez à vider le cache quand les données changent.
• Indexer les colonnes filtrées. Si les utilisateurs filtrent par commune ou par date, un index sur ces colonnes compte autant que l'index spatial.
• Encadrer l'édition WFS-T. L'écriture en ligne est puissante, mais elle demande un compte de base autorisé à écrire, des droits limités par couche dans GeoServer et une clé primaire fiable.

Gardez enfin une règle simple de sécurité : l'utilisateur PostgreSQL de l'entrepôt ne doit avoir que les droits dont la couche a besoin. Un entrepôt en lecture seule ne peut rien modifier, même si un service est mal configuré. Pour les autres précautions, voyez le guide sécuriser et mettre à jour GeoServer.

Tester dans QGIS

1. Dans QGIS, ouvrir le gestionnaire des sources de données.
2. Onglet WMS/WMTS : créer une connexion avec l'adresse WMS, se connecter, ajouter la couche. Le style SLD doit s'afficher.
3. Onglet WFS : créer une connexion avec l'adresse WFS, ajouter la couche, puis ouvrir sa table attributaire pour vérifier les champs.
4. Modifier une ligne dans PostGIS, actualiser la carte : la modification apparaît.

Si la couche est vide, vérifiez les emprises et le SRID ; si elle est lente, l'index spatial. Pour héberger le tout sans serveur, voyez l'hébergement GeoServer en ligne. Pour choisir entre GeoServer et QGIS Server, lisez notre comparatif.

Erreurs fréquentes et solutions

Les mêmes problèmes reviennent d'un projet à l'autre. Le tableau ci-dessous part du symptôme observé, dans QGIS ou dans un navigateur, pour remonter à la cause la plus probable.

Quand le symptôme ne figure pas dans ce tableau, regardez d'abord la réponse brute du serveur : ouvrez l'adresse de la requête dans un navigateur. GeoServer renvoie un message d'exception explicite (couche inconnue, attribut introuvable, erreur SQL) que les clients cartographiques masquent souvent derrière une carte vide. Les journaux de GeoServer et de PostgreSQL complètent le diagnostic, notamment pour les erreurs de requête SQL produites par une vue mal écrite.

Questions fréquentes