Extraire des données OpenStreetMap à l'échelle planétaire : outils et performance

Cet article fait suite à Self-hoster OpenFreeMap : architecture, migration depuis MapTiler et choix face à Martin. L’article précédent montrait comment servir un fond de carte vectoriel complet issu de Planetiler ; celui-ci part du problème d’après : que faire quand la donnée dont on a besoin n’est pas dans ce fond de carte, et qu’il faut aller la chercher soi-même dans OpenStreetMap, à l’échelle de la planète.

Les fonds de carte vectoriels prêts à l’emploi — OpenFreeMap, MapTiler Planet, Protomaps — reposent tous sur un schéma figé : OpenMapTiles ou Shortbread. Ce schéma décide quelles étiquettes (tags) OSM finissent dans les tuiles et lesquelles sont jetées. Il est optimisé pour un fond de carte généraliste : routes, bâtiments, POI courants, usage du sol, hydrographie.

Dès qu’on veut une couche que le schéma ignore, on est bloqué. Quelques exemples réels : les lignes électriques (power=line), les via ferrata et voies d’escalade, les fontaines à eau potable, les défibrillateurs (emergency=defibrillator), les relations d’itinéraires de randonnée (route=hiking), le mobilier urbain, les limites administratives fines. Aucun de ces jeux n’existe dans les tuiles standard — soit parce que le tag est trop niche, soit parce qu’il vit dans des relations qu’aucun schéma généraliste ne matérialise.

La seule issue est de reconstituer la chaîne complète soi-même : partir de la donnée brute OSM, extraire précisément ce dont on a besoin, et en faire un jeu de tuiles. À l’échelle d’un pays, c’est trivial. À l’échelle du planet — 87 Go compressés au 1ᵉʳ juillet 2026 [Source : OpenStreetMap Community Forum], plus de 9,3 milliards de nœuds et 1 milliard de chemins [Source : Crunchy Data] — le choix de la chaîne d’outils décide si votre traitement prend 20 minutes ou trois jours.

Cet article passe en revue les outils, étape par étape, avec les chiffres de performance concrets pour chacun, puis propose un arbre de décision.

1. Le pipeline, vue d’ensemble

Toute extraction planet-scale suit la même colonne vertébrale, quels que soient les outils :

┌───────────────┐   ┌──────────────┐   ┌───────────────┐   ┌──────────────┐   ┌─────────┐
│  planet.osm   │──▶│   FILTRER    │──▶│   MODÉLISER   │──▶│   TUILER     │──▶│ SERVIR  │
│  .pbf (87 Go) │   │ (réduire aux │   │ (construire   │   │ (MVT / .pmt  │   │ (statique│
│               │   │  tags voulus)│   │  géométries)  │   │  / .mbtiles) │   │  ou live)│
└───────────────┘   └──────────────┘   └───────────────┘   └──────────────┘   └─────────┘
     source            Osmium            osm2pgsql /         Planetiler /       nginx /
   (Geofabrik,       (tags-filter)        Imposm /           Tilemaker /        Martin /
    planet.osm.org)                       DuckDB             Tippecanoe         tileserver

Deux remarques de méthode avant d’entrer dans le détail :

Filtrer tôt, filtrer fort. Chaque octet écarté à l’étape 1 est un octet que les étapes suivantes n’auront pas à charger, indexer, ou garder en RAM. Réduire un planet de 87 Go à un extrait thématique de quelques centaines de Mo change la nature du problème : un traitement qui exigeait 128 Go de RAM tient sur un laptop.
Deux familles de tuilage. Soit on génère les tuiles directement depuis le PBF (Planetiler, Tilemaker) — pas de base de données intermédiaire, rapide, mais recalcul complet à chaque build. Soit on passe par une base PostGIS (osm2pgsql / Imposm) puis on tuile depuis SQL (Tippecanoe, tilekiln, Martin) — plus lourd à monter, mais requêtable et incrémental. Le choix structure toute la chaîne.

2. Le point de départ : le fichier planet et son format

2.1 PBF, et pas XML

OSM se distribue en deux formats. L’OSM XML (.osm) est lisible mais énorme et lent à parser. Le PBF (Protocolbuffer Binary Format, .osm.pbf) est le format binaire compact, structuré en blocs compressés — c’est le seul format sérieux pour du planet-scale. Tous les outils modernes le lisent nativement. Règle simple : si un outil vous demande du XML pour un traitement volumineux, changez d’outil.

Le PBF encode les objets OSM dans leur modèle natif, qu’il faut comprendre pour saisir les pièges de performance qui suivent :

Nœuds (nodes) : un point avec lat/lon et éventuellement des tags. 9,3 milliards d’entre eux.
Chemins (ways) : une liste ordonnée de références de nœuds. Un chemin ne contient pas de coordonnées — juste des identifiants de nœuds. Pour lui donner une géométrie, il faut résoudre chaque référence contre la table des nœuds.
Relations (relations) : un groupe de membres (nœuds, chemins, ou autres relations) avec des rôles. C’est ainsi que sont modélisés les multipolygones (bâtiments à trous, forêts), les itinéraires, les frontières.

Cette indirection nœud → chemin → relation est la source de complexité. Résoudre les géométries à l’échelle du planet, c’est maintenir un index de 9,3 milliards de nœuds accessible aléatoirement. C’est précisément là que se joue la performance de chaque outil.

2.2 Où récupérer la donnée

Source	Contenu	Quand l’utiliser
planet.osm.org	Planet complet, régénéré chaque semaine	Traitement mondial, source de référence
Geofabrik	Extraits par continent / pays / région, MAJ quotidienne	Périmètre national ou régional
BBBike	Extrait par bbox arbitraire à la demande	Zone urbaine ou emprise custom
AWS Open Data (`s3://osm-pds`, Daylight)	Planet en PBF et en Parquet	Traitement cloud, approche colonne

Point de méthode souvent négligé : si votre zone tient dans un extrait Geofabrik, partez de l’extrait, pas du planet. Filtrer une bbox de Munich depuis le fichier Allemagne prend 4,5 minutes ; depuis le planet complet, 21 minutes — pour un résultat identique [Source : osmium-tool issue #214]. Le planet ne se justifie que si votre extraction est réellement mondiale ou couvre de multiples pays sans découpage Geofabrik pratique.

Les fichiers Geofabrik sont du PBF pur, non filtré : toute la donnée et toutes les métadonnées de la région, sans l’historique [Source : Geofabrik]. C’est le même contenu que le planet, restreint géographiquement — donc tous les outils ci-dessous s’y appliquent à l’identique.

3. La distinction fondamentale : requête vs traitement en masse

Avant les outils, une clarification qui évite l’erreur la plus coûteuse.

L’Overpass API n’est pas un outil d’extraction en masse. C’est un moteur de requête pour récupérer une sélection de données sur une zone limitée : « toutes les pharmacies dans ce quartier », « ce relation par son id ». Ses quotas le rendent inutilisable pour du planet-scale :

Timeout par défaut de 180 secondes, extensible à 900 secondes maximum.
Volume de téléchargement recommandé sous 1 Go par jour, ~10 000 requêtes/jour maximum.

Source : Overpass API — OpenStreetMap Wiki.

La documentation officielle est explicite : « quand vous voulez extraire des régions de la taille d’un pays avec toute (ou presque) la donnée, il vaut mieux utiliser un miroir planet.osm. L’Overpass API est surtout utile quand la quantité de donnée nécessaire n’est qu’une sélection de ce qui est disponible » [Source : OpenStreetMap Wiki].

Autrement dit : Overpass sert à explorer et à prototyper une requête de tags sur une petite zone. Une fois que vous savez quels tags vous voulez, l’extraction planet-scale se fait sur un fichier PBF local avec les outils qui suivent. Utiliser Overpass pour aspirer le planet vous fera bannir avant d’avoir fini.

4. Filtrer et découper : la famille Osmium

Osmium (le CLI osmium, adossé à la bibliothèque C++ libosmium) est l’outil de référence pour manipuler des fichiers OSM. C’est le couteau suisse de l’étape 1 : filtrer, découper, convertir, fusionner, inspecter. Il lit et écrit le PBF nativement et fait tout son travail en streaming.

4.1 `osmium tags-filter` : réduire par étiquettes

C’est la commande centrale de ce cas d’usage. Elle ne garde que les objets portant les tags voulus :

# Ne garder que les lignes électriques et sous-stations, mondialement
osmium tags-filter planet.osm.pbf \
  nwr/power=line nwr/power=substation \
  -o power.osm.pbf

La syntaxe nwr/ précise le type d’objet ciblé : n (node), w (way), r (relation), combinables. nwr/power matche tout objet ayant une clé power, quelle que soit la valeur.

Le piège central : les objets référencés. Par défaut, tags-filter ajoute automatiquement au résultat tous les objets référencés par les objets matchés — c’est-à-dire les nœuds composant un chemin power=line, sans quoi ce chemin serait sans géométrie [Source : osmium-tags-filter manual]. C’est ce qu’on veut presque toujours. Pour maintenir la table des identifiants nécessaires, Osmium ne garde en mémoire que des listes d’IDs, pas les objets eux-mêmes — d’où une empreinte RAM modeste même sur le planet [Source : osmium-tags-filter manual]. L’option --omit-referenced/-R désactive ce comportement (aucun ID gardé en RAM), utile si vous ne voulez que les tags sans les géométries.

4.2 `osmium extract` : découper par géographie

Pour restreindre par emprise plutôt que par tag :

# Découper une bbox (lon_min, lat_min, lon_max, lat_max)
osmium extract -b 5.9,45.5,7.2,46.4 planet.osm.pbf -o alpes.osm.pbf

# Ou selon un polygone (GeoJSON / .poly)
osmium extract -p perimetre.geojson planet.osm.pbf -o zone.osm.pbf

4.3 Performance

Osmium est essentiellement lié au débit disque (I/O-bound) : son travail dominant est de lire séquentiellement le fichier PBF et de le décompresser. Un filtrage complet du planet se compte en dizaines de minutes sur une machine avec un SSD correct — historiquement ~40 minutes sur un laptop, aujourd’hui nettement moins sur du NVMe [Source : Florian Ledermann, Osmium]. À comparer aux 21 minutes mesurées pour un extract géographique depuis le planet [Source : osmium-tool issue #214].

En pratique, l’étape de filtrage Osmium est rarement le goulot de la chaîne. C’est l’étape la moins coûteuse, et elle allège tout ce qui suit. Chaînez agressivement : un tags-filter puis un extract géographique produit un fichier de quelques dizaines de Mo sur lequel les outils de tuilage tournent en minutes au lieu d’heures.

4.4 Les ancêtres : Osmosis et osmctools

Deux familles plus anciennes traînent encore dans les tutoriels :

Osmosis (Java) : le vétéran, très complet (pipelines de tâches chaînées), mais lent et gourmand en RAM comparé à Osmium. Reste utile pour la gestion des diffs de réplication (mises à jour incrémentales).
osmctools (osmconvert, osmfilter) : rapides et scriptables, mais utilisent un format intermédiaire .o5m et sont moins maintenus.

Pour tout nouveau projet, Osmium est le choix par défaut : plus rapide, mieux maintenu, PBF natif. Ne revenez à Osmosis que pour la réplication de diffs si votre chaîne l’exige.

5. Charger en base : l’approche PostGIS

Si votre besoin dépasse le filtrage — jointures, requêtes spatiales, mises à jour incrémentales, ou tuilage dynamique — il faut une base de données. Deux outils importent OSM dans PostgreSQL/PostGIS.

5.1 osm2pgsql

osm2pgsql est l’importateur historique, celui qui alimente le rendu « standard » d’openstreetmap.org. La version 2.x (2.3.0 sortie le 10 juin 2026) a modernisé l’outil autour du flex output [Source : osm2pgsql releases].

Le mode flex est ce qui rend osm2pgsql pertinent pour de la donnée custom. Au lieu d’un schéma figé, vous écrivez un script Lua qui décide, objet par objet, dans quelle table il atterrit et avec quelles colonnes :

-- extrait de config flex : une table dédiée aux lignes électriques
local power = osm2pgsql.define_way_table('power_lines', {
    { column = 'voltage', type = 'text' },
    { column = 'geom', type = 'linestring', not_null = true },
})

function osm2pgsql.process_way(object)
    if object.tags.power == 'line' then
        power:insert({
            voltage = object.tags.voltage,
            geom = object:as_linestring(),
        })
    end
end

Source : osm2pgsql flex output manual.

Le paramètre qui décide de tout : --flat-nodes. Souvenez-vous du problème de l’indirection nœud → chemin. osm2pgsql doit stocker la position des 9,3 milliards de nœuds pour reconstruire les géométries. Deux options :

Dans PostgreSQL : ~100 Go, et lent.
Dans un fichier plat dédié (--flat-nodes) : ~20 Go, et bien plus rapide.

Pour un import planet, le fichier flat-nodes avec -C 0 (cache mémoire désactivé) est recommandé [Source : osm2pgsql FAQ].

Performance planet. Le benchmark de référence de Crunchy Data (2024) donne l’état de l’art :

Métrique	Valeur
Temps total d’import	3 h 39
Dont lecture du PBF	2 h 11
Dont traitement	1 h 29
Débit nœuds	19 053 k/s
Débit chemins	243 k/s
Débit relations	4 k/s
Taille finale de la base	~750 Go
Matériel	AMD 9600X, 128 Go RAM, SSD
PostgreSQL	17 (v17 ≈ 2× plus rapide que v14–16)

Source : Crunchy Data — Loading the World.

Retenez les ordres de grandeur : 64 Go de RAM est le minimum pour un import planet, 128 Go est confortable [Source : osm2pgsql FAQ]. Et la version de PostgreSQL compte autant que le matériel.

Générer des tuiles depuis osm2pgsql. La v2 introduit osm2pgsql-gen, un programme de généralisation piloté par la même config Lua, qui pré-calcule des versions simplifiées pour les zooms faibles et peut produire des tables indexées par tuile (ids = tile, colonnes x/y automatiques) [Source : osm2pgsql v2 manual — generalization]. Combiné à un serveur comme tilekiln (génère du MVT depuis PostGIS via des requêtes SQL), on obtient une chaîne PostGIS → tuiles complète et maintenable.

5.2 Imposm

Imposm (v3, écrit en Go) attaque le même problème avec un parti pris différent : la vitesse d’import et un mapping déclaratif en YAML plutôt qu’en Lua. Les benchmarks publics le donnent au moins 3× plus rapide qu’osm2pgsql à l’import — pour la Pologne, ~15 minutes contre ~45 minutes [Source : Compare imposm with osm2pgsql — issue #30].

Le compromis : Imposm est optimisé pour un workflow import → tuiles, avec un modèle de mise à jour par diffs propre, mais son mapping YAML est moins expressif que le Lua d’osm2pgsql pour les transformations complexes. Imposm alimente d’ailleurs historiquement la chaîne OSM2VectorTiles / OpenMapTiles.

5.3 osm2pgsql vs Imposm

Aspect	osm2pgsql (flex)	Imposm 3
Langage	C++	Go
Config	Lua (très expressif)	YAML (déclaratif)
Vitesse d’import	Référence	~3× plus rapide
Mises à jour	Réplication (diffs)	Diffs, avec table de production/backup
Généralisation	`osm2pgsql-gen` intégré (v2)	Externe
Écosystème	Rendu OSM standard, tilekiln	OpenMapTiles, tegola

Reco : Imposm si vous voulez surtout de la vitesse et un pipeline import→tuiles classique. osm2pgsql (flex) si vous avez besoin de logique de transformation fine, de généralisation intégrée, ou de coller au standard OSM.

6. L’approche colonne : DuckDB, GeoParquet et Overture

Une troisième voie a émergé et bouscule les deux précédentes pour l’analytique et l’extraction ponctuelle : traiter OSM comme de la donnée colonne (Parquet) plutôt que comme une base spatiale ou un fichier à streamer.

6.1 DuckDB + QuackOSM

DuckDB, via son extension spatial et la fonction ST_ReadOSM, lit directement un PBF. Par-dessus, QuackOSM (Python/CLI) construit les géométries (points, lignes, polygones) à partir des données brutes et sort du GeoParquet prêt pour l’analytique [Source : QuackOSM].

Les atouts par rapport à GDAL/ogr2ogr sur le même terrain :

Multithreadé (GDAL sur OSM est mono-thread), avec réduction automatique du nombre de cœurs si la RAM manque.
Filtrage par tags et par géométrie sans passer par un ogr2ogr de découpage préalable.
Cache des calculs répétés.

Source : QuackOSM.

Limite à connaître : le parsing complet sans filtre demande au moins 10× la taille du PBF en espace disque libre (un fichier de 100 Mo → 1 Go de scratch) [Source : QuackOSM]. QuackOSM « avale » un pays entier comme la France sur un PC grand public, mais le planet complet en un seul passage reste une opération lourde qui exige de la place.

6.2 Le planet déjà en Parquet : Overture et Daylight

Plutôt que de convertir le PBF soi-même, on peut consommer un planet déjà en GeoParquet :

Daylight (s3://daylight-openstreetmap/) : un instantané OSM en Parquet, sans authentification.
Overture Maps (s3://overturemaps-us-west-2/) : la fondation Overture (Meta, Microsoft, AWS, TomTom) publie des releases mensuelles en GeoParquet, dont une large part dérive d’OSM, avec un schéma normalisé et un identifiant stable (GERS).

Source : Overture Maps — DuckDB.

L’intérêt décisif est le partitionnement spatial du GeoParquet couplé aux requêtes HTTP Range : DuckDB lit directement depuis S3 et ne télécharge que les colonnes et les tuiles Parquet couvrant votre bbox [Source : Overture Maps — DuckDB]. On requête « la planète » depuis un laptop sans jamais rapatrier 87 Go :

-- Extraire tous les cours d'eau d'une bbox, directement depuis S3
INSTALL spatial; LOAD spatial;
COPY (
  SELECT * FROM read_parquet('s3://overturemaps-us-west-2/release/.../*.parquet')
  WHERE bbox.xmin BETWEEN 5.9 AND 7.2
    AND bbox.ymin BETWEEN 45.5 AND 46.4
) TO 'rivieres.parquet' (FORMAT parquet);

Quand c’est le bon choix — et quand non. L’approche colonne est excellente pour l’extraction analytique, ponctuelle, cloud-native, et quand un schéma normalisé Overture vous suffit. Elle l’est moins quand vous avez besoin de tags OSM bruts très spécifiques absents de la normalisation Overture, ou d’un pipeline de tuilage clé en main : dans ces cas, on revient au PBF + Planetiler/Tilemaker.

7. Générer les tuiles

Une fois la donnée filtrée (et éventuellement en base), il faut produire des tuiles vectorielles au format MVT (Mapbox Vector Tiles), empaquetées en .mbtiles (SQLite) ou .pmtiles (fichier unique optimisé pour le Range HTTP). Deux familles, selon d’où l’on part.

7.1 Depuis le PBF directement

C’est la voie la plus rapide quand la donnée est stable et qu’on rebuild périodiquement.

Planetiler (Java, par Mike Barry / onthegomap) génère un planet vectoriel complet en quelques heures sur une seule machine ; il exige un minimum de 32 Go de RAM et tourne confortablement avec 64 Go [Source : Planetiler]. Son benchmark de référence tourne sur un droplet à 16 CPU / 128 Go / 1,17 To de disque [Source : Planetiler PLANET.md].

Pour de la donnée custom, deux voies :

Profil Java : implémenter l’interface de profil pour un contrôle total. Depuis la v0.8, on écrit un profil custom sans outils de build [Source : Planetiler].
Config YAML : le format déclaratif planetiler-openmaptiles / custom schema permet de créer un schéma custom sans écrire de Java — l’option à privilégier pour ajouter quelques couches thématiques.

Repère de coût : ajouter la fusion des bâtiments au zoom 13 dans le profil OpenMapTiles ajoute ~14 CPU-heures (~50 min sur 16 cœurs) au build planet [Source : Planetiler PLANET.md]. Planetiler parallélise sur tous les cœurs : plus vous en avez, plus c’est rapide.

Tilemaker (C++, par Richard Fairhurst / systemed) est l’alternative, avec un schéma défini en Lua — souvent perçu comme plus accessible que le Java de Planetiler pour un schéma custom. Sa v3.0 a transformé son profil de performance :

Version	RAM (planet)	Temps (planet)
Tilemaker 2.0	130 Go	37 h
Tilemaker 3.0	24 Go	4,5 h (même matériel)
Tilemaker 3.0, matériel moderne	—	< 90 min

Source : Tilemaker 3.0 — OpenStreetMap Community.

Tilemaker scale bien vers le bas : 16 Go de RAM suffisent pour générer le planet, lentement [Source : Tilemaker discussion #593]. C’est un argument fort pour les régies modestes.

Planetiler vs Tilemaker. Les deux visent le même but. Planetiler est le plus rapide et le mieux documenté pour le planet complet ; son API Java donne le contrôle le plus fin. Tilemaker, avec son schéma Lua et son excellente montée/descente en charge RAM, est souvent plus agréable pour un schéma custom sur des extraits régionaux ou sur du matériel modeste. Pour « ajouter une couche niche au planet », les deux conviennent — commencez par celui dont vous préférez le langage de config.

7.2 Depuis PostGIS / GeoJSON

Si vous êtes déjà passé par une base (section 5), ou si votre donnée est en GeoJSON :

Tippecanoe (par Mapbox, désormais maintenu par Felt) construit des tuiles vectorielles depuis de gros volumes de features GeoJSON. C’est l’outil de référence pour tuiler de la donnée qui n’est pas un fond de carte généraliste : semis de points, tracés, jeux thématiques. Il gère intelligemment la densité — il abandonne une fraction des points aux zooms faibles pour éviter des tuiles obèses, comportement ajustable (-r1 pour tout garder sur les petits jeux) [Source : Tippecanoe].

Attention à la performance : sur des géométries complexes, Tippecanoe peut être lent, et surtout on veut éviter de matérialiser un GeoJSON de plusieurs Go sur disque. La bonne pratique est de piper directement PostGIS → Tippecanoe :

# Streamer du GeoJSON depuis PostGIS vers Tippecanoe, sans fichier intermédiaire
psql -d osm -c "COPY (SELECT ST_AsGeoJSON(t.*) FROM power_lines t) TO STDOUT" \
  | tippecanoe -o power.mbtiles -l power -Z4 -z14

Serveurs de tuiles dynamiques. Alternative au pré-calcul : générer les tuiles à la volée depuis PostGIS. Martin (Rust, écosystème MapLibre) et tegola (Go) exposent PostGIS en MVT à la demande. Idéal pour de la donnée qui change souvent (pas de rebuild), au prix d’un process applicatif sur le chemin de chaque requête — le compromis exact discuté dans l’article OpenFreeMap à propos de Btrfs+nginx vs Martin.

8. Performance de bout en bout

Ordres de grandeur pour un traitement mondial, sur une machine sérieuse (16+ cœurs, 64–128 Go RAM, NVMe). À diviser par un grand facteur si vous filtrez d’abord à un extrait thématique.

Étape	Outil	Temps (planet)	RAM	Goulot
Filtrer par tags	`osmium tags-filter`	dizaines de min	faible (IDs seuls)	Disque (I/O)
Découper une bbox	`osmium extract`	~20 min	faible	Disque (I/O)
Import PostGIS	osm2pgsql (flat-nodes)	~3 h 40	64–128 Go	RAM + disque
Import PostGIS	Imposm 3	~3× plus rapide	élevée	Disque
Extraction colonne	DuckDB / QuackOSM	variable	s’adapte à la RAM	CPU + disque (10×)
Tuiles depuis PBF	Planetiler	quelques h	32–64 Go min	CPU
Tuiles depuis PBF	Tilemaker 3.0	1,5–4,5 h	16–24 Go	CPU + RAM
Tuiles depuis GeoJSON	Tippecanoe	dépend du volume	modérée	CPU

Sources : sections 4 à 7 ci-dessus.

La leçon transversale : le goulot se déplace selon la chaîne. Filtrage Osmium → disque. Import PostGIS → RAM (les positions de nœuds). Tuilage → CPU (calcul de géométries et simplification). Optimisez le maillon qui saigne, pas les autres. Et rappelez-vous que filtrer tôt rend tous les maillons suivants dérisoires : un extrait power=* mondial pèse quelques centaines de Mo, et Planetiler ou Tilemaker le tuilent en minutes, pas en heures.

9. Choisir sa chaîne : arbre de décision

Votre donnée est-elle dans un fond standard (OpenMapTiles / Shortbread) ?
│
├─ OUI ──▶ Utilisez OpenFreeMap / Planetiler basemap. Fin. (cf. article précédent)
│
└─ NON ──▶ Quel est le besoin ?
           │
           ├─ Exploration / prototypage de la requête de tags
           │     └─▶ Overpass API (petite zone) pour valider quels tags extraire
           │
           ├─ Extraction ponctuelle, analytique, cloud
           │     └─▶ DuckDB + QuackOSM, ou Overture/Daylight en GeoParquet sur S3
           │
           ├─ Jeu de tuiles thématique, donnée stable, rebuild périodique
           │     └─▶ osmium tags-filter  ─▶  Planetiler (YAML) ou Tilemaker (Lua)
           │
           ├─ Besoin de requêtes SQL / jointures / généralisation
           │     └─▶ osm2pgsql flex (ou Imposm si vitesse prime)  ─▶  tilekiln / Tippecanoe
           │
           └─ Donnée qui change souvent, tuiles à la volée
                 └─▶ Imposm/osm2pgsql  ─▶  Martin / tegola (MVT dynamique)

La chaîne la plus courante pour « une couche niche à l’échelle planète » est la troisième : osmium tags-filter → Planetiler ou Tilemaker. Pas de base de données, un extrait léger, un tuilage en minutes, un .pmtiles servi en statique. C’est simple, rapide, reproductible, et ça se rebuild dans un cron hebdomadaire aligné sur le planet.

10. Pièges et limitations connues

La résolution des géométries est le vrai coût

Répétons-le parce que c’est LA source de surprises : un chemin OSM ne contient pas de coordonnées, seulement des références de nœuds. Tout outil qui doit produire des géométries doit maintenir un index de 9,3 milliards de nœuds. C’est pourquoi --flat-nodes existe dans osm2pgsql, pourquoi Planetiler exige 32 Go de RAM, et pourquoi un simple tags-filter (qui, lui, ne calcule pas de géométrie) est si léger. Si un outil « rame » sur le planet, c’est presque toujours ici.

Les relations et multipolygones

Les bâtiments à trous, forêts, frontières et itinéraires sont des relations. Un tags-filter sur r/route=hiking récupère la relation et ses membres, mais assembler la géométrie (recoller les segments en ligne continue, gérer les trous d’un multipolygone) est un travail à part que font Planetiler, Tilemaker et osm2pgsql — pas Osmium seul. Si votre couche repose sur des relations, prévoyez un outil de tuilage qui sait les assembler, et testez les cas tordus (relations avec membres manquants, rôles incohérents).

La RAM est un mur, pas une pente

En dessous du minimum d’un outil (32 Go pour Planetiler, 64 Go pour osm2pgsql planet), ça ne ralentit pas : ça échoue ou ça swap à mort. Vérifiez le minimum documenté avant de lancer un build de plusieurs heures. Le contre-exemple vertueux est Tilemaker, conçu pour descendre jusqu’à 16 Go [Source : Tilemaker discussion #593].

Les mises à jour : rebuild vs diffs

OSM publie des diffs de réplication (minutely/hourly/daily). Deux stratégies :

Rebuild complet périodique (Planetiler/Tilemaker depuis un PBF frais) : simple, idempotent, mais recalcule tout. Adapté à une donnée niche et à une fréquence hebdomadaire.
Application de diffs (osm2pgsql --append, Imposm, Osmosis) : incrémental, mais la plomberie d’état est plus délicate (garder le flat-nodes cohérent, gérer les suppressions).

Pour un jeu de tuiles thématique, le rebuild complet est presque toujours le bon choix : plus robuste, et sur un extrait filtré il coûte quelques minutes.

L’espace disque scratch

DuckDB/QuackOSM demandent ~10× la taille du fichier en scratch [Source : QuackOSM] ; osm2pgsql planet produit une base de ~750 Go [Source : Crunchy Data]. Provisionnez le disque temporaire, pas seulement le disque final — un build qui meurt à 90 % faute d’espace scratch est une perte sèche de plusieurs heures.

11. Conclusion

Extraire une donnée absente des fonds standard, à l’échelle du planet, n’est pas un problème monolithique : c’est un pipeline filtrer → modéliser → tuiler, et chaque étape a son outil et son goulot.

Les trois repères à garder :

Filtrez tôt avec Osmium. tags-filter transforme un problème planet-scale (87 Go, 128 Go de RAM) en un problème d’extrait thématique (quelques centaines de Mo, un laptop). C’est le plus grand levier de performance de toute la chaîne, et le moins cher.
Choisissez la voie de tuilage selon la stabilité de la donnée. Donnée stable, rebuild périodique → Planetiler ou Tilemaker directement depuis le PBF, sans base. Donnée requêtable ou changeante → PostGIS (osm2pgsql flex / Imposm) puis Tippecanoe, tilekiln, ou un serveur dynamique Martin/tegola.
La RAM et le disque scratch sont des murs. Respectez les minimums documentés avant de lancer un build de plusieurs heures. Tilemaker 3.0 est le meilleur candidat pour du matériel modeste ; l’approche DuckDB/GeoParquet, pour du cloud-native sans infra lourde.

Pour la couche niche typique — lignes électriques, itinéraires, mobilier — la chaîne gagnante tient en une ligne : osmium tags-filter → Tilemaker/Planetiler → .pmtiles servi en statique, rebuild hebdomadaire aligné sur le planet. Le reste de l’arsenal (PostGIS, DuckDB, serveurs dynamiques) ne se justifie que quand un besoin précis — SQL, analytique, fraîcheur temps réel — l’exige.