Data Géospatiale

🗺️ Overture vs OSM
Le Framework de Décision 2026

Le guide opérationnel que les Big Tech ne veulent pas que vous lisiez avant de migrer votre stack géospatiale.

⏱ Temps de lecture : 12 min 📊 Niveau : intermédiaire à avancé 📅 Mis à jour le 18 mai 2026

Pour qui ? Data engineers, GIS analysts, CTO, freelances géospatiaux qui doivent choisir (ou défendre) une stack data en 2026.

🎯 Ce que ce guide vous apporte

  1. Un framework de décision en 4 questions pour trancher Overture / OSM / hybride sur n'importe quel projet
  2. 3 cas d'usage opérationnels documentés par secteur (tech, agency, coaching)
  3. Des templates SQL DuckDB prêts à coller pour les 2 stacks
  4. La vérité chiffrée sur GERS — au-delà du marketing et au-delà des polémiques

Part 1 — Le Framework

🌍 Le contexte : une fracture à 300 000 $ l'année

Le 9 février 2026, l'Open Geospatial Consortium (OGC) a ouvert la consultation publique pour faire de GERS — le Global Entity Reference System d'Overture Maps Foundation — un standard communautaire international.

Sur le papier, c'est une avancée. GERS attribue des identifiants persistants 128-bit à chaque entité géospatiale (bâtiments, routes, POI) pour éliminer la fameuse "conflation tax" — ces semaines passées à matcher manuellement des datasets qui décrivent la même réalité avec des schémas différents.

Dans la pratique, c'est une fracture politique majeure. La Linux Foundation héberge Overture, mais le steering committee n'est accessible qu'aux entreprises ayant souscrit à un Silver Membership Linux Foundation dont les tarifs s'échelonnent jusqu'à 300 000 $/an pour les grandes entreprises, et 3 millions $/an + 20 employés contributeurs au niveau le plus élevé. Les fondateurs : AWS, Meta, Microsoft, TomTom.

💡 Insight #1 — Le chiffre qui fait mal
40 % des records d'Overture viennent d'OpenStreetMap (Marc Prioleau, Executive Director Overture, State of the Map US). Combien de contributeurs OSM bénévoles sont représentés au steering committee ? Zéro.

📊 Les 3 erreurs que tout le monde fait

Erreur #1 : Penser qu'il faut "choisir entre OSM et Overture"

C'est le faux dilemme parfait. OSM est une base de données vivante (édition continue par des bénévoles), tandis qu'Overture est un snapshot mensuel issu de l'agrégation de ~200 sources, dont OSM lui-même. Les utiliser ensemble n'est pas une trahison — c'est la stack pragmatique de 2026.

Erreur #2 : Adopter GERS comme clé primaire persistante

Lisez bien la doc Overture : "Overture maintains open-source matching and conflation libraries to ensure that the ID remains stable across releases." Le mot clé est "ensure" — un objectif, pas une garantie. Le churn d'IDs sur le thème Places a atteint ~20 % entre certaines releases (rapporté par la communauté OSM sur le forum officiel). Si vous joignez vos données critiques à un GERS ID en clé primaire dure, vous reconstruisez un pipeline de réconciliation tous les 6 mois.

Erreur #3 : Confondre "open data" et "open governance"

La licence CDLA Permissive v2 d'Overture est techniquement permissive. Mais la licence ne dit rien de qui décide du schéma, du roadmap, ou de l'inclusion d'une source. Quand Microsoft pousse un dataset Buildings ML-derived sans validation locale, vous n'avez ni véto ni recours. Avec OSM, chaque feature a un historique d'édition, un contributeur identifié, et une discussion publique sur le forum.

🔄 Le changement de paradigme

Avant 2024Après 2026
Choisir UNE source de donnéesOrchestrer PLUSIEURS sources via identifiants partagés
Combinaison adaptée à chaque projet (semaines de boulot)Agrégation et cohérence déléguée à Overture + bridge files
OSM vs Google Maps vs HERE = guerre commercialeOverture vs OSM = guerre de gouvernance
L'analyste pousse des boutons SIGL'analyste choisit, audite et combine des sources

💡 Insight #2 — La règle d'or
Vos données changent souvent (édition transactionnelle, mises à jour locales, contributions terrain) → OSM. Vous analysez des snapshots stables à l'échelle planétaire (logistics, AI grounding, BI) → Overture. Vous voulez les deux ? Bridge files.


Part 2 — La Méthode

🧭 Le framework de décision en 4 questions

Posez-vous ces 4 questions dans l'ordre. La première à laquelle vous répondez "non" détermine votre stack.

Question 1

Avez-vous besoin de mises à jour < 24 h ?

Question 2

Travaillez-vous à l'échelle continentale ou planétaire ?

Question 3

Devez-vous joindre 3+ datasets tiers (Meta Places, Microsoft Buildings, données gouvernementales) ?

Question 4

Êtes-vous prêt à reconstruire vos joins tous les 6 mois ?

📋 Tableau comparatif opérationnel

Critère OSM seul Overture seul OSM + Overture (bridge files)
Coût d'ingestion (1 pays) 2–4 h 4–8 h 8–16 h
Latence des updates Minutes ~30 jours Mixte
Couverture POI/Places Hétérogène Plus dense Maximale
Stabilité IDs sur 12 mois 99 %+ (OSM IDs) 80 % (GERS Places) 99 % avec stratégie hybride
Licence sortie ODbL (share-alike) CDLA Permissive (sauf themes OSM-derived → ODbL) Mixte à clarifier par theme
Gouvernance Décentralisée, OSMF Linux Foundation, steering Big Tech Composite
Stack technique PostGIS, Overpass DuckDB, GeoParquet, S3 DuckDB + extension osm

🛠️ Process pas-à-pas : intégrer Overture + OSM en hybride

Étape 1 — Récupérer Overture par bounding box (DuckDB)

-- Installation des extensions DuckDB
INSTALL spatial;
INSTALL httpfs;
LOAD spatial;
LOAD httpfs;

-- Récupérer les bâtiments Overture pour la région parisienne
COPY (
  SELECT
    id AS gers_id,
    geometry,
    sources,
    height,
    num_floors,
    class
  FROM read_parquet(
    's3://overturemaps-us-west-2/release/2026-04-15.0/theme=buildings/type=building/*',
    hive_partitioning=1
  )
  WHERE bbox.xmin >= 2.22 AND bbox.xmax <= 2.47
    AND bbox.ymin >= 48.81 AND bbox.ymax <= 48.91
) TO 'paris_buildings_overture.parquet' (FORMAT 'parquet');

Étape 2 — Récupérer les bridge files Overture → OSM

-- Bridge file Overture → OSM pour le thème buildings
CREATE TABLE bridge_osm AS
SELECT
  gers_id,
  source_id AS osm_id,
  source_type
FROM read_parquet(
  's3://overturemaps-us-west-2/bridgefiles/2026-04-15.0/dataset=OpenStreetMap/theme=buildings/type=building/*'
);

Étape 3 — Charger l'extract OSM (Geofabrik)

# Téléchargement région Île-de-France
wget https://download.geofabrik.de/europe/france/ile-de-france-latest.osm.pbf

# Conversion en GeoParquet avec planetiler/osmium
osmium export ile-de-france-latest.osm.pbf \
  -o paris_osm.parquet \
  --output-format=parquet

Étape 4 — Joindre les 3 datasets

-- Stratégie hybride : Overture comme base, OSM pour enrichir les attributs récents
CREATE TABLE buildings_enrichis AS
SELECT
  o.gers_id,
  o.geometry,
  o.height AS height_overture,
  osm.height_tag AS height_osm_live,
  osm.last_edit_timestamp,
  -- Privilégier OSM si édité récemment, sinon Overture
  COALESCE(
    CASE WHEN osm.last_edit_timestamp > NOW() - INTERVAL '90 days'
         THEN osm.height_tag ELSE NULL END,
    o.height
  ) AS height_final
FROM paris_buildings_overture o
LEFT JOIN bridge_osm b ON o.gers_id = b.gers_id
LEFT JOIN paris_osm osm ON b.osm_id = osm.osm_id;

💡 Insight #3 — La règle d'or de la clé stable
N'utilisez jamais GERS ID seul comme clé primaire. Pattern recommandé :
PRIMARY KEY (h3_index_resolution_9, entity_type) + gers_id en colonne enrichissement + osm_id en colonne fallback. Si GERS churne, votre clé h3 tient.

🏢 3 cas d'usage par secteur

Tech

App hyperlocale type Yelp/Foursquare

Contexte : Vous lancez une app de découverte de restaurants à Lyon.
Stack recommandée : Overture Places (base) + bridge file OSM (mises à jour terrain) + données INSEE/SIRENE (légales).

Avant (combinaison personnalisée)Après (Overture + bridge)
6 semaines pour combiner Yelp + Google Places + OSM 3 jours : Overture Places direct, bridge file pour les MAJ OSM
Pipeline custom à maintenir Pipeline déclaratif, monthly refresh
Coût ingénieur ~25 k€ Coût ingénieur ~3 k€
Agency

Cabinet de conseil en risque assurance

Contexte : Un assureur vous demande de scorer 2 millions de bâtiments en France (risque inondation + sismicité).
Stack recommandée : Overture Buildings (footprints + hauteur) + Géorisques BRGM (zonage) + IGN BD TOPO (validation).

Pourquoi Overture ici ? Footprints homogènes sur tout le territoire (Microsoft ML-derived), hauteur quand dispo, schéma stable pour des analyses batch. Pas besoin d'updates live.

Erreur à éviter : Ne joignez PAS les zonages Géorisques sur GERS ID — joignez sur géométrie (intersection h3 resolution 8). Les bâtiments peuvent disparaître entre releases, mais le risque géographique reste lié au sol.

Coaching

Freelance / consultant data géospatial

Contexte : Un client vous demande "quelle stack pour notre projet de digital twin urbain ?"

Votre livrable : Un audit en 1 page qui montre que vous comprenez les trade-offs, pas juste les outils.

## AUDIT STACK GÉOSPATIALE — [CLIENT]

### 1. Profil de mise à jour
- Fréquence éditions terrain attendues : [ jour / semaine / mois / jamais ]
- Volume géographique : [ ville / région / pays / monde ]

### 2. Profil de jointure
- Datasets tiers à intégrer : [ liste ]
- Identifiants externes existants : [ liste ]

### 3. Profil de licence
- Sortie du livrable : [ propriétaire / open / mixte ]
- Compatibilité ODbL acceptable ? : [ oui / non ]

### 4. Recommandation
- Source primaire : [ OSM / Overture / hybride ]
- Identifiant pivot : [ osm_id / gers_id / h3 / geometry hash ]
- Cadence refresh : [ live / monthly / quarterly ]
- Justification (3 lignes max) : [...]

Part 3 — L'Outil

🧰 La stack 2026 recommandée

CoucheOutilPourquoi
Stockage GeoParquet sur S3/Azure Cloud-native, partitionné, lisible sans téléchargement
Query engine DuckDB Spatial Lit S3 en SQL, R-tree natif, zéro infrastructure
Extracts OSM Geofabrik + osmium Fiable, gratuit, par région
Bridge GERS↔OSM Overture bridge files Officiels, mensuel, 7 sources couvertes
Index spatial pivot H3 (Uber) Stable, hiérarchique, indépendant de tout vendor
Visualisation kepler.gl / DeckGL / Felt Rendu GeoParquet natif

📜 Les 3 règles d'or à imprimer

Règle 1. GERS ID est une colonne, jamais une clé primaire de prod.
Règle 2. Si vos contributeurs locaux comptent (mappers, terrain, agents), OSM reste l'unique source de vérité éditable. Overture en aval.
Règle 3. La gouvernance d'une donnée est plus importante que sa licence. Avant de migrer, demandez-vous : qui décide quand le schéma change ?

💬 Prompt Claude / ChatGPT prêt à l'emploi

Tu es un consultant data géospatial senior. J'ai un projet [DÉCRIRE LE PROJET EN 3 LIGNES]. Mes contraintes : budget [X k€], délai [X semaines], équipe [X personnes, niveau SQL/Python]. Applique le framework de décision Overture vs OSM (4 questions : updates < 24h, échelle planétaire, jointures tierces, tolérance churn IDs). Pour chaque question : 1. Donne la réponse pour mon projet 2. Justifie en 1 phrase 3. Conclus avec une recommandation de stack (sources + identifiant pivot + cadence refresh) Termine par un risque que je n'ai pas anticipé.

🔗 Pour aller plus loin


🎁 Bonus : checklist de migration en 7 points