Self-hoster OpenFreeMap : architecture, migration depuis MapTiler et choix face à Martin

Cet article fait suite à Sprites d’icônes MapLibre : intégrer Pinhead dans une carte MapTiler. L’article précédent partait du principe qu’on consommait des tuiles MapTiler ; celui-ci pose la question d’après : comment sortir de MapTiler, soit vers l’instance publique gratuite d’OpenFreeMap, soit vers sa propre infrastructure.

OpenFreeMap est un service d’hébergement de tuiles vectorielles, gratuit, sans clé d’API, sans compte, sans limite de requêtes, et entièrement open-source (licence MIT). Il est l’œuvre de Zsolt Ero (hyperknot), qui faisait tourner MapHub depuis neuf ans avant d’extraire et d’ouvrir son infrastructure de production [Source : Show HN, septembre 2024].

Deux usages coexistent et partagent le même code :

L’instance publique (tiles.openfreemap.org) : on pointe une carte MapLibre dessus et c’est terminé.
L’auto-hébergement : on déploie le même setup sur ses propres serveurs Ubuntu.

Cet article répond à cinq questions concrètes : comment ça marche, quel sous-ensemble d’OSM contient l’instance publique, quelles sont les sources et le schéma (et en quoi ils divergent de MapTiler), comment migrer un style MapTiler, et quand préférer MapLibre Martin. En fil rouge, un cas pratique fréquent — migrer un style outdoor/ski qui réclame du relief et des courbes de niveau — sert à montrer ce qu’OpenFreeMap ne couvre pas et comment le compléter avec des DEM gratuits.

1. Le problème que résout OpenFreeMap

Le marché des fonds de carte vectoriels est dominé par des fournisseurs « open-core » : MapTiler, Mapbox, Stadia Maps, Protomaps. Le schéma de données (OpenMapTiles) et le moteur de rendu (MapLibre GL) sont open-source, mais l’hébergement des tuiles reste payant et soumis à des clés d’API, des quotas de vues mensuelles et des conditions d’utilisation.

OpenFreeMap attaque précisément cette dernière couche. Pas de clé, pas de quota, pas de cookie, pas de tracking — y compris pour un usage commercial, explicitement autorisé [Source : openfreemap.org]. La seule contrepartie est l’attribution (OpenFreeMap, OpenMapTiles, OpenStreetMap), que MapLibre affiche automatiquement.

Le pari économique est ce qui rend la gratuité crédible. Plutôt qu’une tarification au TB façon CDN, OpenFreeMap s’appuie sur la bande passante forfaitaire de Hetzner : autour de 1 €/TB, contre ~90 $/TB sur AWS S3 [Source : Simon Willison]. Trois serveurs dédiés Hetzner, un objectif de financement de ~175 $/mois via dons, et le service tient [Source : Show HN].

2. Comment ça marche : Planetiler → MBTiles → Btrfs → nginx

L’originalité d’OpenFreeMap n’est pas dans le format de tuiles (standard) mais dans la manière de les servir. Le pipeline complet :

┌──────────────┐   ┌───────────────┐   ┌──────────────────┐   ┌─────────┐
│ OpenStreetMap│──▶│  Planetiler   │──▶│  Image Btrfs     │──▶│  nginx  │──▶ MapLibre
│  (planet.osm)│   │ (génère .mbt) │   │ (300 M fichiers, │   │ (statique)│
│ + Natural    │   │  ~5 h / planet│   │  hard-links)     │   │          │
│   Earth, etc.│   └───────────────┘   └──────────────────┘   └─────────┘
└──────────────┘

2.1 Génération : Planetiler

Planetiler (par Mike Barry, onthegomap) génère un planet vectoriel complet au schéma OpenMapTiles en ~5 heures sur une grosse machine, là où l’ancienne chaîne en mettait des jours [Source : Show HN]. La sortie est un fichier MBTiles (une base SQLite contenant toutes les tuiles).

2.2 Stockage : pourquoi Btrfs et pas PMTiles

C’est le cœur de l’astuce. Un planet complet, c’est environ 300 millions de tuiles minuscules (moyenne ~405–450 octets chacune) [Source : Simon Willison]. Trois façons de les servir :

Approche	Mécanisme	Limite
Tile server (Martin, tileserver-gl)	un process lit le MBTiles/PostGIS et répond	overhead applicatif sur chaque requête
PMTiles	un seul gros fichier, requêtes HTTP `Range`	latence des `Range` sur fichiers de 80 Go, surtout sur R2
Btrfs + nginx (OpenFreeMap)	300 M de fichiers sur image Btrfs, servis en statique	dépend du cache disque du kernel

OpenFreeMap convertit le MBTiles en image de partition Btrfs via des scripts maison (extract_mbtiles, shrink_btrfs). Pourquoi Btrfs précisément :

il gère beaucoup mieux les inodes pour des centaines de millions de petits fichiers qu’ext4 ;
les tuiles très petites tiennent directement dans les blocs de métadonnées Btrfs (inline), ce qui économise de l’espace ;
une fois l’image montée, nginx sert chaque tuile comme un fichier statique, et c’est le page cache du kernel Linux qui fait office de cache — pas de service à maintenir [Source : README OpenFreeMap].

Sur le rejet de PMTiles, la FAQ est directe : « faire des requêtes Range dans des fichiers de 80 Go ne fonctionne tout simplement pas en production » avec une latence acceptable ; Brandon Liu (créateur de Protomaps) a lui-même reconnu des soucis de latence des Range sur les gros fichiers via Cloudflare R2 [Source : Show HN]. L’approche statique-sur-serveur contourne entièrement ce goulot.

2.3 Service : nginx en round-robin

L’instance publique tourne avec un serveur de génération et deux serveurs de diffusion, en DNS round-robin, certificats Let’s Encrypt, sans CDN devant [Source : Show HN]. Volontairement « sans Docker » : tout se déploie via des scripts Fabric (SSH) sur Ubuntu propre.

3. Quel sous-ensemble d’OSM contient l’instance publique ?

Réponse courte : le planet entier, sans découpage géographique, du zoom 0 au zoom 14, au schéma OpenMapTiles, régénéré chaque semaine.

Détaillons les dimensions :

Couverture spatiale : monde entier. Aucune extraction par pays ou bbox sur l’instance publique.
Niveaux de zoom : z0 à z14, comme tout tileset OpenMapTiles. Au-delà de z14, MapLibre fait de l’overzoom (réutilisation des tuiles z14 agrandies) — les détails fins du bâti restent lisibles bien au-delà parce que les géométries z14 sont vectorielles.
Couches : les 16 couches du schéma OpenMapTiles (voir §4).
Fraîcheur : un run planet complet est généré et publié chaque semaine, en Btrfs et en MBTiles, sur des buckets Cloudflare R2 publics [Source : README OpenFreeMap].
Historique : pas d’archives. L’auteur assume ce choix : « les données OSM historiques sont généralement moins bonnes sur tous les plans » que le snapshot courant [Source : Show HN].

Ce qu’OpenFreeMap ne fait pas, par conception : géocodage/recherche, calcul d’itinéraire, génération d’images statiques, hébergement raster/satellite, élévation, jeux de données personnalisés [Source : README OpenFreeMap]. C’est un service de tuiles de fond de carte, rien d’autre.

L’instance publique fonctionne en best-effort, sans SLA. Un fair-use implicite existe (rate-limiting ou coupure en cas d’abus manifeste), sans seuil chiffré [Source : Show HN]. Pour une appli en production avec garanties, c’est le signal qu’il faut self-hoster.

4. Sources et schéma : OpenMapTiles, et la divergence MapTiler

4.1 Les sources d’OpenFreeMap

OpenFreeMap agrège quatre sources [Source : README OpenFreeMap] :

OpenStreetMap — la quasi-totalité du contenu (routes, bâtiments, POI, frontières, eau…) ;
Natural Earth — données physiques/culturelles aux bas zooms (océans, pays) pour un rendu propre dès z0 ;
OpenMapTiles — le schéma (la structure des couches) et les outils ;
Wikidata — pour enrichir certains labels multilingues.

4.2 Le schéma OpenMapTiles : 16 couches

Le schéma OpenMapTiles définit 16 source-layer [Source : MapTiler — OpenMapTiles Planet] :

aerodrome_label   boundary    housenumber   mountain_peak   poi               transportation_name   waterway
aeroway           building    landcover     park            place             water
                              landuse                       transportation    water_name

La règle d’or pour styliser : « styliser les routes est la partie la plus essentielle » — la couche transportation (avec son champ class : motorway, trunk, primary…) porte l’essentiel de la lisibilité d’une carte.

4.3 La vraie question : OpenFreeMap a-t-il une couche d’agrégation qui diverge d’OSM, comme MapTiler ?

Non — et c’est précisément ce qui le différencie de MapTiler.

C’est un point souvent mal compris, alors posons-le nettement. MapTiler et OpenFreeMap utilisent le même schéma (OpenMapTiles), mais pas les mêmes données dans ce schéma.

OpenFreeMap remplit le schéma OpenMapTiles avec les attributs OSM bruts (plus Natural Earth aux bas zooms). Les valeurs que vous lisez dans les tuiles correspondent aux tags OSM.

MapTiler, dans son tileset commercial « MapTiler Planet », enrichit le même schéma avec des sources tierces non-OSM [Source : MapTiler — Origine des données] :

Couche	OpenFreeMap	MapTiler Planet
`building`	empreintes OSM uniquement	OSM + Microsoft Building Footprints + Google Open Buildings + Esri Community Maps ; bâtiments GSI au Japon (via Mierune)
`landcover`	OSM (+ Natural Earth bas zoom)	OSM + ESA CCI Landcover (mondial z0–z9), USGS woodland (USA), CanVec (Canada)
glaciers	OSM	OSM + GLIMS
relief / courbes de niveau	absent	tilesets séparés (`contour`, `hillshade`) hors OpenMapTiles

Conséquence concrète : sur OpenFreeMap, une zone mal cartographiée dans OSM (bâti incomplet en Afrique, landcover absent) restera vide, là où MapTiler aura comblé avec ses sources IA/satellite. À l’inverse, OpenFreeMap vous donne une carte qui est OSM, sans couche d’agrégation propriétaire qui s’en écarterait.

Donc, pour reformuler la question de départ : MapTiler a une couche d’agrégation divergente (buildings IA, landcover satellite). OpenFreeMap n’en a pas — c’est de l’OSM dans un schéma OpenMapTiles, point.

5. Migrer un style MapTiler vers OpenFreeMap

Bonne nouvelle de départ : MapTiler et OpenFreeMap parlent le même schéma OpenMapTiles. Les source-layer (transportation, building, poi…) et leurs champs principaux (class, subclass…) sont identiques. Un style MapTiler n’a donc pas à être réécrit couche par couche : il faut surtout rebrancher les trois URLs externes d’un style Mapbox/MapLibre (sources, glyphs, sprite).

5.1 Les trois points de branchement

Voici les URLs réelles servies par OpenFreeMap (extraites du style Liberty) :

{
  "version": 8,
  "sources": {
    "openmaptiles": {
      "type": "vector",
      "url": "https://tiles.openfreemap.org/planet", // ← TileJSON OpenFreeMap
    },
  },
  "glyphs": "https://tiles.openfreemap.org/fonts/{fontstack}/{range}.pbf",
  "sprite": "https://tiles.openfreemap.org/sprites/ofm_f384/ofm",
}

Côté style MapTiler typique, vous aviez :

{
  "sources": {
    "openmaptiles": {
      "type": "vector",
      "url": "https://api.maptiler.com/tiles/v3/tiles.json?key=VOTRE_CLE",
    },
  },
  "glyphs": "https://api.maptiler.com/fonts/{fontstack}/{range}.pbf?key=VOTRE_CLE",
  "sprite": "https://api.maptiler.com/maps/streets/sprite?key=VOTRE_CLE",
}

La migration mécanique consiste à remplacer ces trois valeurs. Le nom de source "openmaptiles" est conventionnellement identique des deux côtés — vos source-layer dans les couches ne changent donc pas.

5.2 Les trois pièges réels

Le remplacement d’URL ne suffit pas toujours. Trois écueils, par ordre de fréquence :

1. Les polices (glyphs). OpenFreeMap ne sert que les fontstacks Noto Sans [Source : openfreemap-styles]. Si vos couches symbol référencent "text-font": ["Open Sans Regular"] ou une police MapTiler spécifique, le glyphe ne se chargera pas. Solution : remplacer les text-font par ["Noto Sans Regular"] / ["Noto Sans Bold"], ou héberger vos propres glyphs.

2. Les sprites (icônes). Le sprite MapTiler et le sprite ofm d’OpenFreeMap n’ont pas les mêmes noms d’icônes. Toute couche POI avec "icon-image": "..." pointant vers un nom MapTiler affichera une icône manquante. C’est exactement le sujet de l’article précédent sur les sprites Pinhead : la solution propre est de générer et héberger votre propre sprite (avec Spreet ou spritezero) et de pointer "sprite" dessus, plutôt que de dépendre du sprite d’un fournisseur.

3. Les attributs absents. Si votre style MapTiler exploitait des champs issus de l’enrichissement MapTiler (voir §4.3) — typiquement des bâtiments présents grâce à Microsoft/Google, ou un landcover mondial dense — ces éléments disparaîtront sur OpenFreeMap là où OSM est creux. Aucune erreur, juste une carte plus vide dans les zones sous-cartographiées. C’est une différence de données, pas de style ; elle ne se corrige pas côté style JSON.

5.3 Le raccourci : partir d’un style OpenFreeMap

Si votre style MapTiler était lui-même un dérivé d’un style OpenMapTiles standard (osm-bright, positron, dark-matter), le plus rapide est souvent de repartir du style OpenFreeMap équivalent déjà câblé, et d’y réappliquer vos personnalisations de couleurs/visibilité. Les cinq styles disponibles :

Style	Origine
Liberty	fork de l’osm-liberty de Maputnik (maintenu en amont)
Bright	fork d’osm-bright-gl-style
Positron	fork de positron-gl-style
Dark	fork de dark-matter-gl-style
Fiord	fork de fiord-color-gl-style

À noter : les styles OpenMapTiles classiques (Bright, Positron, Dark, Fiord) sont abandonnés en amont ; OpenFreeMap les a forkés et les maintient désormais (rendu du texte, frontières administratives, POI) [Source : openfreemap-styles].

5.4 Le code MapLibre final

Pour un style prêt à l’emploi, une seule ligne suffit :

const map = new maplibregl.Map({
  container: "map",
  style: "https://tiles.openfreemap.org/styles/liberty",
  center: [2.35, 48.85],
  zoom: 11,
});

Pour un style personnalisé, on héberge son propre style JSON (Maputnik pour l’éditer) qui pointe vers les URLs OpenFreeMap de §5.1, et on passe l’URL de ce JSON ou l’objet style directement [Source : Quick Start OpenFreeMap].

5.5 Le cas des styles multi-sources (outdoor, ski, relief)

Un style MapTiler « basique » n’a qu’une source vectorielle (openmaptiles). Mais beaucoup de styles thématiques — outdoor, ski, randonnée — en empilent plusieurs, et c’est là que la migration se complique. Exemple d’un style « ski » réel :

"sources": {
  "maptiler_planet": { "url": ".../tiles/v3/...",          "type": "vector" },     // ✅ → OpenFreeMap
  "outdoor":         { "url": ".../tiles/outdoor/...",     "type": "vector" },     // ❌ pistes, sentiers, remontées
  "contours":        { "url": ".../tiles/contours-v2/...", "type": "vector" },     // ❌ courbes de niveau
  "terrain-rgb":     { "url": ".../tiles/terrain-rgb-v2/...", "type": "raster-dem" } // ❌ relief 3D / hillshade
}

Seule maptiler_planet (le fond OpenMapTiles) a un équivalent OpenFreeMap. Les trois autres sources sont des enrichissements propriétaires MapTiler sans équivalent : OpenFreeMap ne fait ni courbes de niveau, ni relief/élévation, ni couches outdoor (pistes, télésièges, sentiers), par conception (§3).

Conséquence : si vous ne rebranchez que maptiler_planet, MapLibre ignore silencieusement les couches dont la source a disparu (pas de crash, mais pistes, courbes et relief absents). Deux issues :

les couches outdoor/relief étaient déjà en visibility: none et inutiles → supprimez ces sources, migrez le fond, c’est terminé ;
vous en avez besoin → il faut reconstruire ces couches vous-même, ce qui est le sujet de la section suivante.

6. Relief, courbes de niveau et terrain : sources gratuites

OpenFreeMap ne fournit ni relief ni courbes de niveau. Si votre style en avait besoin (cas montagne/ski du §5.5), il faut les ajouter à côté. Bonne nouvelle : l’écosystème MapLibre permet de remplacer les deux sources MapTiler (terrain-rgb + contours) par une seule source DEM.

6.1 Un seul DEM, trois rendus

À partir d’une unique source raster-dem, MapLibre produit les trois éléments :

le relief 3D via la propriété terrain du style ;
l’ombrage (hillshade) via la couche native hillshade ;
les courbes de niveau via le plugin maplibre-contour (de Mike Barry, l’auteur de Planetiler), qui génère les isolignes à la volée dans le navigateur depuis ce même DEM, via map.addProtocol. La source contours de MapTiler devient inutile.

On passe ainsi de 4 sources à 2 : OpenFreeMap (fond) + un DEM (relief + courbes).

const map = new maplibregl.Map({
  container: "map",
  style: "https://tiles.openfreemap.org/styles/liberty", // fond OSM
});

// 1. Plugin courbes : enregistre un protocole qui génère les vector tiles côté client
const demSource = new mlcontour.DemSource({
  url: "https://s3.amazonaws.com/elevation-tiles-prod/terrarium/{z}/{x}/{y}.png",
  encoding: "terrarium",
});
demSource.setupMaplibre(maplibregl);

map.on("load", () => {
  // 2. Source DEM unique, réutilisée pour terrain + hillshade
  map.addSource("dem", {
    type: "raster-dem",
    tiles: [
      "https://s3.amazonaws.com/elevation-tiles-prod/terrarium/{z}/{x}/{y}.png",
    ],
    encoding: "terrarium",
    tileSize: 256,
  });
  map.setTerrain({ source: "dem", exaggeration: 1 }); // relief 3D
  map.addLayer({ id: "hillshade", type: "hillshade", source: "dem" }); // ombrage

  // 3. Courbes générées à la volée par le plugin
  map.addSource("contours", {
    type: "vector",
    tiles: [
      demSource.contourProtocolUrl({
        thresholds: { 11: [200, 1000], 13: [50, 200] },
      }),
    ],
  });
  map.addLayer({
    id: "contour-lines",
    type: "line",
    source: "contours",
    "source-layer": "contours",
    paint: { "line-color": "#a08050", "line-width": 1 },
  });
});

6.2 Sources DEM gratuites

Source	Couverture	Accès	Remarque
AWS Terrain Tiles (terrarium)	mondiale	`https://s3.amazonaws.com/elevation-tiles-prod/terrarium/{z}/{x}/{y}.png` — sans clé	Le plus simple. Dataset Mapzen/Joerd. [Registry of Open Data on AWS]
Mapterhorn (Protomaps)	mondiale	PMTiles libre (2025, financé par NLnet/UE)	Reproductible, servable depuis un bucket. [Mapterhorn]
IGN RGE ALTI	France 1 m / 5 m	téléchargement libre (data.gouv / Géoplateforme)	Meilleure qualité pour les Alpes, mais DEM brut à transformer en tuiles soi-même
Copernicus DEM GLO‑30	mondiale 30 m	AWS Open Data	DEM brut de référence Europe, à traiter soi-même

6.3 Quelle précision attendre ?

Point clé : les sources mondiales plafonnent toutes autour de 30 m horizontalement, parce qu’elles reposent sur les mêmes DEM ouverts (SRTM ou Copernicus GLO‑30). Il n’y a pas de miracle de résolution entre elles, MapTiler compris.

Source	DEM de base (mondial)	Résolution horizontale	Zoom max	Précision verticale
AWS Terrain Tiles	SRTM 30 m (+ GMTED bas zooms, ETOPO1 bathymétrie)	~30 m ; patchs régionaux plus fins : USA 10 m, UK 2 m, Norvège 10 m, NZ 8 m, Autriche 10 m, ArcticDEM 5 m	15	terrarium (pas ~0,004 m)
Mapterhorn	Copernicus GLO‑30 (30 m), raffiné en local	~30 m, plus fin là où un modèle local est injecté	12 (global)	terrarium
MapTiler terrain‑RGB v2	composite de DEM, curé par MapTiler	30 × 30 m annoncé	14	formule RGB, pas 0,1 m

Sources : Joerd / tilezen, Mapterhorn, MapTiler Terrain RGB.

Deux nuances qui comptent plus que le tableau :

Zoom max ≠ précision réelle. AWS va jusqu’au z15 (≈ 4,8 m/pixel à l’équateur) et MapTiler au z14, mais la donnée sous‑jacente reste à ~30 m. Au‑delà du z12–z13, ces tuiles sur‑échantillonnent : le rendu est plus lisse, pas plus précis.
Horizontale vs verticale. Le « 0,1 m » de MapTiler est le pas d’encodage (finesse du codage RGB de l’altitude), pas la précision de la mesure. La précision verticale réelle d’un DEM 30 m est de l’ordre de quelques mètres, identique pour les trois.

6.4 France et montagne : IGN RGE ALTI

Aucune des trois sources mondiales n’a de donnée France haute résolution (AWS a UK 2 m et Norvège 10 m, mais pas la France — il retombe sur EUDEM 30 m). Pour un relief net sur un domaine skiable, le seul vrai gain est IGN RGE ALTI, en licence ouverte depuis 2021 :

Source	Résolution sur les Alpes
AWS / Mapterhorn / MapTiler	~30 m
IGN RGE ALTI	1 m / 5 m (6 à 30× plus fin)

Le compromis : RGE ALTI est un DEM brut à transformer soi-même en tuiles. À noter, l’API altimétrique IGN (data.geopf.fr/altimetrie) ne sert que des altitudes ponctuelles (limitée à 5 req/s) — ce n’est pas une source de tuiles [Source : Géoplateforme — altimétrie].

6.5 Pré-générer relief et courbes (qualité, ou IGN)

Si vous partez d’IGN RGE ALTI, ou si vous voulez des courbes pré-calculées plutôt que générées dans le navigateur :

# DEM brut → tuiles terrain (terrarium) avec rio-rgbify
rio rgbify -b -10000 -i 0.1 --base-val -10000 rge_alti.tif terrain.mbtiles

# DEM brut → courbes vectorielles → PMTiles
gdal_contour -a elev -i 10 rge_alti.tif contours.gpkg   # courbes tous les 10 m
tippecanoe -o contours.pmtiles -l contours contours.gpkg

Vous servez ensuite ces fichiers soit en statique (bucket + CDN, comme OpenFreeMap), soit via Martin — exactement le pattern « socle OpenFreeMap + couches métier/relief par Martin » détaillé au §7.

7. OpenFreeMap vs MapLibre Martin

Martin est un serveur de tuiles écrit en Rust, maintenu sous l’organisation MapLibre. Il génère et sert des tuiles vectorielles depuis trois types de sources [Source : README Martin] :

PostGIS : tuiles générées à la volée depuis des tables/fonctions PostgreSQL ;
MBTiles : sert des tuiles pré-générées depuis une archive MBTiles ;
PMTiles : sert des fichiers PMTiles locaux ou distants (HTTP).

Il génère aussi sprites et glyphs à la volée, compose plusieurs sources, et embarque martin-cp pour exporter en MBTiles.

La différence de fond avec OpenFreeMap n’est pas « gratuit vs payant » (les deux sont open-source et gratuits) mais dynamique vs statique :

Martin :        PostGIS ──(requête SQL à la volée)──▶ tuile         ← reflète vos données
OpenFreeMap :   .mbt ──(extract)──▶ Btrfs ──(nginx statique)──▶ tuile  ← reflète OSM hebdo

7.1 Tableau de décision

Critère	OpenFreeMap	Martin
Nature	tuiles OSM pré-générées, servies en statique	serveur générant des tuiles, souvent depuis vos données
Données	OSM mondial, schéma OpenMapTiles, fige hebdo	n’importe quelles données géo (vos tables PostGIS)
Données dynamiques	non (fige hebdomadaire)	oui : un `UPDATE` SQL se voit à la tuile suivante
Setup	scripts Fabric, Ubuntu, 300 Go de disque	binaire Rust + PostGIS à administrer
Charge serveur	quasi nulle (nginx + page cache)	dépend du SQL ; cache à prévoir devant pour le gros trafic
Fond de carte mondial clé en main	oui (instance publique ou self-host)	non — il faut fournir/charger les données
Couches métier (vos polygones)	non	oui, c’est sa raison d’être
Géocodage / routing	non	non (sert des tuiles, pas un moteur de recherche)

7.2 Sur quels critères choisir

La question « OpenFreeMap ou Martin » est souvent un faux dilemme : ils résolvent deux problèmes distincts et se combinent très bien.

Vous voulez juste un beau fond de carte OSM mondial, sans clé MapTiler → OpenFreeMap. Instance publique pour prototyper, self-host pour la prod.
Vous devez afficher vos propres données géo (parcelles, capteurs IoT, zones de livraison) qui changent en temps réel → Martin sur PostGIS, en surcouche d’OpenFreeMap.
Vous voulez servir un extrait OSM régional figé sans dépendre d’un serveur applicatif → OpenFreeMap (extrait par zone) ou Martin servant un PMTiles/MBTiles régional. Si l’absence totale de process applicatif est un objectif (charge, surface d’attaque), OpenFreeMap a l’avantage.
Vous avez déjà du PostGIS et une chaîne de génération → Martin s’intègre naturellement ; martin-cp exporte ensuite en MBTiles si vous voulez basculer en statique.

L’architecture type d’une appli réelle :

┌────────────────────────────┐   fond de carte OSM
│  OpenFreeMap (self-host)    │──────────────┐
└────────────────────────────┘              ▼
                                       ┌───────────┐
┌────────────────────────────┐  vos    │ MapLibre  │
│  Martin + PostGIS           │─données▶│  GL JS    │
└────────────────────────────┘ métier  └───────────┘

OpenFreeMap pour le socle, Martin pour la couche métier vivante. C’est le découpage qui maximise la simplicité de chaque brique.

8. Self-hoster OpenFreeMap, concrètement

8.1 Prérequis

Deux profils de serveur très différents [Source : self_hosting.md] :

Rôle	Disque	RAM	Usage
http-host (recommandé)	300 Go SSD	4 Go	télécharge le run hebdo pré-généré et le sert
tile-gen (avancé)	500 Go SSD	64 Go	régénère soi-même via Planetiler

Le message des docs est sans ambiguïté : générer soi-même les tuiles est « totalement inutile, puisqu’on téléverse les fichiers traités chaque semaine ». 99 % des self-hosters veulent le profil http-host : il télécharge l’image Btrfs prête à l’emploi.

8.2 Déploiement

Le déploiement se fait depuis votre machine via Fabric (SSH) vers un serveur Ubuntu 22+ propre [Source : self_hosting.md] :

# 1. DNS : un enregistrement A pointant tiles.mondomaine.fr vers l'IP du serveur

# 2. Cloner et configurer
git clone https://github.com/hyperknot/openfreemap
cd openfreemap
cp .env.sample .env
# éditer .env : DOMAIN_DIRECT=tiles.mondomaine.fr, LETSENCRYPT_EMAIL=...

# 3. Environnement Python (sur la machine locale)
pip install -r requirements.txt

# 4. Test rapide SANS télécharger le planet (vérifie le setup)
SKIP_PLANET=true ./init-server.py http-host-static tiles.mondomaine.fr

# 5. Déploiement complet (télécharge le planet ~80 Go, déplie en Btrfs ~300 Go)
SKIP_PLANET=false ./init-server.py http-host-static tiles.mondomaine.fr

Le script configure nginx, Let’s Encrypt et l’image Btrfs automatiquement. Sur disque non-SSD, le téléchargement + décompression prend « des heures » [Source : self_hosting.md].

8.3 Mises à jour et fair-use du self-host

Le run pré-généré est publié chaque semaine ; c’est à vous de relancer le déploiement pour rafraîchir vos données. L’auteur prévient : le self-hosting n’est pas un « déploie et oublie » garanti, il faut surveiller les mises à jour [Source : README OpenFreeMap]. Les fichiers bruts (Btrfs et MBTiles) restent téléchargeables directement sur https://btrfs.openfreemap.com/, les styles/fonts/sprites sur https://assets.openfreemap.com/.

9. Synthèse

OpenFreeMap résout un problème, mais entièrement : héberger un fond de carte vectoriel OSM mondial, gratuitement, sans clé, en production. Son architecture (Planetiler → Btrfs → nginx statique) tire sa robustesse de sa simplicité : pas de serveur applicatif, le page cache du kernel comme cache, la bande passante forfaitaire Hetzner comme modèle économique.

Les points à retenir :

Instance publique = planet OSM complet, z0–z14, schéma OpenMapTiles, rafraîchi hebdomadairement, best-effort sans SLA.
Sources = OSM brut + Natural Earth + Wikidata. Contrairement à MapTiler, aucune couche d’agrégation propriétaire (pas de bâtiments IA Microsoft/Google, pas de landcover satellite). Ce qui n’est pas dans OSM n’apparaît pas.
Migration depuis MapTiler = rebrancher sources/glyphs/sprite ; les pièges sont les polices (Noto Sans uniquement), les icônes (hébergez votre sprite) et les données absentes là où OSM est creux. Un style multi-sources (outdoor/ski) ne migre pas tel quel : seul le fond a un équivalent.
Relief et courbes = absents d’OpenFreeMap, mais une seule source DEM suffit à produire relief 3D + hillshade + courbes (via maplibre-contour). Les DEM mondiaux gratuits (AWS Terrarium, Mapterhorn) plafonnent à ~30 m ; pour les Alpes, IGN RGE ALTI 1 m/5 m est le seul vrai gain.
vs Martin = faux dilemme. OpenFreeMap pour le socle OSM statique, Martin pour servir vos propres données dynamiques (ou un relief/des courbes pré-générés) depuis PostGIS/PMTiles. Les deux se superposent dans la même carte MapLibre.

Pour une application de tourisme ou de cartographie métier, le couple idéal est souvent : OpenFreeMap self-hosté pour le fond, Martin/PostGIS pour les données propres, le tout rendu par MapLibre GL — sans une seule clé d’API propriétaire dans la chaîne.

Sources principales : openfreemap.org, README & docs OpenFreeMap (GitHub), openfreemap-styles, Show HN / commentaires de l’auteur, Simon Willison, MapTiler — schéma OpenMapTiles Planet, MapTiler — origine des données Planet, Martin (MapLibre), Planetiler, maplibre-contour, AWS Terrain Tiles, Joerd / tilezen, Mapterhorn, MapTiler Terrain RGB, IGN Géoplateforme — altimétrie.