Une des fonctionnalités les plus intéressantes de Geoserver est sa capacité à gérer un service d’images en cache. Nous verrons dans cet article comment exploiter complètement cette fonctionnalité.
Petit rappel de la notion de tuilage
Dans l’image suivante vous verrez la représentation de deux modes de fonctionnement d’un serveur de cartes.
A gauche vous avez le fonctionnement d’un serveur classique de cartes:
- une application cliente génère une requête pour afficher une carte
- le serveur reçoit la requête
- il procède à extraire les données nécessaires à la fabrication de la carte à partir d’une base de données contenant les différentes couches géographiques
- le résultat de cette extraction est mise en forme pour constituer la carte demandée
- la carte est transmise à l’application client pour affichage
A chaque requête cliente, le serveur doit interroger la base de données et mettre en forme les données extraites.
L’image de droite montre le fonctionnement d’un serveur avec la fonction « tuilage » activée:
- une application cliente génère une requête pour afficher une carte
- le serveur reçoit la requête
- selon l’emprise de la carte demandée, le serveur sélectionne des images pré-calculées, dans le cache du serveur, correspondantes à l’emprise et le niveau de zoom demandé
- les images sont transmises à l’application client pour affichage
Tout le travail d’extraction et de mise en forme a été réalisé au préalable et une seule fois. Dans cette deuxième configuration il suffit d’un simple calcul pour déterminer quelles images doivent être retournées à l’application client. Le gain de temps et de ressources nécessaires et réellement important.
On produit la carte selon une symbologie de mise en forme,puis on découpe cette image en tuiles de même taille. Ce travail est fait une seule fois pour toutes
Chaque tuile représente les données mises en forme et peut être « servie » très rapidement. Par contre, la seule chose possible est l’affichage car on ne peut pas accéder ni aux données sous-jacentes ni modifier leur mise en forme.
Par contre, si on zoome sur cette tuile, rapidement on va atteindre le niveau de pixellisation. Pour résoudre ce problème, on va créer plusieurs cartes, à différents niveaux de zoom. Chaque carte sera divisée en tuiles. Lors de la réception d’une requête, on calculera le niveau de zoom correspondant et on servira les tuiles correspondantes à ce niveau là.
Typiquement, on procède par pas de 4 tuiles. La couche la plus détaillé est divisée en tuiles, le plus généralement de 256 x 256 pixels. On calculera une couche au-dessus correspondant à 2×2 tuiles ( à partir de 4 tuiles de 256 x 256 pixels on calcule une seule tuile de 256 x 256 pixels). Et ainsi de suite jusqu’au niveau où on ne retrouve qu’une seule tuile.
Cette série de couches est appelée une pyramide.
Tuiles raster et tuiles vectorielles.
Jusque là nous avons parlé d’un serveur de cartes sous forme d’images (raster). Même si les données dans la base de données sont des données vecteur (rues, bâtiments, parcs, …), le rendu est appliqué à ces couches vecteur pour produire une image raster, qui sera le résultat de la requête.
Ce type de service est appelé WMS.
Depuis quelques années, un nouveau type de service permet de fournir des données sous forme de tuiles, appelé WMTS. Dans gGeoserver, ce service est implémenté pour fournir des tuiles de données de type vecteur.
Le principe est le même que pour le tuiles raster:
On divise l’espace en carrés et on extrait les données vecteur (entités) correspondantes à chaque tuile:
Lors de la réception d’un requête, on procède comme pour les tuiles raster: on détermine le niveau de zoom approprié, puis on envoie les données pré-extraites à l’application client.
Génération des tuiles
La procédure de génération des tuiles est la même, qu’il s’agisse de tuiles raster ou vectorielles.
La première étape est l’extraction des données correspondantes à la requête à partir de la base de données.
La plupart du temps ces données sont des données de type vectoriel (point, ligne , polygone).
Les données sont les données correspondantes à la totalité de l’espace possible, pas à une tuile.
La deuxième étape correspond à ce que l’on appelle « généralisation ».
Le processus essaye de ne garder que le niveau de détail nécessaire au niveau de zoom prévu, en effaçant les points superflus.
La troisième étape est la génération d’un fichier permettant de traduire le système de grille utilisé pour le tuilage et un système de coordonnées de référence. Geoserver utilise des gridsets et des gridsubsets. GeoWebCache ne connaît pas de systèmes de référence. Lorsque GeoWebCache envoie une requête au service WMS, il utilise les informations gridset et gridsubset pour convertir son index de tuiles interne en une requête spatiale que le WMS comprendra.
La quatrième étape est un deuxième type de généralisation, mais au lieu de simplifier les géométries en réduisant le nombre de points qui les composent, elle consiste à enlever les entités trop petites ou redondantes.
L’avant-dernière étape et le découpage (clip) en tuiles. Nous n’avons pas encore appliqué de mise en forme des entités. Si on extrait exactement la zone demandée pour chaque tuile, au moment d’appliquer une symbologie nous risquons d’avoir des artefacts au niveau de la jointure des tuiles, comme montré dans cette image.
Geoserver utilise une technique qui retourne une zone légèrement plus grande que celle demandée pour la tuile. Ceci évite les artefacts sur les bords.
Finalement, nous retrouvons la mise en forme des entités avec la symbologie définie dans un fichier SLD:
Ce fichier indique quelles entités on doit prendre en compte, dans quelle fourchette d’échelle elles doivent apparaître dans les tuiles et quel type de symbole il faut utiliser pour les dessiner.
Tuiles raster et tuiles vectorielles.
Nous avons, dans les standards de l’OGC, trois types de service
• WMS – Service de fourniture de cartes
• WMTS – service de fourniture de tuiles
• WFS – Service de fourniture de données
Les tuiles de type raster ou vectorielles sont donc fournies par le même service, le WMTS.
Si les deux types de données sont fournies par des moyens similaires, il y a quand même quelques différences.
Par rapport aux tuiles de type raster, les tuiles vectorielles sont mises en forme par le client et non pas par le serveur. Dans une application OpenLayers, par exemple, vous ne pourrez qu’afficher des tuiles raster avec leur mise en forme d’origine, tandis que pour les tuiles vecteur vous aurez toute latitude pour décider de leur symbologie.
Un seul tuilage peut alors servir à générer de multiples cartes différentes côté client. A cela il faut ajouter que le rendu des vecteurs est amélioré, par rapport aux tuiles raster, pour les écrans haute résolution.
Côté désavantages, il faut noter que les tuiles raster sont plus faciles à utiliser que les tuiles vecteur. Il faut plus de connaissances techniques pour travailler avec des tuiles vecteur.
Vous pourrez alors conclure qu’il est plus intéressant d’utiliser le service de tuiles vecteur en lieu et place du service WFS classique de données vecteur.
Si c’est vrai que les deux retournent des données vecteur / attributaires sans mise en forme, il faut savoir que le service WFS retourne les données sous-jacentes NON MODIFIEES, tandis que le service WMTS retourne les données sous-jacentes MODIFIEES : les entités sont prêtes à être affichées.
Dans le premier cas vous avez accès à la totalité des attributs des entités, tandis que dans le deuxième vous n’avez que les attributs définis dans le fichier SLD du tuilage.
Dans l’article suivant nous verrons concrètement comment mettre en place le service de tuiles raster/vecteur dans Geoserver.
