OpenStreetMap est un wiki brillant et un mauvais entrepôt de données

81 455 423 lieux et 4 688 229 divisions administratives, comptés en 0,37 seconde sur un portable le 2026-10-11, sans décompresser un seul fichier. Les comptes répondent à une requête contre la version 2026-09-23.1 d'Overture Maps, et le plus frappant n'est pas leur ampleur. C'est la manière de compter : DuckDB a lu les métadonnées Parquet sur S3 et a répondu comme une base de données répond à une requête, pas comme répond un téléchargement en masse.

OpenStreetMap est le projet cartographique le plus considérable que des humains aient bâti, et ce succès est exactement le problème quand votre pipeline le traite comme de l'infrastructure de données. Un wiki optimise le consensus entre ses contributeurs. Un entrepôt optimise des colonnes typées et une vérité épinglée, interrogeable à la demande. Les deux objectifs se heurtent, et ce heurt explique l'existence d'Overture Maps, un consortium piloté par Amazon, Meta, Microsoft et TomTom, qui publie chaque mois une copie consolidée et schématisée des données de fond de la planète. Ce billet plaide pour poser votre couche de fond sur cette copie, et nomme ce qu'Overture ne fera pas pour vous.

Un wiki a la mauvaise forme pour un pipeline de données

Partez d'une question concrète. Votre équipe veut savoir quels restaurants d'une zone de livraison ont une terrasse. Posée à OpenStreetMap, elle devient une chasse aux tags : amenity=restaurant croisé avec outdoor_seating=yes, et la réponse est silencieusement incomplète parce que rien dans le modèle de données n'a à parler de terrasse du tout. Les tags sont des clés libres. Les pages du wiki en documentent des milliers, et n'importe quel contributeur peut en inventer une nouvelle cet après-midi. Aucun schéma ne contraint ces clés à exister, à porter un type, ni à désigner la même chose dans deux départements voisins.

L'identité est le deuxième accroc. L'objet atomique d'OSM est le nœud, si bien qu'un bâtiment tracé par deux contributeurs dont les modifications se rejoignent sur un mur commun arrive sous la forme de deux ways sans aucun lien stable entre elles. Un contributeur qui scinde une rue frappe de nouveaux identifiants de nœuds par souci de précision. Votre extraction de mardi et celle de vendredi diffèrent, et il n'existe aucun nom de version à épingler dans un dépôt.

Le remède bricolé, c'est votre propre table de passage, les tags d'un côté et vos colonnes de l'autre. Elle tient jusqu'à la retraite d'une clé sur le wiki ou son renommage par convention régionale, et la table de passage devient discrètement un produit de données sans propriétaire. Nous connaissons ce coût pour l'avoir payé : le graphe de sentiers que nous construisons à partir d'extractions OpenStreetMap charrie une couche d'interprétation des tags devenue plus longue que le code du graphe qu'elle alimente, et cette couche n'est jamais finie.

Overture, c'est la consolidation avec un calendrier de versions

Le vrai remède est le travail des autres, fait en public. Overture prend les sources communautaires, OSM au premier rang, plus le travail de Meta sur les lieux, ceux de Microsoft sur les bâtiments et de TomTom sur les routes, passe le mélange dans un pipeline de validation et de consolidation, puis publie chaque mois un instantané typé, estampillé deux fois : une date de version et une version de schéma. La version 2026-09-23.1 porte le schéma v2.0.0, et ses notes enregistrent le retrait du champ categories des lieux au profit de taxonomy et de basic_category, ainsi qu'une nouvelle classe de bâtiment shelter.

Chaque version vit au même endroit, selon le même motif de chemins sur S3 :

s3://overturemaps-us-west-2/release/2026-09-23.1/theme=<theme>/type=<type>/*.parquet

Les segments theme= et type= sont du partitionnement hive, expression terne tant qu'aucun moteur ne s'en sert. Pointez DuckDB vers le bucket avec hive_partitioning=1 et il saute des répertoires entiers sans les ouvrir : une question sur les bâtiments commence sa lecture à theme=buildings et n'ouvre jamais un fichier des 81 millions de lieux. Votre extraction porte désormais un nom qu'un relecteur peut épingler, une seule chaîne dans un seul dépôt, et quiconque la lit plus tard reçoit les mêmes octets.

Ma lecture des raisons pour lesquelles quatre entreprises que la donnée cartographique fait vivre financent tout cela : chacune payait jusqu'ici pour consolider le monde en privé, et le socle partagé les libère pour rivaliser au-dessus de la couche de données. Quoi qu'il en soit des motivations internes, l'artefact est public, en GeoParquet, et publié sous une licence de base de données ouverte.

Les identifiants GERS stables et l'élagage par fichiers sont les deux premiers changements qui comptent

L'identifiant d'abord, parce qu'il change ce qu'est une jointure. Chaque entité consolidée porte un identifiant GERS stable qui survit à l'instabilité des sources, ce qui transforme « rattacher vos enregistrements à la carte » de re-trace en jointure. Un café de mon échantillon du Tahoe, tiré de la version 2026-09-23.1, se trouve dans le thème places sous l'identifiant e13e7209-a09a-4cf7-9d45-0532936fcc4c, taxonomy primaire furniture_store, confiance 1.0, avec un compteur de version sur la ligne. Quand une consolidation ultérieure re-fusionne ses sources, l'identifiant ne bouge pas et la version avance, si bien que votre jointure le remarque au lieu de casser. Dans OSM, le même rattachement est une trace d'identifiants de nœuds, et la scission d'un contributeur peut l'invalider du jour au lendemain.

Le deuxième changement, c'est l'élagage. Comme bbox est une simple colonne struct, un prédicat dessus écarte des fichiers Parquet comme des lignes, sans toucher une seule géométrie. J'ai posé quatre questions à la version 2026-09-23.1 avec DuckDB 1.5.6 le 2026-10-11 ; chaque temps réel ci-dessous vient de cette exécution :

Question posée à la version 2026-09-23.1	Réponse	Temps réel
Nombre de lieux, version complète	81 455 423	0,37 s
Lieux dans une boîte englobante du Tahoe (-121.0 à -119.6, 38.7 à 39.5)	28 166	2,77 s
Bâtiments dans la même boîte	228 935	37,1 s
Segments de transport dans la même boîte	106 242	18,0 s

La ligne à deux secondes vaut qu'on s'y arrête. La requête tient en ceci :

SELECT count(*)
FROM read_parquet(
  's3://overturemaps-us-west-2/release/2026-09-23.1/theme=places/type=place/*.parquet',
  hive_partitioning = 1
)
WHERE bbox.xmin >= -121.0 AND bbox.xmax <= -119.6
  AND bbox.ymin >= 38.7 AND bbox.ymax <= 39.5;

Rien ne se télécharge ici. Le moteur écarte les fichiers par partition, les lignes par bbox, et ne lit que ce que le prédicat admet. La même question à OSM, c'est soit une requête Overpass côté serveur dont la latence est un don de la communauté, soit une extraction régionale suivie d'un déchiffrement XML. C'est le sens concret de l'expression que j'emploie en rendez-vous : de la donnée géographique qui se comporte comme une donnée normale. Votre compte de mardi et celui de mardi prochain ne diffèrent que si vous avez interrogé des identifiants de version différents, un fait qui s'imprime dans le rapport.

Deux limites à inscrire au plan, et les contournements

Première limite : les adresses. La version 2026-09-23.1 embarque 474 millions de caractéristiques d'adresses, chiffre que publie Overture pour ce thème, et la documentation le marque alpha : pas encore d'identifiants GERS, et un schéma qui peut encore bouger. Ne branchez rien d'orienté client dessus. Géocodez à partir des lieux et des divisions aujourd'hui, gardez les adresses dans une expérience à part, dans son propre environnement, et revenez au thème quand il aura mûri et que les identifiants seront là.

Deuxième limite : le décalage de consolidation, et son ombre. Un contributeur complète les horaires d'un café dans OSM au petit-déjeuner ; la modification n'atteint Overture qu'au plus tôt dans la version du mois prochain. Le contournement garde les deux outils honnêtes : courez OSM comme votre couche de lieux en direct là où la fraîcheur de la semaine passée compte, puis raccrochez-le aux identifiants stables de la version épinglée une fois la version parue. Et montrez la même méfiance envers la nouvelle couche qu'envers l'ancienne. Dans mon échantillon du Tahoe, 896 des 28 166 lieux n'avaient pas de taxonomy.primary, donc toute logique bâtie sur ce champ a besoin d'un chemin de repli. Les notes de la version 2026-09-23.1 enregistrent aussi une instabilité d'identifiants dans base et building_part après un changement de génération des UUID. Épinglez la version, lisez les notes, et traitez GERS comme stable là où le modèle de données a mûri.

Ce qui reste de tout cela pour votre pipeline

Si votre couche de fond est un grep dans les tags, alors pour chaque question à laquelle vous avez déjà répondu vous maintenez un schéma artisanal, et pour chaque question qui arrive le mois prochain vous maintenez un plan à la place. La décision tient en une ligne : épinglez la version 2026-09-23.1, chargez theme=places et theme=divisions, interrogez-les sur place avec DuckDB, gardez OSM là où la fraîcheur gagne, et ré-épinglez quand les notes de la prochaine version sont claires.

Le wiki reste. L'entrepôt cesse d'être votre travail, parce que quelqu'un d'autre le finance, le publie sur un calendrier, et nomme chaque version pour que vous puissiez l'épingler.

AngoraTek construit des pipelines de données géospatiales pour des équipes qui éditent des produits cartographiques. [Parlez-nous](/fr/#contact) si votre couche de fond est encore un tas de greps dans les tags.