Commencez votre migration Overture par une région, pas par la planète entière

Rien ne casse le jour où votre pipeline commence à lire Overture Maps. La version 2026-09-23.1 sert des tuiles, répond aux requêtes analytiques, et reste sagement à côté de l'extrait OpenStreetMap que personne n'a encore désinstallé. C'est ce calme qui tue les migrations : sans incendie à éteindre, la migration glisse au trimestre suivant, et le coût de maintenance d'OSM continue d'arriver chaque mois pendant que l'onglet de comparaison reste ouvert sur votre écran. Ce billet s'adresse au responsable SIG dans exactement cette situation, celui qui doit poser un plan devant son directeur technique.

Le plan, énoncé pour que vous puissiez le contester : une migration de carte de base d'OSM vers Overture tient en huit étapes de travail de pipeline sans éclat, qui rentrent dans un trimestre. Les équipes que cette migration blesse sont celles qui commencent par la planète entière au lieu d'une seule région. Charger les données est la moitié facile de ce travail. L'autre moitié met à la retraite des hypothèses que votre pipeline OSM a fait pousser sans que personne ne les écrive, et la liste de ces cinq hypothèses vient d'abord, parce que chaque étape du plan existe pour en retirer une.

La bascule casse cinq hypothèses avant de casser le moindre code

La première casse est le schéma. OSM tend à votre pipeline des balises libres, et chaque table de correspondance des balises vers les colonnes est un schéma que vous possédez sous un autre nom. Overture vous tend les colonnes, taxonomy.primary pour la catégorie et speed_limits avec son unité, et elle versionne ce schéma dans son ensemble. Le schéma v2.0.0 de la version 2026-09-23.1 a retiré le champ categories des places au profit de taxonomy et de basic_category, et toute requête écrite contre la version mineure précédente a cessé de fonctionner le même mois. Ce retrait est l'étude de cas de l'étape une, pas une fable à faire peur.

La deuxième casse est l'identité. OSM vous donne des identifiants de nœuds et de chemins, qui changent dès qu'un contributeur retrace le même mur. Overture vous donne des identifiants GERS, conçus pour survivre précisément à ce brassage. Les deux systèmes ne se traduisent pas l'un dans l'autre, parce qu'un identifiant de nœud nomme une modification qui a eu lieu une fois et un identifiant GERS nomme un objet qui persiste. Ce qui déplace vos enregistrements vers la nouvelle couche, c'est une jointure que vous construisez puis entretenez, ce qui ressemble davantage à la possession d'un produit de données qu'à une conversion de format. Nous avons documenté la jointure elle-même, compteurs de version compris, dans joindre deux jeux de données cartographiques avec les identifiants GERS.

La troisième casse est la posture de licence, et elle remonte dans la paperasse plutôt que dans le code. Overture publie ses données sous la licence CD-ODbL-BY. La documentation du schéma est en CC BY et l'outillage en MIT. Écrivez cela dans votre document d'architecture, mot pour mot. Puis ajoutez à côté notre réserve, dans les mêmes mots simples : la manière dont les termes de partage à l'identique d'une licence de base de données traitent vos tables dérivées mérite une vraie lecture juridique avant que votre entreprise ne s'engage. Nous sommes ingénieurs, pas juristes, et une migration est la mauvaise semaine pour découvrir ce que les obligations sur une base dérivée signifiaient.

La quatrième casse est la fraîcheur, parce que les deux sources ne battent pas au même rythme. OSM est vivante : une modification faite le matin dans une ville peut être dans votre extrait avant la fin de la semaine. Overture publie chaque mois, si bien que la version 2026-09-23.1 comptait déjà un mois d'histoire le jour où elle est tombée. Aucune des deux horloges n'a tort. Mais votre produit contient les deux espèces de données, donc la décision se prend couche par couche. Des empreintes de bâtiments qui alimentent un rapport de couverture tolèrent un mois d'âge. Les horaires d'ouverture d'un restaurant dans une application de livraison non, et OSM reste sur cette couche.

La cinquième casse est la maturité de l'outillage, nommée ici pour qu'elle ne vous embusque pas à l'étape six. L'outillage OSM qui entoure votre pipeline a vingt ans, et son ennui est une qualité. Celui d'Overture est assez jeune pour bouger sous vos pieds d'une version à l'autre, une propriété à planifier plutôt qu'une raison d'attendre. Le bord le plus tranchant est le thème des adresses : 474 millions d'objets, marqués alpha dans la documentation d'Overture, sans identifiant GERS pour l'instant. Rien de tout cela ne bloque la bascule de la carte de base. Cela veut seulement dire que le géocodeur est la dernière chose à déplacer, et l'étape six le dit à voix haute.

Le plan : huit étapes, une région

Chaque étape ci-dessous tourne sur une seule région, et la région est la nôtre. C'est un rectangle englobant autour de Tahoe, de la longitude -121.0 à -119.6 et de la latitude 38.7 à 39.5, l'échantillon que nous chargeons dès que nous voulons des réponses Overture sur un ordinateur portable. Les chiffres cités proviennent de requêtes lancées avec DuckDB 1.5.6 le 2026-10-11, contre la version 2026-09-23.1 sauf mention contraire. Votre région produira des chiffres différents à chaque ligne. La forme du travail, elle, se transporte.

Étape une : on épingle la version avant que la moindre donnée ne bouge. L'identifiant 2026-09-23.1 va dans un fichier de constantes de votre dépôt, et chaque script qui suit lit la version depuis ce fichier. Un contrôle en CI fait échouer toute construction où deux scripts se contredisent, parce que la casse de schéma v2.0.0 a montré ce qu'une version mineure non épinglée fait à une requête. Épingler coûte dix minutes et achète quelque chose de plus cher : la capacité de reproduire chaque chiffre imprimé dans un rapport d'incident.

Étape deux : on découpe l'extrait, sur place, avec DuckDB. Installez les extensions spatial et httpfs, pointez read_parquet vers le chemin de la version avec le partitionnement hive activé, et filtrez sur la colonne struct bbox plutôt que sur la géométrie. Ce prédicat élague les fichiers Parquet et les lignes sans ouvrir une seule géométrie, et c'est ainsi que notre boîte a répondu 28 166 places en 2,77 secondes et 228 935 bâtiments en 37,1 secondes le 2026-10-11. La recette complète, extensions et comportement de partitionnement compris, est dans interroger Overture avec DuckDB.

Étape trois : on mappe le schéma et l'identité dans la même séance. Pour chaque balise OSM que votre pipeline lit réellement, nommez la colonne Overture qui la remplace, et écrivez NULL là où rien ne la remplace, parce que ces lignes sont votre liste de réécritures. Construisez ici aussi la table de jointure OSM vers GERS, adossée à la version épinglée. Attendez-vous à de la résistance : dans notre échantillon autour de Tahoe, 896 places sur 28 166, soit 3,2 %, n'avaient aucun taxonomy.primary, donc toute logique appuyée sur cette colonne a besoin d'un chemin de repli écrit le jour même du mapping.

Étape quatre : on pose le service par charge de travail, et c'est la charge qui choisit la base, pas le goût. Les questions qui étaient des requêtes Overpass partent dans DuckDB, qui continue de lire la version épinglée sur place. La carte que lit votre application va dans PostGIS, chargée depuis l'extrait. Les documents qui vivent déjà dans MongoDB peuvent absorber Overture directement, parce que le CLI officiel overturemaps-py écrit vers MongoDB comme mode de sortie. Nous avons posé les mêmes questions aux trois chemins dans stocker Overture dans Postgres, MongoDB et DuckDB.

Étape cinq : on reconstruit les tuiles depuis l'extrait épinglé, pas depuis ce que le moteur de rendu précédent a laissé derrière lui. L'outillage officiel de tuiles produit des PMTiles depuis le GeoParquet d'Overture, et l'exemple build-a-map de la documentation mène de DuckDB à la génération de tuiles puis à un visualiseur MapLibre. Nommez le paquet de tuiles d'après la version d'où il vient, comme vous avez nommé l'extrait. Un jeu de tuiles sans version accrochée n'est que la prochaine table de correspondance sans propriétaire.

Étape six : on ajoute géocodage et routage seulement là où le produit l'exige, et le verbe fait un vrai travail dans cette phrase. Beaucoup d'équipes répondent aux questions d'adresses depuis leurs propres tables et n'ont besoin d'aucun géocodeur au premier jour. Là où vous routez, le projet omf-bifrost construit des tuiles de graphe Valhalla depuis le GeoParquet d'Overture, et c'est l'outil le plus mûr de sa catégorie dans l'écosystème, ce qui est un compliment timide. Là où vous géocodez, faites un benchmark avant de vous engager. Le projet overture-geocoder publie 80 % de précision top-1 sur des questions de villes contre 67 % pour Nominatim, un chiffre que ses auteurs bornent aux recherches urbaines. Un test plus étroit que votre trafic de production mérite exactement le scepticisme que vous accorderiez à un chiffre des nôtres.

Étape sept : on lit en double pendant la fenêtre de bascule. Les deux lecteurs restent pointés vers leurs sources pendant que le chemin Overture accumule des semaines de preuves, avec OSM toujours propriétaire de la couche des lieux frais, conformément à la quatrième casse. Il n'y a pas de grand retournement de drapeau. Une couche arrête la double lecture quand son contrôle qualité passe contre deux versions consécutives, et jusque-là les deux pipelines continuent de se rendre utiles.

Étape huit : on écrit la liste de contrôle qualité et la date de repli le jour même où la bascule commence. Recomptez les objets contre la version épinglée. Vérifiez des attributs sur dix objets que vous pouvez aller voir. Rendez les tuiles à trois niveaux de zoom et regardez. Chaque contrôle cite l'identifiant de version contre lequel il a tourné, et la date de repli va sur un calendrier avec un nom à côté, parce qu'un repli sans propriétaire est un repli qui n'arrive pas.

L'essai planétaire que nous ne répétons pas

Notre propre historique contient précisément l'erreur contre laquelle ce billet argumente. Notre toute première séance Overture a tiré des réponses sur la planète entière, 81 455 423 places et 4 688 229 divisions, alors que la question réelle à l'écran tenait dans une seule région. Les comptages étaient honnêtes et inutiles à un plan : ni extrait, ni mapping de schéma, ni table de jointure, et un volume de données bien au-delà des décisions de service de l'étape quatre. Une migration qui commence par la planète entière achète la même leçon un mois plus tard à un prix plus élevé. La région d'abord, la planète quand le produit en couvre réellement une, voilà la séquence que nous poussons désormais dans chaque réunion où un directeur technique est assis à la table.

Ce que ce plan ne peut pas promettre

Rien de ce qui précède ne sort d'une mission client, donc le billet ne porte aucun chiffre avant-après inventé. L'opinion est de celle qui se forme en entretenant des pipelines OSM, chez nous depuis des années. L'un de ces pipelines est le graphe de sentiers que nous construisons depuis OpenStreetMap, dont la couche d'interprétation des balises a dépassé en taille le code du graphe en dessous, et qui n'est jamais fini.

La réserve sur l'outillage reste réelle elle aussi. Le constructeur de graphes et les géocodeurs communautaires sont du code jeune, le thème des adresses est alpha, et le schéma a déjà cassé une version mineure une fois. Le plan absorbe cela par construction : une version épinglée, une région, et un géocodeur qui reste en place tant que votre propre benchmark ne dit pas le contraire, voilà ce qui laisse les pièces jeunes échouer sans danger. Et la question des licences demeure une question juridique que nous ne pouvons pas trancher pour vous. Ce que nous pouvons faire, c'est lire les notes de version avec vous, épingler la version, et vous remettre les chiffres mesurés pour votre région.

La décision en une ligne : donnez à la migration un trimestre, démarrez-la sur les données d'une seule région, et tenez la date de repli à un standard qu'un directeur technique peut lire sans traducteur.