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, installez PostgreSQL avec PostGIS, importez un extrait régional OpenStreetMap avec osm2pgsql et le script du style OSM Carto, générez le style Mapnik puis reliez renderd et mod_tile à Apache. Le premier test utile consiste à télécharger une tuile locale au format PNG, avant d’afficher une carte dans un navigateur.
Un serveur de tuiles OpenStreetMap est un serveur cartographique qui transforme des données géographiques OSM en images de carte, généralement des tuiles carrées de 256 pixels. Ce tutoriel cible Ubuntu 24.04 LTS sur architecture amd64, avec un extrait régional au format PBF : une approche plus réaliste pour un premier déploiement que l’import de la planète entière.
Sommaire
Quels prérequis prévoir avant d’installer OSM sur Ubuntu 24.04 ?
Un serveur cartographique Ubuntu doit disposer d’Ubuntu 24.04 LTS, d’un compte doté de droits sudo et d’une connexion réseau capable de télécharger les paquets, les données PBF et les ressources du style. Un extrait régional reste le bon périmètre de départ, car l’import et le rendu consomment de la mémoire, du disque et du temps de calcul.
Les ressources nécessaires dépendent fortement de la taille du fichier PBF, des index, du style, du cache et de la fréquentation. Pour un petit extrait régional, contrôlez au préalable la mémoire et l’espace libre ; pour des zones plus grandes, dimensionnez la machine à partir d’un essai d’import sur une copie de l’environnement.
| Élément | Rôle dans le serveur OSM | Contrôle avant installation |
|---|---|---|
| Ubuntu 24.04 LTS amd64 | Système cible du tutoriel | lsb_release -a |
| Mémoire disponible | Import et traitement des données | free -h |
| Espace disque libre | Fichier PBF, base PostGIS, cache de tuiles | df -h / |
| Accès sudo | Installation et gestion des services | sudo -v |
| Connexion Internet | Paquets, style et extrait OSM | ping -c 3 download.geofabrik.de |
- Créez un instantané de la machine virtuelle ou une sauvegarde avant le premier import.
- Choisissez un nom DNS ou une adresse IP stable si la carte doit être utilisée depuis un autre appareil.
- Préservez PostgreSQL sur l’interface locale ; Apache est le composant web à publier.
- Vérifiez la présence d’un swap adapté lorsque la mémoire disponible est limitée.
Un import OSM échoue plus souvent par manque de mémoire, d’espace libre ou de droits cohérents que par absence d’un paquet.
Installation : préparer Ubuntu et installer les dépendances
La préparation du système consiste à mettre à jour Ubuntu, installer les outils cartographiques et installer d’abord renderd. Cette installation crée normalement le compte système _renderd utilisé par le service : ne l’employez pas avant d’avoir contrôlé son existence.
Étape 1 : mettre à jour Ubuntu 24.04 et contrôler l’environnement
sudo apt update && sudo apt upgrade -y
lsb_release -a
locale
Le résultat attendu est une distribution identifiée comme Ubuntu 24.04 LTS et une locale UTF-8 correctement déclarée.
Étape 2 : installer les paquets disponibles dans les dépôts Ubuntu
Ne figez pas les numéros de version PostgreSQL, PostGIS, renderd ou mod_tile : les versions réellement disponibles dépendent des dépôts Ubuntu 24.04 activés sur votre machine. Contrôlez les candidats avant l’installation et n’ajoutez pas de dépôt tiers sans validation.
sudo apt install -y \
ca-certificates \
curl \
wget \
unzip \
bzip2 \
tar \
git \
python3 \
gdal-bin \
mapnik-utils \
nodejs \
npm \
postgresql \
postgis \
osm2pgsql \
renderd \
libapache2-mod-tile \
apache2
apt-cache policy postgresql postgis osm2pgsql renderd libapache2-mod-tile
getent passwd _renderd
id _renderd
Si getent passwd _renderd ne retourne aucun compte, arrêtez-vous : le paquet installé ne fournit pas le même compte ou la même disposition que celle attendue. Consultez alors les fichiers fournis par le paquet avant de créer ou de modifier un compte système.
Comment installer PostgreSQL, PostGIS et osm2pgsql ?
PostgreSQL stocke les données importées, PostGIS ajoute les types et fonctions spatiales, tandis qu’osm2pgsql transforme le fichier PBF en tables exploitables par Mapnik. La commande suivante utilise les paquets proposés par Ubuntu 24.04 plutôt qu’une pile de versions supposées.
Étape 3 : contrôler les outils et créer la base
psql --version
osm2pgsql --version
sudo systemctl is-active postgresql
sudo -u postgres createuser _renderd
sudo -u postgres createdb -E UTF8 -O _renderd gis
sudo -u postgres psql -d gis -c "CREATE EXTENSION postgis;"
sudo -u postgres psql -d gis -c "CREATE EXTENSION hstore;"
sudo -u postgres psql -d gis -c "\dx"
Le résultat attendu est une base nommée gis contenant les extensions PostGIS et hstore. PostgreSQL ne doit pas être exposé publiquement pour permettre à Apache de servir des tuiles.
Importer un fichier PBF régional dans PostGIS
Un fichier PBF est une archive binaire contenant les objets OpenStreetMap d’une zone donnée. Geofabrik publie des extraits régionaux au format .osm.pbf, adaptés à un premier serveur de tuiles.
Étape 4 : récupérer OSM Carto, ses ressources et son script d’import
OSM Carto doit être récupéré avant l’import, car son script Lua définit les tables attendues par le style Mapnik. Le style, les données externes et les polices doivent être préparés explicitement.
sudo install -d -o _renderd -g _renderd -m 0750 /srv/osm
sudo -u _renderd git clone --depth 1 \
https://github.com/gravitystorm/openstreetmap-carto.git \
/srv/osm/carto
sudo npm install --global carto
sudo -u _renderd bash -lc '
cd /srv/osm/carto
scripts/get-fonts.sh
scripts/get-external-data.py
carto project.mml > mapnik.xml
'
sudo -u _renderd test -s /srv/osm/carto/openstreetmap-carto.lua
sudo -u _renderd test -s /srv/osm/carto/mapnik.xml
Avant de continuer, vérifiez les messages des scripts. Selon la révision du projet, les données externes peuvent nécessiter des dépendances supplémentaires documentées par OSM Carto. Ne poursuivez pas avec un fichier mapnik.xml vide ou une récupération de données incomplète.
Étape 5 : télécharger un extrait et lancer osm2pgsql avec le style OSM Carto
Créez un répertoire de données hors du dossier web, puis téléchargez un extrait régional. L’exemple utilise l’Azerbaïdjan ; remplacez l’URL et le nom de fichier par votre zone.
sudo install -d -o _renderd -g _renderd -m 0750 /srv/osm/data
sudo -u _renderd wget -O /srv/osm/data/azerbaijan-latest.osm.pbf \
https://download.geofabrik.de/asia/azerbaijan-latest.osm.pbf
sudo -u _renderd test -s /srv/osm/data/azerbaijan-latest.osm.pbf
Importez ensuite le PBF avec le mode flex et le script de transformation fourni par OSM Carto. Cette association est indispensable : elle génère les tables et colonnes interrogées par le style.
sudo -u _renderd osm2pgsql \
--create \
--database gis \
--username _renderd \
--slim \
--output flex \
--style /srv/osm/carto/openstreetmap-carto.lua \
--number-processes 4 \
--cache 4096 \
/srv/osm/data/azerbaijan-latest.osm.pbf
Adaptez --number-processes et --cache aux ressources réellement disponibles. Ne lancez pas une seconde fois cette commande sur la même base sans comprendre son effet : l’option --create recrée les tables d’import.
sudo -u _renderd psql -d gis -c "\dt"
sudo -u _renderd psql -d gis -c "SELECT count(*) FROM planet_osm_point;"
Configurer Mapnik, OSM Carto, renderd et mod_tile
Mapnik dessine les tuiles à partir des données PostGIS et d’un fichier XML de style. OSM Carto fournit le style, renderd planifie les rendus demandés et mod_tile transmet les requêtes reçues par Apache au service de rendu.
Étape 6 : vérifier la configuration fournie par les paquets
Les chemins de renderd.conf, du socket, des modules Mapnik et du cache dépendent du paquet installé. Ne remplacez pas ces valeurs par une configuration présentée comme universelle : inspectez d’abord les fichiers réellement fournis par Ubuntu 24.04.
dpkg -L renderd | grep -E 'renderd\.conf|systemd|socket'
dpkg -L libapache2-mod-tile | grep -E 'tile|renderd'
sudo systemctl cat renderd
sudo find /etc -maxdepth 2 -name 'renderd.conf' -o -name '*tile*.conf'
Dans le fichier de configuration effectivement utilisé par le service, vérifiez que le style pointe vers /srv/osm/carto/mapnik.xml, que le répertoire de cache est accessible à _renderd et que le socket configuré correspond à celui déclaré dans Apache. Après toute modification, contrôlez la syntaxe et les journaux du service.
sudo install -d -o _renderd -g _renderd -m 0750 /var/lib/mod_tile
sudo -u _renderd test -r /srv/osm/carto/mapnik.xml && echo "XML lisible"
sudo systemctl restart renderd
sudo systemctl status renderd --no-pager
Publier les tuiles avec Apache
Apache reçoit la requête HTTP du navigateur, tandis que mod_tile transmet la demande à renderd via un socket local. Le serveur web publie donc des tuiles sans donner un accès direct à PostgreSQL ni aux fichiers PBF stockés dans /srv/osm/data.
Étape 7 : activer le module et valider le socket utilisé
Activez le module fourni par le paquet. Avant d’écrire une directive de socket, comparez le chemin avec le fichier de configuration réellement livré et avec l’unité systemd de renderd.
sudo a2enmod tile
sudo apachectl configtest
sudo apachectl -M | grep tile
sudo systemctl enable --now renderd
sudo systemctl restart apache2
sudo systemctl is-active renderd
sudo systemctl is-active apache2
Le service renderd et le module Apache doivent être actifs simultanément : Apache seul ne produit aucune tuile. Si Apache ne trouve pas le socket ou si renderd ne démarre pas, consultez les fichiers fournis par les paquets et les journaux avant de modifier les chemins.
sudo journalctl -u renderd -n 100 --no-pager
sudo tail -n 100 /var/log/apache2/error.log
Comment vérifier que le serveur de tuiles OSM fonctionne ?
Le test le plus fiable demande une tuile avec une requête GET, enregistre le fichier et vérifie qu’il s’agit bien d’une image PNG. Une requête HEAD avec curl -I ne teste pas nécessairement le même traitement que la requête GET envoyée par un navigateur.
Étape 8 : demander une tuile PNG et afficher une page de test
curl --fail --silent --show-error \
--output /tmp/osm-test.png \
http://127.0.0.1/hot/0/0/0.png
file /tmp/osm-test.png
python3 - <<'PY'
with open("/tmp/osm-test.png", "rb") as image:
assert image.read(8) == b"\x89PNG\r\n\x1a\n"
print("PNG valide")
PY
Le fichier doit être identifié comme une image PNG et le script doit afficher PNG valide. En cas d’échec, consultez les journaux de renderd et d’Apache avant de modifier la configuration au hasard.
sudo tee /var/www/html/osm-test.html > /dev/null <<'EOF'
<!doctype html>
<html lang="fr">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Test serveur OSM</title>
<link rel="stylesheet" href="https://unpkg.com/[email protected]/dist/leaflet.css">
<style>#map { height: 100vh; }</style>
</head>
<body>
<div id="map"></div>
<script src="https://unpkg.com/[email protected]/dist/leaflet.js"></script>
<script>
const map = L.map('map').setView([40.4093, 49.8671], 7);
L.tileLayer('http://ADRESSE_DU_SERVEUR/hot/{z}/{x}/{y}.png', {
maxZoom: 20,
attribution: '© contributeurs OpenStreetMap'
}).addTo(map);
</script>
</body>
</html>
EOF
Ouvrez ensuite http://ADRESSE_DU_SERVEUR/osm-test.html dans un navigateur. Pour une publication réelle, servez la page et les tuiles en HTTPS et appliquez les règles de pare-feu adaptées à votre infrastructure.
Mettre à jour les données OSM sans tout réimporter
Les données OpenStreetMap évoluent en continu. Un import initial fixe une photographie de la zone au moment du téléchargement ; une mise à jour efficace repose ensuite sur des données différentielles et sur le recalcul des tuiles expirées.
La réplication doit être configurée avec le même mode d’import et le même script flex que l’import initial. Avant toute automatisation, créez une copie de la base, conservez le fichier PBF initial et vérifiez dans la documentation osm2pgsql la procédure de réplication compatible avec votre version et avec openstreetmap-carto.lua. Une synchronisation mal paramétrée peut désaligner la base, les tables d’import et le cache.
- Conservez l’URL exacte, la date de téléchargement et le nom du fichier PBF importé.
- Testez les mises à jour sur une copie de la base
gisavant de les appliquer au service publié. - Surveillez l’espace libre avant chaque mise à jour, car les index et fichiers temporaires peuvent croître.
- Invalidez uniquement les tuiles concernées lorsque votre mécanisme de réplication est validé.
Erreurs fréquentes sur un serveur de tuiles OpenStreetMap
| Symptôme | Cause probable | Contrôle et correction prudente |
|---|---|---|
| osm2pgsql manque de mémoire ou d’espace | RAM, swap ou disque temporaire insuffisant | Contrôlez free -h et df -h, augmentez les ressources ou réduisez la zone importée. |
| renderd ne démarre pas | Chemin XML, socket ou cache incorrect | Utilisez systemctl cat renderd, vérifiez le fichier de configuration utilisé et consultez journalctl -u renderd. |
| Apache ne sert aucune tuile | mod_tile non chargé ou socket différent | Utilisez apachectl -M | grep tile, apachectl configtest et comparez le socket Apache avec celui de renderd. |
| Le fichier téléchargé n’est pas un PNG | Réponse HTTP d’erreur ou rendu inabouti | Exécutez le test GET avec curl --output, puis vérifiez le fichier avec file et les journaux. |
| Erreur d’écriture du cache | Droits incohérents sur le répertoire de cache | Vérifiez propriétaire et mode avec ls -ld /var/lib/mod_tile, sans ouvrir les droits à tous les utilisateurs. |
Bonnes pratiques de sécurité et d’exploitation
Le navigateur doit joindre Apache, mais PostgreSQL, renderd et leur socket local n’ont pas vocation à être exposés sur Internet. Limitez les accès réseau au strict nécessaire, utilisez HTTPS pour les visiteurs et conservez les journaux Apache ainsi que ceux de renderd pendant les phases de réglage.
- Sauvegardez les fichiers de configuration réellement utilisés par renderd et Apache, ainsi que la liste des paquets installés.
- Documentez la révision du style OSM Carto, son script Lua et le fichier PBF associé à chaque import.
- Surveillez l’espace disque du cache, de
/srv/osm/dataet du volume PostgreSQL. - Appliquez les mises à jour système après les avoir testées sur une machine de préproduction.
- Utilisez une authentification SSH robuste et désactivez les comptes inutiles plutôt que d’élargir les droits sur les répertoires.
Sources utiles à consulter
- Switch2OSM — installation manuelle sur Ubuntu 24.04 : séquence de référence pour les composants d’un serveur de tuiles.
- Documentation PostgreSQL : administration de la base, sauvegardes et contrôle des rôles.
- Documentation PostGIS : extension spatiale et fonctions géographiques.
- Documentation osm2pgsql : styles flex, options d’import et mécanismes de mise à jour.
- OpenStreetMap Carto : script d’import, données externes, polices et style Mapnik.
- Geofabrik : extraits régionaux PBF.
Questions fréquentes sur l’installation d’un serveur OSM
Peut-on installer un serveur OSM sur un petit VPS ?
Un petit VPS peut convenir à des essais limités, mais l’import PBF et le rendu demandent rapidement de la mémoire et du stockage. Mesurez les besoins avec un extrait représentatif avant de prévoir une installation durable.
Pourquoi PostgreSQL est-il nécessaire pour héberger des cartes OpenStreetMap ?
PostgreSQL stocke les objets importés depuis le fichier PBF. L’extension PostGIS ajoute les fonctions géographiques dont Mapnik et le style cartographique ont besoin pour produire les tuiles.
Faut-il installer Nominatim ou OSRM pour afficher les tuiles ?
Non. Nominatim sert au géocodage et OSRM au calcul d’itinéraires, alors que ce tutoriel publie des tuiles raster. Ces services peuvent être ajoutés plus tard, sur une installation distincte et dimensionnée pour leurs propres traitements.
Pourquoi la première tuile est-elle plus lente à apparaître ?
La première requête peut déclencher le calcul de la tuile par renderd. Une fois le résultat enregistré dans le cache de mod_tile, la même tuile peut être renvoyée plus rapidement, sous réserve que le cache reste disponible.
Comment savoir si le problème vient d’Apache ou de renderd ?
Commencez par apachectl configtest et apachectl -M | grep tile pour Apache. Consultez ensuite journalctl -u renderd -n 50 et comparez les chemins de socket réellement utilisés par les deux composants.
Avertissement : les noms de paquets, versions, fichiers de configuration et chemins de socket doivent être contrôlés sur l’Ubuntu 24.04 cible avant une mise en production. Rejouez l’ensemble des étapes sur une machine vierge ou un environnement de préproduction, puis adaptez le pare-feu, HTTPS, les sauvegardes et la stratégie de mise à jour à votre infrastructure réelle.