Les tuiles vectorielles… Qu’elle est donc cet objet que vous voyez fleurir partout dans le merveilleux monde des SIG ?
Voila de bonnes bases sur ce format dédié au partage des données SIG sur le web.
Principe
Le tuilage vectoriel est un système de conditionnement des données permettant d’optimiser les échanges entre un serveur et un client. Les tuiles (ou dalles) vectorielles sont en fait des paquets de données vectorielles (1 tuile = 1 paquet).
Mais pourquoi l’utiliser ? Parce que c’est mieux…
Ça c’est dit !
Classiquement, en web SIG, il y a un client (un navigateur web en règle générale) et un serveur SIG (un logiciel de web SIG). Lorsque le client consulte des données, le serveur SIG récupère toutes les données présentes dans l’emprise visualisée, fait un rendu cartographique vectoriel et l’envoie sous la forme d’un gros paquet de données : c’est complet mais c’est bien lourd.
Le problème avec ce système c’est que les géométries peuvent dépasser de l’emprise visualisée, ce qui implique la récupération de données géométriques inutiles car lorsque l’utilisateur changera d’emprise, un nouveau rendu sera fait puis envoyé.
D’autre part, le client ne possède pas de copie des données donc lorsqu’il interroge un objet, une requête est faite au serveur qui récupère l’information pour la renvoyer au client.
Les tuiles vectorielles changent complètement cette façon de fonctionner.
Les données sources sont découpées en tuiles carrées contenant à la fois la géométrie et les attributs.
Le client ne récupère que les données de l’emprise consultée (avec un peu de débordement mais généralement moins que sans tuilage). Les données pouvant être prégénérées, le serveur SIG est ainsi moins sollicité lors de la consultation.
Les tuiles récupérées par le client sont légères car elle ne contiennent que des données vectorielles et sur une faible emprise. Elles peuvent être mises en cache ce qui évite d’avoir à les télécharger de nouveau sur une emprise déjà visualisée.
Le rendu cartographique (thématisation, étiquettes…) est opéré côté client (par le navigateur, via du JavaScript) ce qui évite la sollicitation du serveur SIG. Il est même possible de changer le style des données à la volée, sans avoir à télécharger de nouveau les données.
L’interrogation des données est également gérée côté client car les données sont disponibles localement, le navigateur peut donc directement y accéder directement.
Format
Il existe plusieurs formats de tuiles vectorielles dont les premiers remontent à 1966, au tout début du SIG. Aucun format ne dominant le marché, c’est en 2014 que le format Mapbox Vector Tile (MVT) est apparu et a rapidement dominé tous les autres. Nous allons nous concentrer sur celui-ci.
Les spécifications relatives à ce format sont disponibles ici :
L’encodage des données se fait au format Google Protocol Buffers et l’extension des fichiers doit être le « .mvt », cependant on trouve beaucoup de services dont les fichiers portent l’extension « .pbf » qu’il ne faut surtout pas confondre avec le format des fichiers produits par OpenStreetMap qui, même s’ils possèdent la même extension, ne sont pas structurés de la même façon.
Vous pourrez également trouver le format TileJSON qui est en fait un fichier au format JSON utilisé pour décrire un jeu de données tuilées. Il contient les url pour récupérer les données, le nom des couches disponibles dans le jeu de données ainsi que diverses autres informations. Les spécifications sont disponibles ici :
Le système de tuilage repose sur la projection Web Mercator (EPSG:3857) et le schéma de tuile Google.
Tuilage à la Google (Google tile scheme)
Il s’agit d’une spécification développée par Google pour son outil Google Maps et permettant de découper le globe terrestre en tuiles de plus en plus petites au fur et à mesure que l’on zoom.
Dans les faits, on considère le monde comme s’étendant entre les longitudes -180° et +180° et les latitudes -85,06° et +85,06° ce qui représente un plan carré dans la projection Web Mercator (EPSG:3857).
Le découpage est ensuite réalisé se la façon suivante : nombre de tuiles = 2(niveau de zoom x 2)
| Niveau | Nombre de tuiles | Largeur de la tuile en degré (de longitude) | Largeur de la tuile en mètres (projetés) | Exemple de secteur visualisé (avec un écran de résolution 150 ppp et des tuiles de 256px) |
|---|---|---|---|---|
| 0 | 1 | 360 | 40 075 017 | Monde entier |
| 1 | 4 | 180 | 20 037 508 | |
| 2 | 16 | 90 | 10 018 754 | |
| 3 | 64 | 45 | 5 009 377 | |
| 4 | 256 | 22,5 | 2 504 689 | |
| 5 | 1 024 | 11,25 | 1 252 344 | Europe |
| 6 | 4 096 | 5,625 | 626 172 | France |
| 7 | 16 384 | 2,813 | 313 086 | |
| 8 | 65 536 | 1,406 | 156 543 | Région française |
| 9 | 262 144 | 0,703 | 78 272 | |
| 10 | 1 048 576 | 0,352 | 39 136 | Département français |
| 11 | 4 194 304 | 0,176 | 19 568 | Paris et sa banlieue |
| 12 | 16 777 216 | 0,088 | 9 784 | |
| 13 | 67 108 864 | 0,044 | 4 892 | Paris intra-muros |
| 14 | 268 435 456 | 0,022 | 2 446 | Petite ville |
| 15 | 1 073 741 824 | 0,011 | 1 223 | Petit village |
| 16 | 4 294 967 296 | 0,0055 | 611 | |
| 17 | 17 179 869 184 | 0,0027 | 306 | Quartier |
| 18 | 68 719 476 736 | 0,00137 | 153 | Rue |
| 19 | 274 877 906 944 | 0,000687 | 76 | |
| 20 | 1 099 511 627 776 | 0,000343 | 38 | Bâtiment |
Les tuiles sont numérotées en prenant pour origine (0,0) le coin Nord-Ouest (180°O, 85,06°N). Il devient alors possible de stocker les tuiles prégénérées dans un système de répertoires structurés de la façon suivante : Z/X/Y (ou Z/Y/X selon les outils).
Pour les rasters tuilés, chaque tuile mesure généralement 256 pixels de côté mais d’autres tailles peuvent exister (512 px par exemple). Dans le cas de tuiles vectorielles, une taille en pixel n’a pas de sens mais le rendu est prévu pour que l’affichage de la tuile corresponde à une taille spécifique au niveau de zoom spécifié. Cette taille est en général de 256 pixels également.
Par exemple, au niveau de zoom 2, une tuile s’étendra sur environ 10 000 km de large mais occupera un espace de 256 pixels sur un écran d’ordinateur (pour une carte est zoomée au niveau 2).
Vous trouverez sur cette page une carte affichant les coordonnées des tuiles pour chaque niveau de zoom :
Contenu
Le contenu de chaque tuile est constitué d’un ensemble de couches contenant chacune des objets. Chaque objet contient une géométrie vectorielle et un ensemble d’attributs.
Si vous possédez une url source de tuiles vectorielles au format MVT, il vous est possible de consulter son contenu grâce à ce site :
Vous pouvez consulter un exemple avec les données de la Base d’Adresse Nationale en cliquant ici.
Le stockage des géométries est un peu spécifique car les coordonnées de chaque sommet sont définies par rapport à leur position au sein de la tuile à laquelle il appartient et non plus par rapport à un système de coordonnées mondial. En effet, c’est la tuile qui est placée au niveau mondial.
En plus de cela, pour les géométries contenant plusieurs sommets (ligne, polygone et multi-géométrie), seules les coordonnées du premier sommet sont spécifiées, les coordonnées suivantes sont définies par rapport au précédentes via un ensemble de commande de traçage :
Prenez la multiligne suivante :
- Line 1:
- (2,2)
- (2,10)
- (10,10)
- Line 2:
- (1,1)
- (3,5)
Le tracé est ainsi encodé de la façon suivante :
- MoveTo(+2,+2) : se rendre aux coordonnées (2,2) : début de la première ligne.
- LineTo(+0,+8) : tracer une ligne de 0 unité sur l’axe X et 8 unités sur l’axe Y depuis le précédent sommet.
- LineTo(+8,+0) : tracer une ligne de 8 unités sur l’axe X et 0 unités sur l’axe Y depuis le précédent sommet.
- MoveTo(-9,-9) : se déplacer de -9 unités sur l’axe X et -9 unités sur l’axe Y depuis le précédent sommet : fin de la première ligne et début de la seconde ligne.
- LineTo(+2,+4) : tracer une ligne de 2 unités sur l’axe X et 4 unités sur l’axe Y depuis le précédent sommet.
Cet encodage permet d’optimiser le poids des données d’autant plus que les commandes sont encodées dans un formatage binaire particulier permettant de ne spécifier qu’une seule fois une commande devant être répétée (comme dans mon exemple pour la première ligne, l’instruction « LineTo » n’a pas besoin d’être répétée).
Notez par ailleurs que le format autorise les géométries à dépasser de la tuile, cela peut être utile lorsque des objets sont a cheval sur plusieurs tuiles.
Style
Maintenant que vous connaissez tout des tuiles vectorielles, parlons un peu de style.
Comme indiqué précédemment, le rendu cartographie s’effectue côté client. Il faut donc un fichier qui décrit comment représenter les tuiles, il s’agit du fichier de style.
Mapbox GL JS/Maplibre GL JS
Avant de parler style, parlons technologie.
A l’origine de tout ce dont on parle, il existe la société Mapbox qui a conçue une bibliothèque JavaScript : Mapbox GL JS qui permet de créer des cartes web vectorielles dont le rendu repose sur la technologie WebGL qui permet d’accélérer l’affichage par l’utilisation du processeur graphique (GPU).
Pour fonctionner, cette librairie requiert des données vectorielles tuilées conformes au format Mapbox Vector Tile ainsi qu’un fichier de style lui-même conforme à la spécification Mapbox Style. Cette dernière détaille un ensemble de règles permettant de décrire la façon de représenter les données vectorielles.
En décembre 2020, la société Mapbox a changé de politique et opté pour une licence propriétaire en lieu et place de la licence Open Source précédemment utilisée. Suite à ce changement est né le fork MapLibre GL JS, une copie ouverte (Open Source) de Mapbox GL JS mais qui a depuis évolué de son côté.
Ici aussi on retrouve des données vectorielles tuilées au format Mapbox Vector Tile ainsi qu’un fichier de style répondant à sa propre spécification : Maplibre Style.
A noter que vous pouvez retrouver un ensemble de projets qui utilisent ou soutiennent ces librairies en suivant ces liens :
- Pour Mapbox : la page awesome-vector-tile.
- Pour Maplibre : le site Awesome-maplibre.
Fichier de style
Contenu
Le fichier de style ne contient pas seulement les éléments décrivant le rendu des différentes couches, il va bien au delà.
Au sein de ce fichier, vous trouverez les éléments suivants (disponibilité : MB = Mapbox, ML = Maplibre) :
name(MB & ML) : le nom du style.metadata(MB & ML) : diverses métadonnées.version(ML) : version de la spécification du style.projection(MB) : projection à utiliser pour le rendu (les données doivent elles être au format Web Mercator d’après la spécification).center(MB & ML) : coordonnées du centre de la carte à l’ouverture.zoom(MB & ML) : niveau de zoom à l’ouverture.bearing(MB & ML) : orientation du haut de la carte (0 = nord en haut)pitch(MB & ML) : inclinaison de la carte (pour vue 3D).light(MB & ML) : lumière globale.transition(MB & ML) : paramètre global pour la vitesse des transitions.fog(MB) : effet de brouillard pour les objets lointains.sprite(MB & ML) : base URL for retrieving the sprite image and metadata.glyphs(MB & ML) : A URL template for loading signed-distance-field glyph sets in PBF format.sources(MB & ML) : liste des sources de données (serveur de tuiles vectorielles, raster tuilé, raster dem, geojson, image, vidéo).layers(MB & ML) : liste des couches issues des sources à utiliser (incluant la stylisation de chaque couche).terrain(MB & ML) : configuration du terrain à utiliser (affichage 3D).
Ainsi, le fichier de style se suffit à lui-même en contenant à la fois la description de la mise en forme des données mais également l’origine, la source des données.
Les fournisseurs de données tuilées proposent souvent un fichier de style associé permettant d’utiliser directement les données. Voici quelques sources :
- Les données tuilées de l’IGN.
- Les données d’OpenStreetMap.
- Les données de la Base d’Adresse Nationale (style en version projet).
Éditeur
Le contenu d’un fichier de style n’étant pas forcément trivial à rédiger, il existe des éditeurs. Les plus connus sont les deux suivants :
- Pour le style Mapbox, rendez-vous sur Mapbox Studio.
- Pour le style Maplibre, rendez-vous sur Maputnik.
Les deux outils sont très similaires et permettent d’ajouter des sources, puis d’en choisir les couches à afficher et enfin de les styliser.
Je ne détaillerais pas leur fonctionnement ici.
Consultation des données
Pour consulter les données, il y a deux méthodes :
- Utiliser un outil qui lit directement les données vectorielles et dans lequel vous devez créer la symbologie (QGIS, OpenLayer, Leaflet…)
- Utiliser un outil qui gère les fichiers de style et dans lequel vous n’aurez donc pas à gérer la symbologie (Mapbox GL JS, Maplibre GL JS, OpenLayer via plugin, Leaflet via plugin…)
Cet article vous a plu ?
N'hésitez pas à le partager, il interessera surement certains de vos contacts.
Les thèmes suivants contiennent des articles en lien avec celui-ci, allez faire un tour :
SIG googlemapboxmaplibremvttuile
