Les nouvelles tuiles vectorielles d’OpenStreetMap

• OpenStreetMap fournit depuis longtemps des tuiles raster statiques basées sur des PNG, mais commence désormais à héberger des tuiles vectorielles au format Mapbox Vector Tiles (MVT), ce qui élargit les usages possibles de la carte
• Les tuiles vectorielles permettent aux utilisateurs d’ajuster le style et les règles de rendu, d’extraire les informations contenues dans les tuiles et d’implémenter des fonctionnalités comme le changement de langue des libellés
• Le site web principal d’OSM utilise encore des tuiles raster, mais les nouvelles tuiles vectorielles peuvent être consultées directement dans une démo web distincte, dans QGIS et dans Leafmap
• L’exemple de tuile z14 près du Burj Khalifa montre qu’un fichier MVT de 114 KB a été converti en un JSON de 1,4 MB, et que la couche POI contient 474 enregistrements ainsi que plusieurs clés de couche de premier niveau
• Avec tiles2columns, il est possible de télécharger les tuiles vectorielles OSM d’une boîte englobante donnée et de les convertir en GeoPackage ou en Parquet, ce qui facilite l’exploitation directe des données OSM mises à jour pour des analyses basées sur des fichiers

---

Ce qui change avec les tuiles OSM

• Jusqu’à présent, OpenStreetMap fournissait ses cartes sous forme de tuiles raster PNG statiques avec des règles de rendu et des styles prédéfinis
• Le nouvel hébergement fournit des tuiles vectorielles au format MVT, c’est-à-dire Mapbox Vector Tiles
• Avec les tuiles vectorielles, l’utilisateur final peut contrôler plus directement la représentation de la carte
  • Ajustement des styles et des règles de rendu
  • Extraction des données sous-jacentes incluses dans chaque tuile
  • Affichage d’images cartographiques plus nettes
  • Possibilité de changer la langue des libellés
• Le site principal d’OSM continue toutefois de proposer des tuiles raster
• Les nouvelles tuiles vectorielles peuvent être consultées sur la démo web depuis la plupart des téléphones et ordinateurs de bureau

Outils utilisés pour les essais

• Les exemples utilisent Python et plusieurs outils géospatiaux pour visualiser et analyser les données OSM
• Les outils de base installés incluent jq, python3-pip et python3-virtualenv
• Les paquets suivants sont installés dans un environnement virtuel Python
  • leafmap[maplibre]
  • mapbox_vector_tile
  • morecantile
  • notebook
• DuckDB est utilisé avec les extensions suivantes
  • H3
  • JSON
  • Lindel
  • Parquet
  • Spatial
• Le rendu cartographique est réalisé avec QGIS 3.40
  • QGIS est une application de bureau qui fonctionne sous Windows, macOS et Linux
  • Les applications de ses utilisateurs sont lancées environ 15 millions de fois par mois dans le monde

Ouvrir les tuiles vectorielles dans QGIS

• Dans QGIS, on peut ajouter les tuiles vectorielles OSM via Layer Menu -> Add Layer -> Add Vector Tile Layer
• Pour une nouvelle connexion, l’URL de style utilise la valeur suivante
  • https://pnorman.github.io/tilekiln-shortbread-demo/colorful.json
• L’URL source doit pointer vers le point de terminaison MVT suivant
  • https://vector.openstreetmap.org/shortbread_v1/{z}/{x}/{y}.mvt
• La feuille de style est facultative, QGIS pouvant aussi rendre les données vectorielles avec des couleurs arbitraires
• Dans QGIS, un problème de rendu des icônes a été constaté
  • D’autres outils de cartographie rendent correctement les sprites de ce style
  • Dans QGIS, les icônes apparaissent comme des icônes noires floues
  • Le problème correspondant est documenté dans QGIS #59492

Rendu avec Leafmap et Jupyter Notebook

• Un dossier de configuration Jupyter Notebook est créé, un mot de passe est défini, puis le serveur est lancé sur 127.0.0.1
• Le Notebook s’exécute avec les droits de l’utilisateur qui le lance et peut exposer le répertoire courant ainsi que ses sous-fichiers, d’où le choix de le lancer dans un dossier vide
• Dans Leafmap, leafmap.maplibregl est utilisé avec l’URL de style colorful.json pour afficher la zone autour du Burj Khalifa
• Avec Leafmap, les icônes de POI s’affichent correctement

Transformer les MVT en données analysables

• Une tuile de niveau de zoom 14 près du Burj Khalifa est utilisée comme exemple
• Les coordonnées approximatives [55.27, 25.2] sont passées à morecantile tiles 14 pour obtenir les coordonnées de tuile [10707, 7006, 14]
• La tuile suivante est ensuite téléchargée
  • https://vector.openstreetmap.org/shortbread_v1/14/10707/7006.mvt
• Le fichier MVT de 114 KB est converti en un fichier JSON de 1,4 MB à l’aide de mapbox_vector_tile.decode et de fonctions de transformation de coordonnées
• Les clés de premier niveau de la tuile convertie incluent les couches suivantes
  • addresses
  • bridges
  • buildings
  • ferries
  • land
  • ocean
  • pier_lines
  • pier_polygons
  • place_labels
  • pois
  • public_transport
  • sites
  • street_labels
  • street_polygons
  • streets
  • streets_labels_points
  • water_polygons
  • water_polygons_labels

Explorer la couche POI avec DuckDB

• La couche pois est extraite dans un fichier JSON séparé, puis ouverte pour analyse avec ST_READ de DuckDB
• Les POI avec une valeur cuisine représentent 67 lignes dans la requête
  • Parmi les valeurs d’amenity, on trouve restaurant, fast_food et cafe
  • Parmi les valeurs de cuisine, on trouve french, greek, american, lebanese, coffee_shop, asian, persian, chicken et pizza
• Les résultats de SUMMARIZE dans DuckDB permettent de voir le niveau de remplissage des données POI
  • Le nombre total d’enregistrements POI est de 474
  • Le taux de valeurs nulles pour name, name_de et name_en est de 29,96 % chacun
  • Le taux de valeurs nulles pour amenity est de 31,86 %
  • Le taux de valeurs nulles pour cuisine est de 85,86 %
  • Le taux de valeurs nulles pour geom est de 0,00 %
• Selon approx_unique, name compte 258 valeurs, name_de 264, name_en 245, amenity 27 et cuisine 39

Extraire une boîte englobante avec tiles2columns

• L’outil existant osm_split servait à convertir des fichiers OSM PBF produits par GeoFabrik en fichiers GeoPackage nommés
• Les fichiers PBF GeoFabrik peuvent dater de plusieurs jours au moment où ils sont traités
• Les nouvelles tuiles vectorielles OSM sont mises à jour juste après l’édition des données sous-jacentes
• tiles2columns est un utilitaire Python qui télécharge les tuiles OSM d’une boîte englobante donnée et les convertit en fichiers GeoPackage ou Parquet
• L’exemple de boîte englobante autour du nord de Dubaï télécharge 42 tuiles et génère plusieurs fichiers GeoPackage de quelques mégaoctets
  • streets.gpkg: 6,8 MB
  • buildings.gpkg: 6,2 MB
  • pois.gpkg: 1,4 MB
  • street_labels.gpkg: 1,4 MB
  • land.gpkg: 744 KB
• Les fichiers GeoPackage générés peuvent être directement ajoutés à un projet QGIS
• Les fichiers sont séparés selon les clés utilisées dans les fichiers OSM MVT, ce qui facilite l’identification, le style et l’analyse indépendants de chaque couche
• Les attributs de chaque géométrie sont stockés dans des colonnes distinctes
• Un exemple de requête dans pois.gpkg sur les POI ayant un nom renvoie 6 329 lignes, avec notamment Kiku, Fujiya Restaurant, Mövenpick Grand Al Bustan Dubai et McDonald's

[unsure4000]

La fondation OpenStreetMap a officiellement commencé à exploiter des tuiles cartographiques vectorielles

[GN⁺]

Commentaires sur Hacker News

• J’ai un sentiment assez mitigé à propos des tuiles vectorielles. Je n’ai pas encore trouvé de combinaison style + schéma de génération de tuiles qui affiche le même niveau de détail que les tuiles raster d’origine.
  Rien qu’en regardant les captures d’écran de l’article, la différence est nette. La première contient beaucoup d’informations : des points d’intérêt comme des statues, des boutiques, des théâtres et des points de vue, des routes représentées comme des ponts, des différences de couleur entre pelouses et parcs, des épaisseurs de trait selon les routes, des terrains de sport, des noms de bâtiments et de quartiers, des flèches de sens unique, des parties de bâtiments, des escaliers, des arbres, etc.
  La seconde ne montre guère qu’un arrêt de trolley et un nom de rue, et même ce nom de rue est mal rendu.
  J’ai beaucoup utilisé les styles openmaptiles, le style par défaut de protomaps, les styles Mapbox, ainsi que les générateurs protomaps, openmaptiles et Mapbox, mais rien n’était aussi lisible et riche en détails que les tuiles raster OSM.
  Les styles vectoriels offrent un zoom et un déplacement fluides, et sont faciles à modifier, mais ils restent insuffisants quand on veut réellement consulter les données cartographiques, et pas seulement s’en servir comme fond de carte pour ses propres données.
  C’est peut-être dû à des limites de ressources de calcul. Afficher le même niveau de détail que les tuiles raster OSM pourrait consommer trop de ressources, à la fois côté client et côté génération des tuiles.
  J’aimerais qu’OpenStreetMap imite plus fidèlement le style raster existant plutôt que de proposer un énième fond de carte peu contrasté et peu détaillé, et j’espère que cette publication de tuiles vectorielles publiques permettra des cartes vectorielles plus détaillées.

  • Sur le fond, c’est juste, mais on peut voir les choses un peu différemment. Pour ceux qui fournissent les cartes, le principal avantage des tuiles vectorielles n’est pas un petit gain comme la netteté ou la souplesse du style, mais une forte réduction de la quantité de calcul nécessaire.
    Maintenir une infrastructure moderne de génération de tuiles raster représente un travail assez conséquent.
    J’avais auparavant développé pendant longtemps un style très détaillé pour planifier des voyages à vélo : https://stevebennett.me/2015/01/14/cycletour-org-a-better-ma...
    J’ai essayé plusieurs fois de le reproduire avec des tuiles vectorielles, mais il était assez difficile d’y mettre suffisamment de détails sans se heurter aux limites de taille, et les tuiles Mapbox de base manquaient de loin des informations nécessaires.
    Cela dit, les tuiles vectorielles permettent aussi des contournements impossibles avec les tuiles raster. Par exemple, on peut activer et désactiver différentes couches tout en laissant les libellés tenir compte de ce qui se trouve en dessous, afin de préserver la lisibilité.
  • Jusqu’ici, l’accent semble avoir été mis davantage sur les logiciels permettant de générer des tuiles vectorielles mises à jour en continu que sur l’enrichissement des styles qui exploitent ces tuiles.
  • J’ai créé un fork d’OpenRailwayMap. L’original est sur https://www.openrailwaymap.org, et le style vectoriel est sur https://openrailwaymap.fly.dev.
    Le style a été calé au plus près de l’apparence des tuiles raster d’origine, mais la version vectorielle ajoute beaucoup plus de fonctions interactives.
    Ce qui est intéressant du point de vue de la conception des styles et des tuiles, c’est que les compromis de performance changent complètement selon l’endroit et la manière dont les tuiles sont rendues. C’est évident, mais cela a aussi un impact sur ce qui est visuellement possible côté serveur et côté client.
  • Tout à fait d’accord. Pour trouver mon chemin, j’utilise un mélange d’OpenStreetMap et de Google Maps ; même si j’aimerais n’utiliser qu’OSM, le nombre de lieux enregistrés n’est pas aussi élevé que sur Google Maps.
    Malgré cela, les cartes OSM sont bien plus agréables à utiliser, parce qu’elles affichent beaucoup de points d’intérêt. Rien qu’en regardant la carte, on se fait une idée du lieu réel : un parc ressemble à un parc, un hôpital à un hôpital.
    Google Maps peut paraître meilleur du point de vue d’un graphiste. Mais pour s’orienter, il faut généralement comparer la forme des routes et des intersections. Sur Google Maps, tout se ressemble.
  • Je pense exactement la même chose. Le style par défaut d’openstreetmap.org est, à titre personnel, proche du bonheur pur, et j’ai passé pas mal de temps à essayer d’amener les cartes vectorielles à ce niveau, sans trouver de résultat vraiment utilisable.
    Il suffit de manipuler la carte deux minutes pour voir immédiatement la perte de détails. C’est vraiment dommage, mais je reste optimiste : quelqu’un finira bien par résoudre le problème.

• C’était intéressant de voir la communauté open source construire des fonctionnalités de tuiles cartographiques vectorielles. Vers 2018, quand je travaillais sur du SIG web, les cartes vectorielles en streaming de Google/Apple semblaient magiques, et je les aurais absolument utilisées si le coût avait été supportable.
  Peu de temps après, les technologies clés sont arrivées en open source, et même des solutions d’hébergement gratuites ont vu le jour. Aujourd’hui, on peut utiliser gratuitement d’excellentes couches vectorielles dans une carte Leaflet. Merci l’open source.

  • Je suis un peu surpris qu’OSM ait mis autant de temps à en arriver là. Les briques technologiques de base existaient déjà il y a plus de dix ans.
    Je ne veux pas me plaindre d’un service cartographique gratuit : le service est excellent, et je comprends aussi qu’il se concentre davantage sur l’édition et la propriété des données. L’infrastructure de diffusion est difficile et coûteuse.
    Je me demande simplement dans quelle mesure la domination de Mapbox a freiné d’autres initiatives pendant toutes ces années.

• Je me demande si les coûts d’exploitation baissent quand on héberge des cartes basées sur OSM. Le rendu devrait nécessiter moins de CPU, et les vecteurs devraient aussi consommer moins d’espace de stockage et de bande passante.

  • Oui et non.
    Non, parce que la couche de tuiles officielle d’OSM bénéficie d’un gros sponsoring de Fastly. La dernière fois que j’ai vérifié, Fastly représentait 720 k€, et le rendu AWS 40 k€.
    Oui, parce que techniquement cela utilise moins de ressources, donc cela pèse moins sur AWS+Fastly, et cela rend aussi l’auto-hébergement plus facile.
    Dans une évaluation des risques que j’avais lue en détail il y a quelque temps, OSM écrivait que « si nous perdions le sponsoring de Fastly, nous couperions probablement tout accès tiers à la couche de tuiles standard et n’exploiterions plus que quelques serveurs Varnish ».
    D’après ce que j’ai compris, la motivation principale des vecteurs était moins la réduction des coûts que l’amélioration de l’internationalisation, la possibilité de prendre des décisions de rendu côté client, et la mise en place d’une chaîne d’outils moderne ouvrant la voie à plusieurs bénéfices ultérieurs.
    Il existe sans doute des informations plus récentes, et les ressources pertinentes sont en 1 et 2.
    1. https://operations.osmfoundation.org/2024/01/25/owg_budget.o...
    2. https://osmfoundation.org/wiki/Finances
  • On peut aussi répondre non. Les tuiles vectorielles peuvent déjà depuis longtemps être auto-hébergées, ou hébergées par quelqu’un d’autre, avec très peu d’effort.
    Cela dit, c’est vrai dans le sens où l’on transfère une partie du traitement au client et, plus important encore, où l’on permet au client de prendre beaucoup de décisions de style. Pas toutes, bien sûr.
    Des tuiles vectorielles statiques ou rarement mises à jour peuvent être générées à partir des données OSM avec plusieurs outils ; les plus populaires actuellement sont https://github.com/systemed/tilemaker et https://github.com/onthegomap/planetiler.
    La vraie nouveauté, grâce au travail réalisé par Paul pour l’OSMF, c’est que les tuiles vectorielles peuvent désormais être mises à jour quasi immédiatement, c’est-à-dire en quelques minutes. C’est important comme mécanisme de retour pour les contributeurs OSM, et c’est aussi la principale raison pour laquelle l’OSMF exploite actuellement le service de tuiles raster.
    Pour l’instant, les restrictions qui s’appliqueront à l’usage du service de tuiles vectorielles restent ouvertes. Comme pour le service de tuiles raster, l’objectif n’est pas de concurrencer ni de remplacer des services tiers, mais le service de tuiles vectorielles pourrait potentiellement le faire.
  • Oui, les tuiles vectorielles sont beaucoup plus faciles à auto-héberger.
    Par exemple https://protomaps.com/, https://openmaptiles.org/, https://versatiles.org/.
  • Je suis le créateur d’openfreemap.org. C’est exact. Les tuiles vectorielles reviennent essentiellement à héberger des fichiers statiques, et le serveur n’a rien à faire en dehors du chiffrement HTTPS.
    La compression gzip est déjà faite à l’intérieur des tuiles.

• Un autre problème est que, dans la version vectorielle, les polices arabes ne sont pas rendues correctement. Elles sont rendues de gauche à droite au lieu de droite à gauche, et les lettres apparaissent séparées au lieu d’être liées.

  • Le principe des tuiles vectorielles est que le rendu se fait localement et, en dehors du schéma des tuiles, qu’il est contrôlé par des paramètres de style modifiables.
    Donc les problèmes visibles viennent du style ou de la bibliothèque qui rend le contenu localement.
  • Je ne sais pas comment fonctionne le moteur de rendu de tuiles vectorielles de QGIS, mais pour la page de démo GitHub, il devrait être facile d’ajouter à MapLibre le plugin de texte RTL afin de gérer correctement le texte écrit de droite à gauche : https://maplibre.org/maplibre-gl-js/docs/examples/mapbox-gl-...

• À voir aussi : OpenFreeMap — hébergement gratuit de tuiles vectorielles OpenStreetMap
  https://openfreemap.org/

  • OpenFreeMap ne fournit pas : recherche ou géocodage, calcul d’itinéraires, navigation et guidage, génération d’images statiques, hébergement de tuiles raster, hébergement d’images satellite, requêtes d’altitude, hébergement de tuiles ou de jeux de données personnalisés.
    https://github.com/hyperknot/openfreemap?tab=readme-ov-file#...
  • Waouh, ça a l’air extrêmement bien fini.
    Je me demande si cela repose aussi sur la même pile technologique vectorielle, ou si c’est un développement complètement distinct.

• La partie disant que « les images seront bien plus nettes et le changement de langue des libellés deviendra possible » risque de moins bien fonctionner qu’espéré.
  Quand on change de langue, rien ne garantit que la taille des libellés reste la même, et la taille des libellés interagit avec la mise en page de la carte et détermine aussi ce qui sera affiché.
  Si les libellés deviennent plus grands, ils peuvent trop masquer la carte ou se chevaucher. S’ils deviennent plus petits, les utilisateurs peuvent se demander pourquoi des villes auparavant omises à cause du manque de place n’apparaissent pas dans le nouvel espace libre.

  • Je déteste vraiment le fait que, dans Google Maps, les noms de villes et de routes disparaissent quand on zoome ou dézoome. Certains noms de routes ou de commerces ne sont visibles qu’à un niveau de zoom précis, puis disparaissent si l’on zoome plus ou moins.
    Il suffit d’afficher tous les noms de routes. Ce n’est pas grave si c’est dense. Être à un carrefour avec une carte sans noms, ça ne sert à rien.
  • De toute façon, le point de départ est le placement automatique des libellés.
    C’était déjà pareil avec les tuiles raster utilisées depuis des années.
  • Y a-t-il une raison de penser que l’algorithme de placement va beaucoup changer ?

• C’est une nouveauté très bienvenue. J’ai hâte de voir des cartes plus agréables à regarder.
  En revanche, la section « my workstation » me laisse un peu perplexe. Elle ne semble pas avoir grand rapport avec le reste de l’article, et le travail décrit ensuite ne semble pas non plus exiger une configuration particulièrement puissante.

• Si « les images deviennent beaucoup plus nettes et qu’il sera possible de changer la langue des libellés », est-ce que cela veut dire, par exemple, que les vecteurs représentant la forme des villes — plus précisément les polygones — embarqueront les métadonnées des noms de villes dans toutes les langues définies ?

  • Les grandes villes incluent déjà des noms dans plusieurs langues. Par exemple, voir Paris : https://www.openstreetmap.org/relation/71525
    L’utilité du changement de langue dépend évidemment de l’existence des traductions. Cela pourrait aussi inciter les contributeurs à ajouter davantage de traductions de toponymes.
  • shortbread, le schéma de tuiles actuellement utilisé pour les tests, ne prend pas en charge plusieurs langues, mais d’après ce que je sais, les personnes qui y travaillent veulent le faire une fois les bugs réglés.
    On peut voir un exemple de ce rendu sur https://americanamap.org. Le site utilise des données OSM, mais ne vise pas le quasi temps réel comme les tuiles de cet article.
  • Non, mais on peut récupérer des tuiles ne contenant que le texte nécessaire et patcher celles que l’on possède déjà.

• Ce serait bien si cela signifiait qu’OSMAnd et OrganicMaps allaient enfin unir leurs forces pour sortir l’ultime application de cartographie libre et open source.

  • Les deux applications utilisent principalement des données cartographiques téléchargées et hors ligne, prétraitées dans leurs propres formats.
    Les tuiles vectorielles au format MVT ne sont pas du tout adaptées à la navigation ni à la recherche. Cela ne veut pas dire qu’on ne pourrait pas bricoler quelque chose avec, mais ce serait assez forcé.
  • Il ne peut pas y avoir une application de cartographie ultime unique, parce que les cas d’usage diffèrent.
    Par exemple, OSMAnd propose beaucoup de fonctions avancées très utiles aux contributeurs OSM, mais qui risqueraient seulement d’encombrer l’interface dans une application destinée au grand public.
  • J’aimerais au moins qu’elles puissent partager les tuiles cartographiques, afin d’éviter de dupliquer des gigaoctets d’espace pour les mêmes cartes.

• https://marble.kde.org/ disposait déjà depuis neuf ans de sa propre implémentation d’une couche OSM vectorielle en streaming, et j’attendais depuis longtemps que quelque chose de similaire apparaisse dans d’autres applications de cartographie OSM.
  Sur les applications OSM Android, télécharger des cartes de plusieurs centaines de mégaoctets par gros blocs, pays par pays, a toujours posé un problème d’espace de stockage. Je suis vraiment content de voir qu’un standard commence enfin à émerger, et j’espère qu’il sera adopté et amélioré par plusieurs applications. Beau travail.

  • J’ai cherché l’application Marble sur Android, mais elle n’est ni sur le Play Store ni sur F-Droid. Le lien Play Store du site renvoie une 404. Le projet a été abandonné ?