Archive pour le mot-clef ‘Mapserver’

« Articles plus anciens

Mapserver et GDAL, duo magique

Mardi 20 avril 2010

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.

Mots-clefs : , , , ,
Publié dans News | 2 commentaires »

Retour sur le sprint

Lundi 1 mars 2010

Olivier Courtin nous propose un joli résumé du New York Sprint 2010. Deux posts plus techniques vont bientôt apparaître, quand la fatigue du voyage se sera estompée sans doute… On devrait aimerait alors en savoir plus sur les roadmaps de PostGIS et MapServer quant à leurs versions respectives 2.0 et 6.0. Pour Microsoft Word, ça avait été des évolutions majeures…

Mots-clefs : ,
Publié dans News, SGBD | Aucun commentaire »

MapServer et GeoServer perdent le nord…

Lundi 22 février 2010

En direct du New York City Code Sprint, Paul Ramsey nous transmet cette intéressante carte générée par MapServer :

Carte avec rotation

Inutile d’attraper un torticoli, tout est normal. Ce n’est que l’expression de l’utilisation du nouveau paramètre ANGLE dans MapServer et également disponible dans GeoServer, que chacun des logiciels implémente dans son interface WMS.  L’intérêt principal réside dans le fait que si la carte est bien pivotée, les labels restent lisibles à l’horizontale, ce qui n’était pas le cas avec des rotations appliquées a posteriori, sur l’image finale.

Mots-clefs : ,
Publié dans News | 3 commentaires »

WMS 1.3 et gestion des coordonnées

Mercredi 8 juillet 2009

Comme tout un chacun féru de nouveautés, l’intégration d’une nouvelle version d’un standard international (le WMS de l’OGC) dans un quasi-standard des serveurs cartographiques (MapServer 5.4) me donne envie de l’essayer. Tout le problème fut de trouver un client compatible WMS 1.3. C’est le côté contraignant de l’inter-opérabilité, il faut trouver des agents capables d’utiliser la même norme, et ce n’est pas toujours le cas.

Autodesk proposant un téléchargement gratuit d’Autocad Map 2010 en version 30 jours, je me suis lancé (ou plutôt assis avec un café car le fichier à télécharger fait 2.1 Go !). Je n’avais pas vu Autocad Map depuis la version 2002, j’ai dû avoir la même sensation que le pilote de Caravelle qui se retrouve aux commandes d’un A 380… Rien que le nombre de barres d’outils vous donne l’envie de signer fissa pour une formation accélérée. C’est peut-être pour ça que c’est en téléchargement d’ailleurs.

Après quelques recherches je trouve la fonction d’ajout de couche WMS (il faut cliquer sur DATA dans les pratiques outils de gestion des cartes au dessus de la liste des couches…), avec dans la configuration du serveur un choix de version intégrant le 1.3.0. On touche au but donc. Je saisis ce qu’il faut, choisis une couche en projection Lambert (je ne dirais pas laquelle, pour ne pas raviver de querelle entre les anciens et les modernes, ce n’est pas mon propos). Résultat impeccable, bravo. Je refais un autre test avec une couche non projetée cette fois. Echec, rapport d’erreur un peu obscur… Après de longues recherches, je tombe sur le loup. La norme WMS 1.3.0 impose aux coordonnées de la bounding box d’être en lat,lon pour les systèmes de référence non projetés, et non plus en lon,lat comme pour la version 1.1.1 et comme c’est encore le cas pour les systèmes projetés en WMS 1.3.0. Donc mon AutoCad, qui n’a sans doute pas pris cette subtilité en considération, ou mal, a soumis à MapServer une requête incohérente quant à la BBOX utilisée dans le contexte EPSG:4326. Et l’inter-opérabilité pris fin.

Autre nouveauté du WMS 1.3.0 l’utilisation du paramètres CRS= plutôt que SRS= dans la désignation du système de coordonnées, bien que MapServer accepte encore les deux, avec priorité au SRS. Celui-ci peut d’ailleurs s’affranchir du registre EPSG, le WGS 84 pouvant être désigné par CRS:84 plutôt que EPSG:4326. Ces diverses subtilités n’ont pas manqué de provoquer quelques saines réactions sur la liste MapServer-users dès 2006 !

Mots-clefs : ,
Publié dans News | 12 commentaires »

MapServer, substitution de variable et mise en cache.

Vendredi 12 juin 2009

Vous le savez sans doute, MapServer permet de réaliser du « runtime substitution », soit de la substitution dynamique de variable à l’exécution. En clair, votre requête, CGI ou WMS (ce qui revient peu ou prou au même), intègre un paramètre complémentaire dont la valeur va être interprétée au sein du fichier .map.

Pour être plus clair, imaginons que vous  cartographiez les trajets routiers effectués par des utilisateurs. Chaque utilisateur ne doit voir que ses propres trajets parce qu’on est pas chez Big Brother. En rajoutant un paramètre user_id à la requête envoyée à MapServer, on peut filtrer le contenu renvoyé par le fichier .map. La chaîne SQL de récupération des données devient alors :

DATA « the_geom from trajets WHERE user_id = %user_id% »

C’est tout simple donc. En intégrant entre pourcentages le même paramètre que celui envoyé dans la requête, MapServer lui substitue la valeur associée, et le contenu renvoyé est ainsi filtré. On peut aussi ajouter des expressions régulières pour valider les valeurs envoyées et éviter une bonne grosse SQL injection.

Tout cela est connu et très pratique. Ca tord un peu le coup à l’aspect normalisé quand c’est utilisé en WMS, mais les normes ça sert aussi à être dépassé. Néanmoins, il reste un obstacle à la mise en cache des résultats. TileCache par exemple, qui joue un rôle de proxy, ne fait suivre au serveur WMS que les attributs de la norme WMS, et génère alors une erreur car %user_id% sans rien y subsitituer n’est pas utilisable en SQL. C’est pourtant pratique de mettre aussi ce type de résultat en cache.

Mais il y a une solution ! L’Alaska Ocean Observation System publie un patch qui permet de faire suivre au travers de TileCache n’importe quel attribut complémentaire pour peu qu’il soit déclaré dans le tilecache.cfg (fichier de configuration du cache). Ils l’ont fait pour faire du WMS-T (WMS temporel, enrichi d’une variable temporelle pour récupérer des observations par exemple), et étendu à tout attribut complémentaire, ce qui mérite d’être salué.

Une des complications impliquée par ce genre de techique est la multiplication des arborescence, puisqu’un cache spécifique sera créé pour chaque valeur du paramètre. Avec des milliers d’utilisateurs dans mon exemple, ça peut rapidement poser problème. Mais pourquoi alors ne pas utiliser un cache mémoire (Tilecache avec MemCache), d’une taille pré-définie ? Avec quelques giga-octets, on pourra y stocker un bon nombre de tuiles, sans jamais surcharger le système. Les plus récemment créées remplaceront les plus anciennes quand le cache sera plein. Cette méthode s’adapte aussi assez bien au temps (presque) réel, puisqu’on peut paramétrer le durée de vie des données stockées par MemCache. Pour un suivi de conditions de circulation (bouchons…), on peut ainsi quand-même profiter d’un cache qui dure le temps de la validité de la donnée. Mais même 10 minutes, si de nombreux utilisateurs se connectent, c’est un considérable allégement de la charge système.

Petit résumé :

Dans OpenLayers :

layer = new OpenLayers.Layer.WMS("Couche dynamique en cache",
"http://serveur.com/tilecache/",
{layers: 'layer_test',format:'PNG',user_id:myUserId},
{isBaseLayer:true,visibility:true});

on a donc surchargé la définition de la couche avec un paramètre user_id qui prend la valeur de la variable javascript myUserId.

Dans Tilecache.cfg :

on ajoute à la définition du layer WMS : extra_params=user_id

Dans le MapFile :

On intègre le paramètre à la chaîne DATA (ou FILTER, ou EXPRESSION, ou CONNECTION selon les besoins) : DATA « the_geom FROM trajets WHERE user_id = %user_id% »

on ajoute une ligne dans le bloc METADATA de la couche pour valider le user_id:

‘user_id_validation_string’ ‘^[0-9]{1,2}$’ qui impose un entier fait de deux chiffres au maximum.

Mots-clefs : , ,
Publié dans News | 2 commentaires »

« Articles plus anciens