GeoServer : publier des couches WMS et WFS depuis PostGIS

Introduction

Vos données vivent dans PostGIS, propres et indexées. Mais une carte affichée dans un navigateur ne peut pas — et ne doit surtout pas — se connecter directement à votre base de données : ce serait exposer vos identifiants et votre serveur au premier venu. Il manque un intermédiaire qui lit la base côté serveur et n’expose à l’extérieur que des services cartographiques normalisés. C’est précisément le rôle de GeoServer : il se branche sur PostGIS et publie vos couches sous forme de WMS (des images de carte), de WFS (des entités vectorielles brutes) et de tuiles, selon des standards ouverts compris par tous les outils du domaine.

À la fin de ce tutoriel, GeoServer tournera, connecté à votre base PostGIS, et publiera vos couches. Vous obtiendrez une carte en demandant une simple URL, et les données vectorielles en GeoJSON par une autre URL. Ce sont ces points d’accès que consommera la carte web construite dans le dernier tutoriel de la série.

🎯 Ce que vous allez apprendre

• Installer et démarrer GeoServer à partir du binaire indépendant de la plateforme.
• Sécuriser l’accès en changeant le mot de passe administrateur par défaut.
• Connecter GeoServer à une base PostGIS via un entrepôt de données (store).
• Publier une couche en réglant correctement son système de coordonnées et son emprise.
• Interroger vos couches en WMS (image) et en WFS (GeoJSON), et activer un cache de tuiles.

🛠️ Ce que vous allez construire

Un serveur cartographique exposant vos communes et vos écoles : une URL WMS qui renvoie une image PNG de la carte, une URL WFS qui renvoie les entités en GeoJSON, et un aperçu interactif intégré. Le tout adossé à PostGIS, sans jamais exposer la base directement.

Prérequis

• Un environnement Java : JDK 17 ou 21 (les versions supportées par GeoServer 2.28).
• GeoServer 2.28.4, version stable recommandée pour la production au moment d’écrire, téléchargeable sur geoserver.org/download (archive « Platform Independent Binary »).
• Une base PostGIS active contenant au moins une couche — par exemple les couches communes et écoles produites dans les tutoriels précédents de la série.
• Test express : si vous savez lancer un script shell et naviguer dans une interface d’administration web, vous êtes prêt.
• ⏱️ Temps estimé : ~55 minutes.

Étape 1 — Installer et démarrer GeoServer

GeoServer est une application Java livrée avec son propre serveur web embarqué (Jetty). Le binaire indépendant de la plateforme évite toute installation de serveur d’applications externe : on décompresse, on vérifie que Java est présent, on lance un script. C’est la voie la plus simple pour apprendre et pour un déploiement modeste.

# Vérifier la version de Java (doit afficher 17 ou 21)
java -version

# Décompresser l'archive téléchargée puis démarrer
cd geoserver/bin
sh startup.sh        # startup.bat sous Windows

Le script démarre Jetty et charge GeoServer. Au bout de quelques dizaines de secondes, le journal affiche une ligne indiquant que le serveur écoute. Si java -version renvoie une version inférieure à 17, installez un JDK récent (OpenJDK convient) avant de relancer : GeoServer 2.28 ne démarre pas sous une JVM trop ancienne.

✅ Point d’étape — Le journal de démarrage se termine sans erreur. GeoServer écoute sur le port 8080.

Étape 2 — Se connecter et sécuriser l’accès

L’interface d’administration est une application web. On y accède au navigateur, et la toute première action — avant même de publier quoi que ce soit — doit être de changer le mot de passe par défaut, connu de la terre entière.

Ouvrez http://localhost:8080/geoserver. La page d’accueil de GeoServer s’affiche. Connectez-vous avec les identifiants par défaut : utilisateur admin, mot de passe geoserver. Rendez-vous aussitôt dans Paramètres → Utilisateurs, groupes, rôles, éditez l’utilisateur admin et définissez un mot de passe fort. Sur un serveur exposé à Internet, laisser le mot de passe par défaut revient à publier les clés de votre serveur.

✅ Point d’étape — Vous êtes connecté à l’interface d’administration et le mot de passe admin a été changé.

Étape 3 — Créer un espace de travail

Un espace de travail (workspace) regroupe logiquement vos couches sous un préfixe et un espace de noms (namespace). Toutes vos couches y seront rangées et adressées sous la forme monespace:macouche. C’est l’équivalent d’un schéma : une bonne hygiène d’organisation dès le départ.

Dans le menu de gauche, cliquez sur Espaces de travail → Ajouter un nouvel espace de travail. Donnez-lui le nom portail et une URI d’espace de noms, par exemple https://itskillscenter.io/portail (cette URI est un simple identifiant unique, elle n’a pas besoin d’être une vraie adresse accessible). Cochez la case pour en faire l’espace de travail par défaut, puis enregistrez.

✅ Point d’étape — Un espace de travail portail apparaît dans la liste.

Étape 4 — Connecter l’entrepôt PostGIS

L’entrepôt de données (store) décrit comment GeoServer accède à votre base. On crée un store de type PostGIS en renseignant les paramètres de connexion. GeoServer maintient alors un pool de connexions vers PostgreSQL et lit les tables à la demande — il ne copie pas les données.

Allez dans Entrepôts de données → Ajouter un nouvel entrepôt, choisissez PostGIS dans la liste des sources vectorielles. Renseignez les paramètres de connexion :

dbtype   : postgis
host     : localhost
port     : 5432
database : gis
schema   : public
user     : postgres
passwd   : (votre mot de passe PostgreSQL)

Associez l’entrepôt à l’espace de travail portail, donnez-lui un nom comme postgis_gis, puis enregistrez. Si GeoServer affiche une erreur de connexion, vérifiez que PostgreSQL accepte les connexions sur le port 5432 et que le fichier pg_hba.conf autorise l’utilisateur depuis l’hôte de GeoServer. Une connexion réussie mène directement à la liste des tables publiables.

✅ Point d’étape — L’entrepôt postgis_gis est créé et GeoServer liste les tables de votre base.

Étape 5 — Publier une couche

Lister une table ne suffit pas : il faut la publier, c’est-à-dire déclarer une couche exposée avec son système de coordonnées et son emprise géographique. Ces deux informations sont indispensables : sans elles, GeoServer ne sait pas où placer la couche sur le globe ni quelle étendue dessiner.

Dans la liste des tables, cliquez sur Publier en face de communes. Dans l’onglet Données, descendez jusqu’aux systèmes de coordonnées. Le « SRS déclaré » doit afficher EPSG:32628 (l’UTM 28N de vos données) ; si GeoServer ne l’a pas détecté, saisissez-le. Plus bas, cliquez sur Calculer depuis les données pour l’emprise native, puis Calculer depuis l’emprise native pour l’emprise en latitude-longitude. Enregistrez.

Répétez l’opération pour la couche ecoles. Chaque couche publiée devient immédiatement interrogeable via les services standard.

✅ Point d’étape — Les couches portail:communes et portail:ecoles sont publiées avec un SRS et une emprise corrects.

Étape 6 — Prévisualiser la couche

Avant de manipuler des URL, profitons de l’aperçu intégré pour valider d’un coup d’œil que la couche s’affiche. GeoServer embarque un visualiseur OpenLayers qui interroge le WMS pour vous.

Menu Aperçu des couches, trouvez portail:communes et cliquez sur le lien OpenLayers. Une carte interactive s’ouvre dans un nouvel onglet et affiche vos polygones. Si la carte est vide alors que la publication a réussi, c’est presque toujours une emprise mal calculée à l’étape 5 : revenez la recalculer depuis les données.

✅ Point d’étape — L’aperçu OpenLayers affiche vos communes. La publication est fonctionnelle.

Étape 7 — Demander une carte en WMS

Le service WMS (Web Map Service) renvoie une image de la carte. C’est le service idéal pour afficher rapidement de grands volumes sans transférer les données vectorielles au client. On le pilote entièrement par des paramètres d’URL — l’opération GetMap décrit la couche, l’emprise, la taille et le format voulus.

http://localhost:8080/geoserver/portail/wms?service=WMS&version=1.1.1
  &request=GetMap
  &layers=portail:communes
  &bbox=260000,1620000,275000,1635000
  &width=768&height=768
  &srs=EPSG:32628
  &format=image/png

Collez cette URL (sur une seule ligne, sans les espaces de présentation) dans le navigateur : vous obtenez une image PNG de vos communes. La bbox donne l’emprise à dessiner dans l’ordre min-X, min-Y, max-X, max-Y ; adaptez-la à vos coordonnées. On utilise ici la version 1.1.1 du WMS, dont l’ordre des axes (X puis Y) est plus intuitif que celui de la 1.3.0, qui inverse l’ordre pour certains systèmes de coordonnées et déroute souvent les débutants.

✅ Point d’étape — Une requête GetMap renvoie une image PNG de votre couche.

Étape 8 — Récupérer les données en WFS

Là où le WMS renvoie une image figée, le WFS (Web Feature Service) renvoie les entités vectorielles elles-mêmes : géométries et attributs, que le client peut styliser, interroger ou éditer. Demandé en sortie GeoJSON, c’est exactement ce qu’attend une carte web moderne pour afficher des objets cliquables.

http://localhost:8080/geoserver/portail/ows?service=WFS&version=2.0.0
  &request=GetFeature
  &typeNames=portail:communes
  &outputFormat=application/json
  &count=50

Le résultat est un document GeoJSON : une collection d’entités avec leurs géométries et leurs propriétés (dont la colonne nb_ecoles calculée plus tôt). Le paramètre count limite le nombre d’entités renvoyées — utile pour tester sans tout charger. En WFS 2.0.0, on désigne la couche par typeNames (au pluriel) ; c’est une source d’erreur fréquente quand on s’inspire d’exemples écrits pour l’ancienne version 1.1.0 qui utilisait typeName au singulier.

✅ Point d’étape — Une requête GetFeature renvoie vos entités en GeoJSON, prêtes pour une carte web.

Étape 9 — Styliser avec un SLD

Par défaut, GeoServer dessine les couches avec un style générique. Pour contrôler l’apparence côté serveur (couleurs, épaisseurs, classes), on utilise un style SLD (Styled Layer Descriptor), un format XML standard. Définir le style côté serveur garantit un rendu cohérent pour tous les clients WMS.

<?xml version="1.0" encoding="UTF-8"?>
<StyledLayerDescriptor version="1.0.0"
  xmlns="http://www.opengis.net/sld">
  <NamedLayer>
    <Name>communes</Name>
    <UserStyle>
      <FeatureTypeStyle>
        <Rule>
          <PolygonSymbolizer>
            <Fill><CssParameter name="fill">#a6cee3</CssParameter></Fill>
            <Stroke><CssParameter name="stroke">#1f78b4</CssParameter></Stroke>
          </PolygonSymbolizer>
        </Rule>
      </FeatureTypeStyle>
    </UserStyle>
  </NamedLayer>
</StyledLayerDescriptor>

Créez ce style dans Styles → Ajouter un nouveau style, collez le XML, validez la syntaxe avec le bouton de validation, puis associez-le à la couche communes dans l’onglet Publication de la couche. Vos cartes WMS adoptent désormais ce remplissage bleu clair à contour foncé.

✅ Point d’étape — La couche s’affiche avec votre style personnalisé dans l’aperçu et en WMS.

Étape 10 — Activer le cache de tuiles

Recalculer une image à chaque requête est coûteux. GeoServer intègre GeoWebCache, qui découpe la carte en tuiles carrées et les met en cache : les requêtes suivantes servent des tuiles déjà rendues, ce qui accélère radicalement l’affichage et soulage la base de données. Le tuilage est activé par défaut sur les couches publiées.

Dans Tile Caching → Tile Layers, vérifiez que vos couches sont listées et que la grille EPSG:900913 ou EPSG:4326 est cochée. L’aperçu de tuiles permet de pré-générer le cache pour les niveaux de zoom les plus consultés. Sur une connexion limitée, ce cache fait la différence entre une carte fluide et une carte qui rame.

✅ Point d’étape final — Le cache de tuiles est actif. Votre serveur cartographique est prêt à alimenter une application web.

🐞 Pièges fréquents

🌍 Adaptation au contexte local

GeoServer est gratuit et tourne sur un serveur modeste, mais Java consomme de la mémoire : prévoyez au moins 2 Go de RAM dédiés à la JVM pour un usage confortable, et ajustez les options de mémoire de Jetty si vous publiez de nombreuses couches. Sur un VPS partagé à bas coût — facturable en mobile money chez plusieurs hébergeurs régionaux — un seul cœur suffit tant que le cache de tuiles absorbe la charge de lecture. Pensez à placer GeoServer derrière un proxy inverse (Nginx) avec HTTPS, et à ne jamais exposer le port 8080 ni l’interface d’administration directement sur Internet : seuls les services WMS et WFS doivent être publics. Enfin, le cache GeoWebCache est votre meilleur allié face à une bande passante serveur limitée, puisqu’il évite de recalculer et de relire la base à chaque consultation.

✅ Récapitulatif

Vous avez installé GeoServer, sécurisé son accès, et l’avez connecté à PostGIS via un entrepôt de données. Vous avez publié des couches avec leur système de coordonnées et leur emprise, puis vous les avez interrogées des deux manières fondamentales : en WMS pour obtenir une image, en WFS pour récupérer les entités en GeoJSON. Vous savez enfin styliser côté serveur avec un SLD et activer le cache de tuiles. Vos données PostGIS sont désormais exposées comme des services standard — c’est tout ce dont a besoin une carte web pour les afficher, ce qui clôt l’avant-dernière étape de la chaîne.

🧾 Aide-mémoire

💪 À vous de jouer

Premier défi : publiez la couche écoles et créez un SLD qui colore les points selon leur champ type (public / privé). Second défi : configurez une couche groupée (layer group) qui empile communes et écoles, et servez-la en une seule requête WMS.

Tutoriels frères

• PostGIS et pgRouting : calculer des itinéraires sur un réseau routier — la source de données que GeoServer publie.
• MapLibre GL JS : afficher une carte web avec des tuiles vectorielles — consommer ces services dans le navigateur.

Pour aller plus loin

• 🔝 Retour au guide principal : La chaîne géospatiale open source
• Documentation officielle : docs.geoserver.org (manuel utilisateur et tutoriels)
• Pour préparer les données en amont : le tutoriel QGIS de la série.

FAQ

Q : WMS ou WFS, lequel utiliser ?
R : Le WMS renvoie une image, parfait pour afficher de gros volumes que le client n’a pas besoin de manipuler. Le WFS renvoie les données vectorielles, indispensable dès qu’on veut des objets cliquables, interrogeables ou éditables côté navigateur. Une carte web combine souvent les deux.

Q : Faut-il GeoServer ou peut-on servir PostGIS directement ?
R : Exposer PostgreSQL sur Internet est une faute de sécurité. GeoServer joue le rôle de couche de service : il lit la base en interne et ne publie que des services normalisés et contrôlés, sans révéler la base ni ses identifiants.

Q : GeoServer 2.28 ou GeoServer 3 ?
R : La série 2.28 est la version stable recommandée pour la production au moment d’écrire. GeoServer 3, qui migre vers une pile Java plus récente et une interface rafraîchie, approche de sa disponibilité générale ; pour un projet à mettre en ligne aujourd’hui, restez sur la 2.28.

Q : Comment réduire la consommation mémoire ?
R : Limitez le nombre de couches publiées, activez le cache de tuiles pour éviter les rendus répétés, et ajustez les options mémoire de la JVM. Sur un petit serveur, GeoWebCache fait l’essentiel du travail d’optimisation.