Comment installer un serveur OSM sur Ubuntu 24.04 et publier ses premières tuiles

Comment installer un serveur OSM sur Ubuntu 24.04 et publier ses premières tuiles
Pour installer un serveur OSM sur Ubuntu 24.04, il faut installer PostgreSQL 16 et PostGIS, importer un fichier OSM au format PBF avec osm2pgsql, compiler le style openstreetmap-carto avec Carto, puis relier Mapnik, renderd, mod_tile et Apache. Le chemin le plus prudent consiste à commencer avec un extrait régional plutôt qu’avec la planète entière.
Un serveur de tuiles OpenStreetMap est un serveur cartographique qui transforme des données géographiques OSM en images de carte servies au navigateur. Ce tutoriel cible Ubuntu 24.04 LTS sur architecture amd64, avec la pile documentée autour de PostgreSQL 16, Carto 1.2.0 et openstreetmap-carto v5.9.0. L’interface et les paquets évoluent : rejouez chaque commande sur une machine vierge avant toute mise en production.
Sommaire
En bref
🧩 La pile repose sur PostgreSQL 16, PostGIS, osm2pgsql, Mapnik, renderd, mod_tile et Apache.
📦 Commencez avec un extrait régional .osm.pbf : l’import de la planète entière demande des ressources très supérieures et ne convient pas à un VPS classique.
🗺️ Le style openstreetmap-carto v5.9.0 doit être compilé en mapnik.xml avant que renderd puisse produire des tuiles.
🔒 PostgreSQL reste local au serveur dans cette procédure : Apache publie les tuiles, pas la base de données.
Prérequis avant d’installer un serveur de tuiles OpenStreetMap
Un serveur cartographique Ubuntu doit disposer d’un système Ubuntu 24.04 LTS à jour, d’un compte capable d’utiliser sudo, d’un accès réseau sortant pour récupérer les données et d’un espace disque disponible. La documentation de référence pour cette pile indique qu’un petit extrait demande déjà au moins 18 Go d’espace, entre les données PBF, la base PostGIS, les fichiers externes et le cache de tuiles.
Le facteur limitant est généralement l’import dans PostGIS, pas l’affichage initial de quelques tuiles. La mémoire disponible, la taille de l’extrait choisi et les niveaux de zoom pré-rendus modifient fortement le temps de traitement. Vérifiez les ressources avant de télécharger un fichier PBF.
| Élément à contrôler | Commande | Résultat attendu | Pourquoi |
|---|---|---|---|
| Version du système | lsb_release -a |
Ubuntu 24.04 LTS | Les commandes suivantes visent cette version. |
| Mémoire disponible | free -h |
Valeur à comparer à la taille de l’extrait | L’import osm2pgsql utilise mémoire et disque. |
| Espace libre | df -h |
Au moins 18 Go pour un petit extrait | Évite un import interrompu faute d’espace. |
| Droits administrateur | sudo -v |
Aucune erreur | Les paquets et services nécessitent sudo. |
- Choisissez un extrait régional adapté à la zone réellement affichée par votre application.
- Gardez PostgreSQL sur
localhostsi la base et le moteur de rendu sont sur le même serveur. - Prévoyez une sauvegarde de la base avant tout nouvel import destructif avec
--create.
Un extrait régional permet de vérifier le mécanisme complet : import, style, rendu et publication web, sans transformer le premier essai en chantier d’infrastructure.
Comment préparer Ubuntu 24.04 pour le serveur OSM ?
La préparation consiste à mettre Ubuntu à jour puis à installer les composants de la pile dans une seule opération cohérente. Ubuntu 24.04 fournit PostgreSQL 16 et les paquets nécessaires à PostGIS, osm2pgsql, Mapnik, Apache, mod_tile et renderd. N’ajoutez pas de PPA obsolète pour remplacer ces paquets natifs.
Exécutez d’abord la mise à jour du système. Une mise à niveau peut demander un redémarrage si le noyau ou des bibliothèques centrales ont été remplacés.
Étape 1 : mettre à jour Ubuntu et installer les paquets
sudo apt update
sudo apt upgrade
sudo apt install \
screen locate libapache2-mod-tile renderd \
git tar unzip wget bzip2 apache2 lua5.1 \
mapnik-utils python3-mapnik python3-psycopg2 \
python3-yaml gdal-bin npm node-carto \
postgresql postgresql-contrib postgis \
postgresql-16-postgis-3 postgresql-16-postgis-3-scripts \
osm2pgsql net-tools curl
La commande installe le serveur web, le moteur de rendu, les bibliothèques cartographiques, les outils d’import et les dépendances du style. Le paquet node-carto est installé avec les dépendances, mais la version de Carto utilisée pour compiler le style sera installée explicitement à l’étape 4.
Vérifiez que les composants attendus sont présents :
dpkg -l | grep -E 'postgresql|postgis|osm2pgsql|mapnik|mod_tile|renderd'
Le résultat doit contenir les paquets PostgreSQL, PostGIS, osm2pgsql, Mapnik, libapache2-mod-tile et renderd. Si un paquet manque, corrigez l’erreur APT avant de poursuivre : les étapes suivantes dépendent de cette installation.
Étape 2 : vérifier Mapnik
python3 -c 'import mapnik'
La commande doit se terminer sans message d’erreur. Mapnik est la bibliothèque qui lit le style XML et dessine les données géographiques dans les tuiles raster.
Comment créer la base PostgreSQL PostGIS pour OSM ?
PostgreSQL avec PostGIS stocke les géométries, les noms, les routes et les autres objets importés depuis OpenStreetMap. La procédure crée le rôle local _renderd et la base gis, puis active les extensions indispensables au style openstreetmap-carto.
Le rôle PostgreSQL, le processus renderd et les fichiers de données doivent conserver des droits cohérents. Ne rendez pas PostgreSQL accessible publiquement pour cette installation locale : Apache doit être le seul service exposé aux visiteurs.
Étape 3 : créer le rôle et la base gis
sudo -u postgres -i
createuser _renderd
createdb -E UTF8 -O _renderd gis
psql
\c gis
CREATE EXTENSION postgis;
CREATE EXTENSION hstore;
ALTER TABLE geometry_columns OWNER TO _renderd;
ALTER TABLE spatial_ref_sys OWNER TO _renderd;
\q
exit
La base gis doit maintenant exister avec les extensions PostGIS et hstore. Vérifiez le résultat sans modifier la base :
sudo -u postgres psql -d gis -c '\dx'
sudo -u postgres psql -d gis -c '\du'
La première commande doit afficher postgis et hstore. La seconde doit lister le rôle _renderd.
Comment installer et préparer le style OSM Carto ?
Openstreetmap-carto est un style de carte qui décrit les couches, symboles, libellés et règles de rendu. La version v5.9.0 est utilisée ici avec Carto 1.2.0 afin de produire un fichier mapnik.xml compatible avec le moteur de rendu configuré ensuite.
La pile reste cohérente avec la documentation Ubuntu 24.04, mais un style de carte et ses dépendances évoluent. Pour un projet durable, vérifiez les versions maintenues dans la documentation officielle d’installation manuelle du serveur de tuiles avant de figer une image de production.
Étape 4 : cloner openstreetmap-carto et compiler Mapnik
mkdir ~/src
cd ~/src
git clone https://github.com/gravitystorm/openstreetmap-carto
cd openstreetmap-carto
git pull --all
git switch --detach v5.9.0
sudo npm install -g [email protected]
carto -v
carto project.mml > mapnik.xml
La commande carto -v doit indiquer 1.2.0. Le fichier mapnik.xml doit être généré dans le répertoire du style.
test -s ~/src/openstreetmap-carto/mapnik.xml && echo "mapnik.xml généré"
git -C ~/src/openstreetmap-carto describe --tags --exact-match
Le premier contrôle confirme que le fichier XML n’est pas vide. Le second doit afficher v5.9.0.
Comment importer un fichier PBF dans PostgreSQL avec osm2pgsql ?
Osm2pgsql est l’outil qui lit un fichier .osm.pbf et crée les tables utilisées par le style de carte dans PostGIS. L’exemple télécharge l’extrait Azerbaïdjan de Geofabrik, mais vous devez remplacer cette zone par celle que votre carte doit réellement couvrir.
Un import avec --create reconstruit les tables OSM de la base cible. N’exécutez pas cette commande sur une base contenant des données que vous souhaitez conserver sans disposer d’une sauvegarde vérifiée.
Étape 5 : télécharger un extrait régional OSM
mkdir ~/data
cd ~/data
wget https://download.geofabrik.de/asia/azerbaijan-latest.osm.pbf
ls -lh azerbaijan-latest.osm.pbf
Le fichier téléchargé doit être présent et sa taille ne doit pas être nulle. Pour une autre région, sélectionnez l’URL de l’extrait correspondant sur le site de Geofabrik, puis adaptez le nom de fichier dans toutes les commandes suivantes.
Étape 6 : autoriser renderd à lire le style et importer les données
chmod o+rx ~
sudo -u _renderd \
osm2pgsql -d gis --create --slim -G --hstore \
--tag-transform-script \
~/src/openstreetmap-carto/openstreetmap-carto.lua \
-C 2500 --number-processes 1 \
-S ~/src/openstreetmap-carto/openstreetmap-carto.style \
~/data/azerbaijan-latest.osm.pbf
La permission o+rx permet au processus renderd de traverser le répertoire personnel afin d’accéder au fichier XML et aux ressources du style. Elle ne rend pas les fichiers du dossier personnel modifiables ; contrôlez néanmoins les permissions de vos fichiers sensibles avant de l’appliquer sur un serveur partagé.
Une fois l’import terminé, vérifiez que les tables de rendu existent :
sudo -u _renderd psql -d gis -c "SELECT count(*) FROM planet_osm_point;"
Le nombre retourné doit être supérieur à zéro pour l’extrait utilisé. Une erreur mémoire pendant l’import demande de réduire la taille de l’extrait, d’augmenter les ressources disponibles ou de revoir les paramètres d’import avant de recommencer.
Étape 7 : appliquer les index, fonctions, données externes et polices
cd ~/src/openstreetmap-carto
sudo -u _renderd psql -v ON_ERROR_STOP=1 -d gis -f indexes.sql
sudo -u _renderd psql -v ON_ERROR_STOP=1 -d gis -f functions.sql
mkdir data
sudo chown _renderd data
sudo -u _renderd scripts/get-external-data.py
scripts/get-fonts.sh
Les index et fonctions SQL complètent les tables importées. Les données externes et les polices fournissent des ressources nécessaires à certaines couches et à certains libellés du style.
sudo -u _renderd psql -d gis -c '\di'
find ~/src/openstreetmap-carto/data -type f | head
find ~/src/openstreetmap-carto/fonts -type f | head
Les trois contrôles doivent afficher des index, des fichiers de données externes et des polices. Une commande SQL arrêtée par ON_ERROR_STOP doit être corrigée avant de démarrer renderd.
Comment configurer renderd et mod_tile pour générer les tuiles ?
Renderd reçoit les demandes de rendu envoyées par mod_tile, charge le style Mapnik et écrit les tuiles générées dans son cache. La configuration crée ici une couche accessible sous l’URI /hot/, avec des tuiles de 256 pixels et un zoom maximal fixé à 20.
Le chemin du fichier XML doit désigner le répertoire personnel réel de votre compte Linux. Conservez les sections [renderd] et [mapnik] fournies par le paquet, notamment leurs paramètres de socket, de cache, de plugins et de polices, puis ajoutez ou remplacez uniquement la section de couche suivante.
Étape 8 : ajouter la configuration renderd
STYLE_DIR="$(readlink -f ~/src/openstreetmap-carto)"
sudo nano /etc/renderd.conf
Dans le fichier existant, conservez les sections [renderd] et [mapnik], puis ajoutez ou remplacez la section suivante :
[s2o]
URI=/hot/
XML=${STYLE_DIR}/mapnik.xml
HOST=localhost
TILESIZE=256
MAXZOOM=20
sudo cat /etc/renderd.conf
Le résultat doit afficher les sections [renderd], [mapnik] et [s2o], avec un chemin absolu vers mapnik.xml. Ne supprimez pas les paramètres socketname, tile_dir, plugins_dir ou font_dir fournis par le paquet dans la configuration principale de renderd.

Étape 9 : activer la configuration Apache fournie pour renderd
cd /etc/apache2/conf-available/
sudo wget https://raw.githubusercontent.com/openstreetmap/mod_tile/python-implementation/etc/apache2/renderd.conf
sudo a2enconf renderd
sudo systemctl reload apache2
La configuration Apache active le lien entre le module mod_tile et renderd. Vérifiez la syntaxe avant le redémarrage complet :
sudo apachectl configtest
sudo apachectl -M | grep tile
sudo systemctl status apache2 --no-pager
Le test doit afficher Syntax OK. Le module mod_tile doit apparaître dans la liste des modules chargés.
Une tuile absente du cache n’est pas forcément une panne : renderd peut devoir la calculer lors de la première demande, puis la servir plus vite lors des demandes suivantes.
Comment publier et vérifier les premières tuiles dans le navigateur ?
Apache publie les tuiles générées sous l’URI déclaré dans /etc/renderd.conf. Après le redémarrage des services, la première requête sur une zone réellement importée déclenche un rendu à la demande ; le journal de renderd permet de distinguer une demande reçue d’un problème de style ou de base.
Ne désactivez pas le pare-feu pour ce test. Si le serveur est distant, autorisez uniquement le service web nécessaire en suivant ce guide pour gérer un port UFW sans vous bloquer, puis vérifiez l’adresse utilisée avec ces méthodes pour identifier l’adresse IP du serveur.
Étape 10 : démarrer les services et suivre le rendu
sudo systemctl daemon-reload
sudo systemctl restart renderd
sudo systemctl restart apache2
sudo systemctl status renderd --no-pager
sudo systemctl status apache2 --no-pager
tail -f /var/log/syslog | grep " TILE "
Les services doivent être indiqués comme actifs. Laissez le suivi des journaux ouvert pendant le premier chargement de carte afin d’observer les lignes contenant TILE.
Étape 11 : publier une page de test Leaflet
cd /var/www/html
sudo wget https://raw.githubusercontent.com/SomeoneElseOSM/mod_tile/switch2osm/extra/sample_leaflet.html
sudo nano sample_leaflet.html
Dans le fichier, renseignez l’adresse IP ou le nom de domaine réel du serveur à la place de l’adresse d’exemple, puis ouvrez http://adresse-du-serveur/sample_leaflet.html dans un navigateur. La page doit demander les tuiles sous /hot/.
Pour suivre l’espace consommé pendant les essais, utilisez les méthodes permettant de repérer les fichiers Linux volumineux. Le cache de tuiles peut croître vite lorsque les visiteurs explorent une large zone ou de nombreux niveaux de zoom.
Comment mettre à jour les données OSM sans réimporter toute la carte ?
Les données OpenStreetMap changent continuellement. Une mise à jour peut s’appuyer sur des diffs OSM appliqués à la base, suivis de la régénération des tuiles expirées, mais la configuration précise dépend de l’extrait, du mode d’import choisi et de la politique de cache.
La procédure de réplication dépend de l’extrait, du mode d’import et de la version d’osm2pgsql. Consultez la documentation officielle de l’outil et testez-la sur une copie de la base avant toute automatisation en production. N’automatisez pas une tâche cron qui modifie la base sans journalisation, sauvegarde et vérification du résultat.
- Conservez la date et l’URL de l’extrait initial importé.
- Testez les mises à jour sur une instance séparée avant d’automatiser leur exécution.
- Surveillez la taille de la base, du cache et les erreurs de rendu après chaque mise à jour.
- Définissez une politique d’expiration des tuiles avant de pré-rendre de grandes surfaces.
Erreurs fréquentes avec un serveur de tuiles OSM
Les erreurs les plus coûteuses sont souvent des incohérences simples : mauvais chemin vers mapnik.xml, données externes absentes, droits insuffisants pour le rôle _renderd ou import interrompu. Le journal systemd et les requêtes SQL de contrôle permettent de localiser le maillon en cause.
| Symptôme | Cause probable | Contrôle concret | Action prudente |
|---|---|---|---|
| osm2pgsql s’arrête | Mémoire ou disque insuffisant | free -h et df -h |
Réduire l’extrait ou augmenter les ressources avant un nouvel import. |
| renderd ne démarre pas | Chemin XML ou droits incorrects | sudo journalctl -u renderd -n 100 |
Comparer le chemin XML et vérifier que _renderd peut le lire. |
| Apache renvoie une erreur | Configuration mod_tile inactive | sudo apachectl configtest |
Réactiver la configuration renderd puis recharger Apache. |
| Carte vide dans le navigateur | URI différent ou zone non importée | Comparer /hot/ dans HTML et renderd.conf |
Tester une zone contenue dans l’extrait PBF chargé. |
Étape 12 : activer temporairement le diagnostic renderd
sudo systemctl edit renderd
Saisissez exactement le contenu suivant dans l’override, puis enregistrez et quittez l’éditeur :
[Service]
Environment=G_MESSAGES_DEBUG=all
Rechargez ensuite systemd et redémarrez le service :
sudo systemctl daemon-reload
sudo systemctl restart renderd
sudo journalctl -u renderd -f
Les messages de diagnostic aident à identifier une erreur de chargement du style, une ressource absente ou un refus d’accès à la base. Retirez le diagnostic renforcé lorsque le problème est résolu afin de limiter le volume de journaux.
Bonnes pratiques pour exploiter le serveur cartographique
Un serveur de tuiles exploitable ne se résume pas à une page qui affiche une carte une fois. Le trafic, l’étendue couverte, le nombre de zooms demandés et la fréquence des changements de données déterminent la charge réelle.
Mesurez les journaux, l’espace disque et les temps de rendu avant de lancer un pré-rendu massif. Le rendu localisé, sur une zone utile et pour quelques niveaux de zoom, évite de générer immédiatement des tuiles qui ne seront jamais consultées.
- Servez les tuiles via HTTPS derrière une configuration Apache adaptée à votre nom de domaine.
- Conservez PostgreSQL sur l’interface locale lorsque la base n’a pas besoin d’être distante.
- Sauvegardez la base
giset les fichiers de configuration avant une mise à jour majeure. - Documentez l’extrait PBF, la version du style et la date du dernier import.
- Contrôlez régulièrement le cache et les journaux pour détecter une croissance anormale.
Conclusion : un premier serveur OSM fonctionnel
Le serveur de tuiles est prêt lorsque PostgreSQL contient les données importées, que mapnik.xml est généré, que renderd démarre sans erreur et qu’Apache sert les requêtes sous /hot/. Le premier objectif reste un extrait régional visible dans le navigateur ; les mises à jour automatisées et le pré-rendu viennent ensuite, une fois les contrôles de base validés.
Avertissement : cette procédure cible Ubuntu 24.04 LTS amd64, PostgreSQL 16, PostGIS 3, Carto 1.2.0 et openstreetmap-carto v5.9.0. Rejouez l’installation sur une machine vierge, vérifiez les versions des paquets disponibles et testez les sauvegardes avant toute exposition en production.
Sources
- Switch2OSM — Manually building a tile server on Ubuntu 24.04 LTS
- openstreetmap-carto v5.9.0 — notes de version
- Carto 1.2.0 — paquet npm
- osm2pgsql — documentation officielle
- Geofabrik — extraits OpenStreetMap au format PBF
À retenir
- 🧩 PostgreSQL 16 et PostGIS stockent les données spatiales importées depuis le fichier PBF.
- 🗺️ OSM Carto doit produire mapnik.xml avant le démarrage de renderd.
- 🔍 Vérifiez chaque phase avec une commande avant de configurer le composant suivant.
- 🔒 Apache publie les tuiles ; PostgreSQL reste local au serveur dans cette architecture.
- 📦 Un extrait régional réduit le risque technique du premier déploiement.
Questions fréquentes
Peut-on importer la planète entière sur un VPS classique ?
L’import du fichier mondial planet.osm demande des ressources de stockage, de mémoire et de traitement très importantes. Un extrait régional est plus adapté pour vérifier la pile technique et pour un usage géographiquement limité.
Pourquoi utiliser PostgreSQL et PostGIS pour un serveur OSM ?
PostgreSQL stocke les tables issues de l’import OSM. PostGIS ajoute les types et fonctions géographiques nécessaires au style de carte, aux index spatiaux et aux requêtes utilisées pendant le rendu.
À quoi servent mod_tile et renderd ?
mod_tile reçoit les demandes HTTP de tuiles depuis Apache. Renderd génère les tuiles demandées avec Mapnik, les place en cache et les rend disponibles pour les demandes suivantes.
Pourquoi les tuiles n’apparaissent-elles pas immédiatement ?
Une première demande peut déclencher le calcul de la tuile si elle n’est pas encore présente dans le cache. Vérifiez les journaux renderd, l’URI /hot/, le chemin vers mapnik.xml et la présence de données dans la zone demandée.
Faut-il ouvrir PostgreSQL sur Internet pour afficher les cartes ?
Non. Apache et mod_tile communiquent localement avec renderd, qui accède à PostgreSQL sur le même serveur. L’exposition directe de PostgreSQL augmente inutilement la surface d’attaque dans cette architecture.