La dernière version de GDAL, la 1.7.1, améliore encore l’utilisation de sources de données distantes de type WMS. La documentation reste toutefois succinte et ne dévoile pas les possibilités offertes par les « minidrivers ». Rappelons le principe de base : il s’agit de pouvoir considérer une ressource distante (WMS, TMS) comme une source de données GDAL standard et de pouvoir la manipuler comme s’il s’agissait d’un raster en local. Ca peut déjà rendre service avec le WMS. Mais l’intérêt principal réside en sa capacité à exploiter des ressources tuilées. Qui n’a jamais été frustré de ne pas pouvoir exploiter un service WMS-C ou TMS car la projection proposée ne correspondait pas à son besoin ? Les « minidrivers » permettent de contourner cet obstacle. Comment ? Assez simplement en fait. GDAL va considérer le résultat que vous lui demandez (étendue géographique, projection…), récupérer les tuiles correspondantes, en découper le superflu, les assembler en une seule image et reprojeter le tout dans ce que vous aurez demandé. La configuration de l’accès au service se fait via un petit fichier XML simple à renseigner :
<GDAL_WMS>
<Service name="WMS"> --> Description du type de service (WMS, TMS...)
<Version>1.1.1</Version> --> Version du service
<ServerUrl>http://labs.metacarta.com/wms-c/Basic.py?</ServerUrl>
--> Url d'accès au service
<Layers>basic</Layers> --> Couches à récupérer
</Service>
<DataWindow> --> Configuration plus générale de la données distante
<UpperLeftX>-180.0</UpperLeftX> --> Sur ces quatres lignes, la bbox
<UpperLeftY>90.0</UpperLeftY>
<LowerRightX>180.0</LowerRightX>
<LowerRightY>-90.0</LowerRightY>
<TileLevel>19</TileLevel> --> Le nombre de niveaux dans le cache
<TileCountX>2</TileCountX> --> Le nombre de tuiles en X à la plus
faible résolution (niveau 0)
<TileCountY>1</TileCountY> --> Le nombre de tuiles en Y à la plus
faible résolution (niveau 0)
</DataWindow>
<Projection>EPSG:4326</Projection> --> Projection de la source de données
<BlockSizeX>256</BlockSizeX> --> Largeur des tuiles
<BlockSizeY>256</BlockSizeY> --> Hauteur des tuiles
<BandsCount>3</BandsCount> --> Canaux de couleur dans l'image
(ici, 3 pour RGB)
</GDAL_WMS>
Avec ces informations, GDAL se retrouve capable de traiter la ressource distante comme une donnée locale. Mais ce n’est pas tout. MapServer pouvant utiliser un tel fichier de configuration XML comme source de données d’un LAYER, on peut connecter le service distant à un contexte MapServer particulier, et créer un service WMS non tuilé exploitant des données distantes tuilées. Pratique pour les outils SIG bureautiques par exemple, qui restent incapables d’exploiter le WMS-C !
La configuration d’un tel LAYER dans MapServer est assez basique :
LAYER
NAME test_wms_c
DATA "wms_c.xml"
METADATA
"ows_title" "Couche WMS-C réassemblée"
END
TYPE raster
PROCESSING "OVERSAMPLE_RATIO=1" --> Ne pas récupérer
plus de tuiles que
nécessaire (directive pour GDAL)
PROCESSING "RESAMPLE=BILINEAR" --> rééchantillonner l'image
STATUS ON
PROJECTION
"init=epsg:4326"
END
END
On peut alors reprojeter la ressource initiale, ainsi que l’exploiter sur des échelles intermédiaires non prévues dans le tuilage. Attention quand-même à ne pas trop en faire, car les tuiles reprojetées et rééchantillonnées ne seront pas forcément très belles à voir. L’idéal reste quand-même de conserver au moins la projection initiale.
En résumé nous avons donc :
ressource distante tuilée, définie sur certaines échelles
et une projection spécifique
|
|
GDAL : calcule les requêtes à effectuer,
récupère les tuiles, les assemble,
reprojette si demandé,
découpe si nécessaire
|
|
MapServer : publie la nouvelle ressource pseudo-locale
en toute liberté (projection, échelles...) mais
avec une qualité du rendu potentiellement
dégradée (en fonction des transformations effectuées).
Pour les obsessionnels, oui, on peut aussi mettre en cache la ressource MapServer locale. Mais pas besoin de TileCache pour cela. Les « minidrivers » intègrent un mécanisme de cache qui permet à GDAL de stocker localement les tuiles récupèrées et ainsi de pouvoir les réutiliser plus tard. Pour ce faire, il suffit de rajouter un bloc « cache » dans le fichier XML (voir la doc pour cela).
Mais je sens déjà la question venir chez tous les habitués des caches… Comment GDAL fait-il pour déterminer les résolutions et la grille à utiliser ? Ah, bonne question. Pour les résolutions, autant le dire tout de suite, il suppose unilatéralement que chaque niveau vaut la moitié du précédent, ou que chaque tuile se subdivise en quatre si vous préférez. C’est l’approche standard, mais si on vous demande du 25k, 20k,15k,10k,5k, ça ne va pas être possible.
Pour les limites de la grille, l’exemple plus haut se base sur une grille standard WGS sur le monde entier, et le TileCount permet de calculer l’emprise des tuiles du premier niveau, puis des niveaux suivants. Pour des emprises plus spécifiques, on peut aussi utiliser TileX et TileY, qui représentent des valeurs à ajouter pour gérer un décalage de la grille sans toucher à l’extent globale.
Les domaines d’application sont nombreux. On peut citer d’emblée :
- L’intégration de données tuilées dans des clients non prévus pour cela
- La reprojection de données tuilées
- L’utilisation de données tuilées à des zooms spécifiques non disponibles
- L’alignement des grilles de deux ressources tuilées configurées différemment
- L’exploitation en pur WMS de données lourdes à générer (Open Street Map par exemple)
- Et sans doute bien d’autres problèmes d’exploitation que l’on rencontre.
Ainsi, ce petit exemple illustre bien, une fois de plus, les étonnantes possiblités offertes par MapServer et GDAL quand ils sont utilisés de concert. Plus que le strict respect des normes, c’est la liberté qu’ils donnent aux utilisateurs pour résoudre leurs problèmes qui est précieuse.
