Tuto pour installer un serveur OpenStreetMap sur Ubuntu 24.04

Installer OpenStreetMap sur Ubuntu 24.04 consiste à déployer un serveur de tuiles associant PostgreSQL/PostGIS, osm2pgsql, un style cartographique, Mapnik, renderd, mod_tile et Apache. La méthode fiable commence par vérifier les paquets disponibles sur la machine, puis importe un extrait régional avant de tester une tuile située dans la zone réellement chargée.

Un serveur de tuiles OSM est une infrastructure qui transforme les données géographiques OpenStreetMap en images cartographiques accessibles par URL. Ce tutoriel cible exclusivement Ubuntu Server 24.04 LTS et privilégie les paquets de la distribution. Faute de séquence officielle Ubuntu 24.04 fournie et figée pour l’ensemble de la pile, les commandes dépendant des versions sont clairement signalées comme étant à valider avant exécution.

Que faut-il installer pour héberger OpenStreetMap sur Ubuntu 24.04 ?

Une pile raster OpenStreetMap comprend une base PostgreSQL enrichie par PostGIS, osm2pgsql pour l’import, Mapnik pour le rendu, un style compatible, renderd pour piloter les calculs, mod_tile pour gérer les requêtes et Apache pour répondre en HTTP. Chaque composant doit provenir d’une méthode d’installation cohérente avec Ubuntu 24.04.

OpenStreetMap fournit des données géographiques, pas un serveur prêt à ouvrir dans un navigateur. Le chemin d’une requête commence dans Apache, traverse mod_tile et renderd, puis sollicite Mapnik, le style et les tables PostGIS lorsque la tuile n’existe pas encore dans le cache.

Une page cartographique vide ne prouve pas que les données sont absentes : le problème peut venir du style, de renderd, des droits du cache ou de la zone demandée.

Composant	Fonction	Vérification utile	Erreur typique
PostgreSQL et PostGIS	Stocker les objets et fonctions géographiques	Contrôler les extensions dans la base cible	Extension créée dans la mauvaise base
osm2pgsql	Importer un extrait OSM dans PostgreSQL	Compter les tables et consulter les journaux d’import	Style d’import incompatible avec le style de rendu
Mapnik	Composer les images à partir du style	Charger le fichier XML final	Police, symbole ou source de données introuvable
renderd	Organiser les demandes de rendu	Consulter le service et son journal	Chemin XML ou répertoire de cache incorrect
mod_tile et Apache	Servir les tuiles et gérer leur état	Tester une URL locale et son type MIME	Module absent ou configuration non chargée

Quels prérequis vérifier avant l’installation ?

Ubuntu 24.04 doit être à jour, disposer d’un accès administrateur, d’un nom d’hôte fonctionnel et d’un stockage dimensionné pour l’extrait choisi. La mémoire, le temps d’import et le cache augmentent avec la surface couverte. Un petit extrait régional permet de valider la chaîne avant tout déploiement plus ambitieux.

Le dimensionnement ne peut pas être déduit de la seule taille du fichier PBF. Les tables PostGIS, les index temporaires, les données du style et les tuiles rendues consomment également du disque. Le serveur doit conserver une marge libre pendant l’import, car un volume saturé peut interrompre PostgreSQL et laisser une base partiellement chargée.

Les contrôles suivants ne modifient pas le système. Les résultats permettent de confirmer l’édition d’Ubuntu, l’espace disponible, la mémoire et l’état des dépôts APT.

lsb_release -ds
uname -m
df -h /
free -h
sudo apt update
apt-cache policy postgresql postgis osm2pgsql python3-mapnik mapnik-utils \
  renderd libapache2-mod-tile apache2

La première sortie attendue doit mentionner Ubuntu 24.04 LTS. La commande apt-cache policy doit afficher un « Candidat » pour chaque paquet envisagé. Une valeur « (aucun) » signifie que la séquence ci-dessous ne doit pas être poursuivie sans vérifier les dépôts Ubuntu activés et la documentation propre à la version.

• Choisir un extrait OSM limité dont la provenance et la date sont identifiables.
• Prévoir un compte système dédié plutôt que d’exécuter renderd avec un compte personnel.
• Conserver PostgreSQL et le service de rendu sur l’interface locale pendant la validation.
• Effectuer une sauvegarde ou un instantané avant toute modification d’un serveur existant.
• Noter les versions affichées par APT afin de ne pas mélanger plusieurs tutoriels.

Comment installer un serveur OSM sur Ubuntu 24.04 étape par étape ?

L’installation suit huit étapes continues : contrôler les paquets, installer la pile, créer les identités, préparer PostGIS, importer un extrait, générer le style, configurer renderd puis activer Apache. Chaque phase doit être validée avant la suivante. La commande d’installation reste à confirmer avec les candidats APT réellement affichés sur la machine.

1. Contrôler les paquets et leurs versions

   La liste des candidats APT constitue le point de départ de la pile. Enregistrez-la dans un fichier afin de garder une trace des versions proposées le jour de l’installation.

   mkdir -p "$HOME/osm-install-audit"
   apt-cache policy postgresql postgis osm2pgsql python3-mapnik mapnik-utils \
     renderd libapache2-mod-tile apache2 \
     | tee "$HOME/osm-install-audit/paquets.txt"

   Le fichier doit contenir une section par paquet et un candidat explicite. Un paquet manquant doit être recherché dans le catalogue Ubuntu 24.04 avant toute substitution ou compilation manuelle.

2. Installer une seule pile de paquets

   ⚠️ À VALIDER avant exécution : la commande suivante suppose que tous les paquets possèdent un candidat dans les dépôts Ubuntu 24.04 configurés sur la machine. La référence à consulter est le catalogue des paquets Ubuntu correspondant à Noble, complété par les fichiers README installés avec chaque paquet.

   # À exécuter uniquement après validation de tous les candidats APT
   sudo apt install postgresql postgis osm2pgsql python3-mapnik mapnik-utils \
     renderd libapache2-mod-tile apache2

   La vérification doit interroger chaque programme plutôt que se limiter au code retour d’APT.

   psql --version
   osm2pgsql --version
   python3 -c "import mapnik; print(mapnik.mapnik_version_string())"
   apache2ctl -v
   systemctl status postgresql --no-pager

3. Créer une identité de service cohérente

   Le compte système, le rôle PostgreSQL, les fichiers du style et le cache doivent être alignés. ⚠️ À VALIDER : le nom de l’utilisateur exécutant renderd doit d’abord être lu dans l’unité systemd livrée par le paquet.

   systemctl cat renderd
   getent passwd renderd
   dpkg -L renderd | sort

   Si l’unité annonce un utilisateur existant, ce compte doit devenir propriétaire des seuls répertoires nécessaires au rendu. Ne créez pas un second compte portant un autre nom et n’utilisez jamais chmod 777 pour masquer un problème de droits.

4. Créer la base PostgreSQL et activer PostGIS

   ⚠️ À COMPLÉTER/VALIDER : le nom du rôle doit correspondre à l’utilisateur de service confirmé à l’étape précédente. Les commandes SQL doivent être exécutées avec arrêt immédiat en cas d’erreur.

   # Exemple structurel : remplacer osm_service uniquement par le compte validé
   sudo -u postgres createuser --no-superuser --no-createdb --no-createrole osm_service
   sudo -u postgres createdb --owner=osm_service gis
   sudo -u postgres psql -v ON_ERROR_STOP=1 -d gis <<'SQL'
   CREATE EXTENSION postgis;
   CREATE EXTENSION hstore;
   SELECT PostGIS_Full_Version();
   SQL

   La dernière requête doit retourner la version de PostGIS. La présence de la base seule ne suffit pas : les extensions doivent apparaître dans \dx pour la base gis.

5. Importer l’extrait OpenStreetMap

   Le fichier PBF doit être placé dans un répertoire lisible par l’utilisateur d’import et accompagné de sa provenance. ⚠️ À COMPLÉTER/VALIDER : la commande osm2pgsql exacte dépend du style choisi et de son modèle d’import, notamment du fichier Lua ou du mode de sortie exigé.

   osm2pgsql --help
   sudo -u osm_service psql -v ON_ERROR_STOP=1 -d gis -c \
     "SELECT PostGIS_Full_Version();"
   
   # À VALIDER dans la documentation du style retenu :
   # osm2pgsql [options officielles du style] /srv/osm/data/region.osm.pbf

   La commande d’import doit provenir du fichier d’installation de la même révision que le style. Une ancienne commande basée sur un autre schéma peut réussir techniquement tout en créant des tables inutilisables par le rendu.

6. Générer et charger le style cartographique

   Le style doit produire un fichier Mapnik complet qui référence la base, les polices et les symboles présents sur le serveur. ⚠️ À COMPLÉTER/VALIDER : aucun dépôt, tag ou compilateur Carto n’est imposé ici, car leur compatibilité avec Ubuntu 24.04 et la révision du style n’est pas établie par une séquence officielle fournie.

   # Après génération officielle du fichier Mapnik :
   python3 - <<'PY'
   import mapnik
   m = mapnik.Map(256, 256)
   mapnik.load_map(m, "/chemin/valide/style.xml")
   print("Style Mapnik chargé")
   PY

   Le message final ne doit apparaître qu’après le chargement effectif du XML. Un simple import mapnik teste la bibliothèque Python, mais ne détecte ni une police absente ni une source PostGIS mal configurée.

7. Configurer renderd sans exposer le service

   Le fichier de renderd doit désigner le XML validé, le cache, le nombre de processus et le socket local attendu par mod_tile. ⚠️ À COMPLÉTER/VALIDER : récupérez le modèle exact livré par le paquet Ubuntu 24.04 et comparez chaque directive avec sa page de manuel.

   dpkg -L renderd | grep -E 'renderd\.conf|example|README'
   man renderd
   systemctl cat renderd

   Un fichier générique copié depuis Ubuntu 20.04 ou 22.04 ne doit pas être présenté comme compatible sans contrôle. Le chemin du style, le compte de service et le répertoire du cache doivent correspondre exactement aux ressources créées pendant les étapes précédentes.

8. Activer mod_tile et vérifier Apache

   Apache doit charger mod_tile et une configuration locale correspondant au socket de renderd. ⚠️ À COMPLÉTER/VALIDER : les noms des fichiers activés doivent être relevés dans le paquet libapache2-mod-tile installé sur Ubuntu 24.04.

   dpkg -L libapache2-mod-tile | sort
   apache2ctl -M | grep -i tile
   sudo apache2ctl configtest
   sudo systemctl restart renderd
   sudo systemctl restart apache2
   systemctl --no-pager --full status renderd apache2

   Le test de configuration Apache doit afficher Syntax OK. Les deux services doivent être actifs sans boucle de redémarrage, et les journaux ne doivent signaler ni socket absent ni refus d’accès au cache.

Une commande d’import réussie n’est qu’une étape : la validation finale doit charger le style puis demander une tuile située à l’intérieur de l’extrait importé.

Comment configurer renderd et Apache sans mélanger les versions ?

La configuration doit être dérivée des fichiers installés par les paquets Ubuntu 24.04, puis adaptée aux chemins réellement créés. Il faut éviter les fichiers copiés depuis une autre version d’Ubuntu. Le socket de renderd, le cache, l’utilisateur du service, le XML Mapnik et la directive Apache doivent former une chaîne cohérente.

Les paquets fournissent généralement des unités systemd, des pages de manuel, des exemples ou des fragments Apache. La commande dpkg -L indique leur emplacement exact sur la machine. Cette méthode évite de supposer qu’un chemin observé dans un ancien tutoriel existe encore.

• systemctl cat renderd révèle l’utilisateur, la commande de démarrage et les éventuels paramètres.
• apache2ctl -M confirme que le module est réellement chargé.
• apache2ctl -S expose les hôtes virtuels et les fichiers Apache pris en compte.
• journalctl -u renderd montre les erreurs de style, de socket ou de permissions.
• namei -l /chemin/du/cache contrôle les droits sur chaque niveau du chemin.

Le service de rendu n’a pas besoin d’écouter sur 0.0.0.0. Le dialogue avec mod_tile doit rester local, tandis que l’exposition HTTP se gère dans Apache et dans le pare-feu selon les besoins réels du projet.

Comment vérifier que le serveur de tuiles fonctionne vraiment ?

Une vérification complète contrôle PostgreSQL, charge le style Mapnik, inspecte renderd et demande une tuile dont les coordonnées se trouvent dans l’extrait importé. Le fichier reçu doit être une image valide, pas une page HTML d’erreur enregistrée avec une extension PNG. Les journaux doivent ensuite confirmer le rendu.

Commencez par choisir un point connu à l’intérieur de la zone importée, puis calculez ou relevez ses coordonnées de tuile pour un niveau de zoom raisonnable. Une requête vers 0/0/0 ne valide pas un extrait régional, car cette tuile mondiale peut suivre un chemin différent ou ne contenir aucun détail exploitable.

# Remplacer Z, X et Y par une tuile située dans l'extrait importé
curl --fail --silent --show-error \
  --output /tmp/tuile-test.png \
  "http://127.0.0.1/osm/Z/X/Y.png"

file /tmp/tuile-test.png
stat /tmp/tuile-test.png
journalctl -u renderd --since "5 minutes ago" --no-pager
tail -n 50 /var/log/apache2/error.log

La commande file doit reconnaître une image PNG. Une réponse HTML indique souvent une route Apache incorrecte, une erreur interne ou une page 404. Une image transparente peut révéler une tuile hors zone, une base vide ou un style qui ne trouve pas les tables attendues.

Serveur raster manuel, conteneur ou tuiles vectorielles : que choisir ?

La pile Mapnik, renderd et mod_tile convient aux tuiles raster classiques et au contrôle détaillé du style. Une image conteneurisée facilite la reproductibilité, mais ne supprime ni le stockage ni l’exploitation. Martin sert des tuiles vectorielles depuis PostgreSQL, tandis que TileServer GL diffuse notamment des styles et tuiles vectoriels.

Option	Usage adapté	Avantage principal	Limite à anticiper
Mapnik, renderd et mod_tile	Produire des tuiles raster personnalisées	Contrôle du rendu côté serveur	Pile longue à configurer et à maintenir
Déploiement conteneurisé	Reproduire un environnement figé	Dépendances regroupées dans une image	Volumes, mises à jour et sauvegardes restent nécessaires
Martin	Servir des données PostGIS en tuiles vectorielles	Architecture différente, orientée vecteur	Ne remplace pas directement un rendu raster Mapnik
TileServer GL	Diffuser des cartes fondées sur des tuiles vectorielles	Styles côté client ou rendu associé	Demande une chaîne de données adaptée au format vectoriel

Le choix dépend du produit attendu. Une application devant afficher exactement les mêmes images à tous les clients peut préférer le raster. Une interface interactive qui modifie les couleurs ou masque des couches côté navigateur peut tirer davantage parti des tuiles vectorielles.

Quelles erreurs font échouer une installation OSM sur Ubuntu ?

Les échecs viennent surtout du mélange de versions, d’un import incompatible avec le style, de permissions incohérentes, d’un test effectué hors de la zone importée ou d’un serveur sous-dimensionné. Chaque piège laisse des indices distincts dans PostgreSQL, le chargeur Mapnik, le journal de renderd ou les erreurs Apache.

• Mélanger les instructions Ubuntu 22.04 et les paquets Ubuntu 24.04 : les chemins, dépendances ou unités systemd peuvent différer. Il faut partir des fichiers réellement installés.
• Importer avant de choisir le style : osm2pgsql peut produire un schéma différent de celui attendu. La commande d’import doit venir de la même révision documentaire que le style.
• Tester uniquement l’URL de la tuile mondiale : le test ne sollicite pas forcément les données régionales. Une tuile située dans l’extrait doit être demandée.
• Corriger les droits avec des permissions ouvertes : chmod 777 masque l’identité fautive et élargit inutilement les accès. Le propriétaire et le groupe doivent être corrigés précisément.
• Importer une zone trop vaste dès le premier essai : le diagnostic devient lent et le disque peut saturer. Un extrait limité permet d’abord de valider toute la chaîne.

Dépannage : quel symptôme correspond à quelle cause ?

Le dépannage doit suivre le trajet d’une tuile : réponse Apache, module mod_tile, socket renderd, chargement Mapnik puis accès PostGIS. Cette progression réduit les fausses pistes. Une erreur située en amont doit être corrigée avant d’ajuster les performances ou de relancer plusieurs imports.

Symptôme	Cause probable	Contrôle	Action prudente
Erreur 404	Route mod_tile absente	apache2ctl -M et apache2ctl -S	Vérifier le module et le fragment Apache fourni par le paquet
Erreur 500	Socket ou service indisponible	Journaux Apache et renderd	Comparer les chemins déclarés des deux côtés
Permission refusée	Compte renderd sans accès	namei -l sur le style et le cache	Corriger propriétaire et groupe sans ouvrir tous les droits
Tuile vide	Zone hors extrait ou tables incompatibles	Coordonnées de la tuile et tables PostgreSQL	Tester un point connu dans la zone importée
Mapnik refuse le XML	Police, symbole ou source absent	Chargement direct avec Python Mapnik	Corriger la première ressource manquante signalée
Import interrompu	Disque ou mémoire insuffisants	df -h, free -h et journaux PostgreSQL	Nettoyer l’import incomplet et réduire la zone

Les journaux doivent être lus autour de l’heure exacte du test. Relancer tous les services sans examiner la première erreur efface parfois le contexte utile sans résoudre la cause. Une seule requête de tuile, suivie immédiatement des journaux correspondants, produit un diagnostic plus propre.

Sources utiles à consulter

La documentation de Switch2OSM décrit la construction manuelle d’un serveur de tuiles pour Ubuntu 22.04. Cette version ne doit pas être copiée mécaniquement sur Ubuntu 24.04, mais la source reste utile pour comprendre l’architecture et l’ordre logique des composants : Switch2OSM — serveur de tuiles manuel.

Le tutoriel OSM Carto détaille également Mapnik, PostgreSQL, osm2pgsql, renderd et Apache. Les commandes doivent être comparées aux paquets Noble installés localement avant utilisation : OSM Carto Tutorials — serveur Ubuntu.

La documentation ETSI consacrée à « OSM » concerne Open Source MANO, un projet d’orchestration réseau distinct d’OpenStreetMap. Elle ne doit pas servir à installer un serveur cartographique : documentation ETSI Open Source MANO.

Avertissement sur l’environnement ciblé : cette procédure vise Ubuntu Server 24.04 LTS avec les versions de PostgreSQL, PostGIS, osm2pgsql, Mapnik, renderd, mod_tile et Apache proposées par les dépôts configurés sur la machine. Les commandes signalées doivent être validées contre les paquets Ubuntu 24.04 et la documentation du style retenu. Rejouez l’installation sur une machine vierge avant toute mise en production.

Questions fréquentes sur l’installation d’OSM

Peut-on installer toute la planète OpenStreetMap sur un petit VPS ?

Un fichier mondial exige des ressources importantes pour l’import, les index, la base et le cache. Un extrait régional est plus adapté pour valider la pile et mesurer les besoins réels avant d’augmenter la couverture.

OpenStreetMap et OSM ETSI désignent-ils le même logiciel ?

Non. OpenStreetMap est le projet de données cartographiques utilisé dans ce tutoriel, tandis qu’OSM ETSI désigne Open Source MANO, une plateforme d’orchestration de services réseau.

Pourquoi ne pas copier directement un tutoriel Ubuntu 22.04 ?

Les versions des paquets, les dépendances, les chemins et les unités systemd peuvent évoluer entre deux versions LTS. Les fichiers installés par Ubuntu 24.04 doivent rester la référence locale.

Une tuile PNG vide signifie-t-elle que renderd est en panne ?

Pas nécessairement. Une tuile vide peut venir d’une coordonnée hors extrait, d’un style incompatible avec les tables importées ou d’une couche qui ne trouve pas ses données.

Faut-il utiliser Mapnik pour toutes les cartes OSM ?

Mapnik convient à une pile raster traditionnelle, mais les architectures vectorielles peuvent utiliser d’autres serveurs comme Martin ou TileServer GL. Le choix dépend du format attendu et du lieu où le style doit être appliqué.