Comme souvent la notion d’éclaircissement s’accompagne d’une dose d’obscurcissement, voici un petit résumé de ce que j’ai pu en comprendre…

1. Comment tester ?
   Sans doute pour répondre aux divers besoins exprimés, le document prévoit 2 scénarii de test : soit on teste le service depuis son point d’accès sur internet, soit on le teste depuis l’intérieur de l’infrastructure informatique. Dans ce dernier cas, il faut retrancher le temps de transport réseau pour mesurer la performance. Il s’agit en fait d’établir la différence de temps de transfert entre ce mode et le mode précédent, et de l’appliquer aux résultat obtenus ainsi. C’est une sorte d’extrapolation des résultats qu’on aurait obtenus en testant depuis l’extérieur faite à partir de résultats obtenus depuis l’intérieur de l’infrastructure. Bon, pour la suite, on partira du principe qu’on suit le scénario 1…
2. Mesure de la performance.
   Il faut pouvoir récupérer une image de 470 Ko (800×600 pixels en 8 bits) en moins de 5 secondes, en situation normale. Mais il ne suffit pas que ça marche une fois. Le protocole de mesure indique qu’il faut effectuer plusieurs tests par heure (au moins 10), en n’interrogeant qu’une couche à la fois, mais en faisant varier la bbox pour éviter les effets d’une mise en cache éventuelle. Au final, 90% des mesures doivent être inférieures à ces 5 secondes (c’est la notion de situation normale).  Le chronométrage doit correspondre au premier bit reçu par le client, et non à la réception de l’ensemble de la réponse.
3. Mesure de charge
   Le nombre minimum de requêtes servies doit être de 20 par seconde.  Cette mesure doit être effectuée pendant 1 minute, en envoyant 20 requêtes simultanées par seconde (ce qui associé à l’exigence précédente suppose une bande passante d’au moins 75 Mbps). Pour éviter les biais, il est préférable de réaliser ce test en ayant désactivé l’accès public au service. Concrètement, un test avant la mise en production semble idéal, puis régulièrement (mensuellement selon la recommandation). Dans les 20 requêtes minimum envoyées par seconde, il faut prévoir 10 % de GetCapabilities et 90 % de GetMap (faits selon les exigences de performance vues précédemment).
4. Disponibilité.
   Le service doit être disponible (mais sans forcément atteindre les exigences précédente) 99 % du temps, soit 3,63 jours d’indisponibilité par an au maximum.  Il faut faire au minimum 10 requêtes par heure, qui peuvent être les mêmes que celles utilisées pour mesurer la performance. Néanmoins, les périodes de maintenance ne rentrent pas en compte dans cette mesure, pour peu qu’elles aient été signalées aux utilisateurs (via les portails ou une notification par mail) une semaine à l’avance.

En résumé, si l’on met de côté la mesure de charge qui est particulière, il faut mettre en place un système qui envoie des GetMap sur un layer, en 800×600 avec bbox variable (mais valide, c’est-à-dire incluse dans la bbox du layer tel qu’exposée par le GetCapabilities) plus de 10 fois par heure. Au moins 99 % de ces requêtes doivent aboutir à un résultat (HTTP 200 et image non vide), et le premier bit de ce résultat doit être obtenu en moins de 5s dans au moins 90% des cas. Vous remarquerez néanmoins sans doute un paradoxe : les ViewServices peuvent utiliser du WMS ou du WMTS, mais les indicateurs de QoS ne prévoient pas de mesure particulière sur du GetTile, équivalent en WMTS du GetMap. Si votre service de visualisation WMS ne répond pas aux exigences de qualité de service, vous n’avez donc plus qu’à le basculer en WMTS !

La première est une carte dynamique provenant du site mapmatters.org. La seconde est une carte tirée de la présentation « State of Play of OGC Web Services across the Web » faite à l’occasion des conférences INSPIRE 2010 (cf. ici).

Ces cartes sont intéressantes. Elles mettent en évidence des disparités entre Etats que l’on n’aurait pas soupçonnées au premier abord. On constate en effet une espèce de vacuité au niveau de certains pays alors que d’autres semblent gonflés à bloc. Nos voisins immédiats ont l’air bien plus actifs que nous. On constate également une drôle de répartition des services en France. Enfin, pas vraiment une répartition, plutôt une concentration (à Orléans). Il doit y avoir quelque chose là-bas qui adore les services web.

Comme pour toute carte, il ne faut pas essayer de leur faire dire ce qu’elles ne disent pas. Ces documents ne doivent pas être interprétés comme des indicateurs d’une meilleure réussite de certains Etats par rapport à d’autres (pour cela il faudrait que l’on considère que la mise en œuvre de services web puisse être considérée comme une réussite en soi). En particulier, ces représentations cartographiques ne disent rien sur la qualité des services, sur leur utilisation ni sur la quantité des données mises à disposition.

J’en profite pour noter au passage que mon OWS Search Engine semble avoir été utilisé par les auteurs de l’anamorphose européenne illustrée ci-dessus (cf. ici).

Le problème se situe au niveau du calcul de la BBOX de la couche en coordonnées géographiques (WGS84), dont le résultat est exposé dans la balise EX_GeographicBoundingBox du GetCapabilities. Le calcul de cette BBOX se fait sans vérifier que le méridien d’origine de la projection source de la donnée est bien Greenwich, qui est celui utilisé par le WGS84. Dès lors, si vos données sont dans un système de référence utilisant le méridien de Paris comme origine (les Lambert français de la NTF par exemple, à la différence du Lambert 93 (RGF93) qui utilise Greenwich plus un décalage), la BBOX en WGS84 sera erronée car décalée de plus de 2 degrés vers l’ouest.

Bon, mais qu’est-ce que ça change en pratique ? Je suis sûr que nombre d’entre vous ont déjà utilisé MapServer en WMS 1.3.0 sur ce type de projection sans rencontrer de problème… Il se trouve que certains logiciels clients WMS (l’excellent QGis notamment), plus malins que d’autres, se servent de cette information pour déterminer l’emprise de la couche (quelle que soit la projection utilisée pour l’affichage d’ailleurs), et n’envoient donc pas de requête au serveur WMS quand la vue se situe à l’extérieur de cette emprise, afin de ne pas solliciter inutilement le serveur. Finaud donc. Si vous publiez des données France entière, il y aura recouvrement, et donc pas de problème (à moins peut-être de zoomer sur Strasbourg par exemple. A tester sur vos services WMS 1.3.0 préférés avec QGIS. J’en ai déjà trouvé un…). Mais si l’emprise de vos données est suffisamment étroite (une agglomération par exemple), vous ne verrez tout simplement rien là où vous comptiez les voir apparaître, car d’après le GetCapabilities les données ne se trouvent pas là du tout. Vous ne verrez non seulement rien, et certainement pas d’erreur, et vous risquez de passer quelque temps (je parle d’expérience) à vous creuser la tête pour comprendre ce qui ne va pas dans votre configuration. Sauf que la configuration va bien. Là où ça devient énervant, c’est que les clients WMS qui envoient comme des bourrins des requêtes au serveur où qu’on se situe, ignorant par là la présence et le rôle de la balise EX_GeographicBoundingBox, ces barbares donc, vont eux recevoir une réponse correcte, puisque la reprojection de la donnée elle-même fonctionne normalement. Funeste sort que celui des clients WMS les plus exigeants, les plus respectueux de l’esprit de l’inter-opérabilité, induits ainsi en erreur par un calcul approximatif.

Mais heureux dénouement qui voit les lecteurs assidus de ce blog non seulement informés mais dépannés par un patch tout frais déposé sur le bug-tracker de MapServer ! Pour l’utiliser, il suffit de l’appliquer (commande patch mapows.c wms_1.3.0.patch) au fichier source puis de recompiler et remplacer son mapserv par le nouveau. Il devrait également être rapidement disponible dans la version officielle.

Ce document volumineux (plus de 300 pages) est riche en informations pour ceux qui s’intéressent au déploiement de services WMS dans le cadre d’INSPIRE. Ses annexes décrivent comment paramétrer des services motorisés par ArcGIS et MapServer et comment les consommer depuis une variété intéressante de clients (Gaia, WorldWind, Google Earth et le portail OneGeology notamment).

La confrontation de ce document au guide technique des services de visualisation d’INSPIRE est également instructive. Le premier point qui saute aux yeux : le livre de recettes écossaises propose d’utiliser WMS 1.1.1 (avec MapServer) et WMS 1.3 (à l’aide d’ArcGIS) alors que le guide technique d’INSPIRE recommande WMS 1.3. La volonté de continuer à supporter WMS 1.1.1 est logique tant la quantité de services ne supportant pas WMS 1.3 est importante. Il est également possible que ces recettes datent de l’époque où MapServer ne supportait pas encore WMS 1.3.

Le deuxième point qui a attiré mon attention réside dans la manière de gérer le multilinguisme. Le document n’est pas très bavard sur ce sujet. Il fait l’impasse sur la présence du paramètre LANGUAGE dans les URL des requêtes adressées aux services WMS. Par contre, il recommande de déployer autant de services que de langues à supporter. Ainsi, chaque service n’a qu’une langue à gérer. Les spécificités de chaque langue peuvent donc être gérées au niveau de chaque service déployé. Cette solution est suggérée par moment (mais pas de manière homogène) dans la version 2.12 du guide technique d’INSPIRE. Elle a l’avantage d’être facilement mise en œuvre avec les logiciels actuellement disponibles sur le marché. Cette approche du multilinguisme ne me satisfait guère et je ne serais pas étonné qu’elle disparaisse totalement du guide technique d’INSPIRE dans ses prochaines versions au bénéfice d’une solution basée sur l’emploi du paramètre LANGUAGE utilisé de manière homogène pour toutes les opérations de WMS.

Un dernier point qui vaut la peine d’être mentionné : pour ce qui est de la sécurité et de l’authentification des utilisateurs (dans le cas où l’accès à certaines opérations ou données ne doit pas être libre), le document fait un rappel de quelques standards et outils qui pourraient être employés. Aucune recommandation claire ou tranchée n’est faite sur ce sujet. Ce n’est pas très étonnant tant les solutions n’ont pas l’air d’être mûres sur le sujet (pour s’en convaincre il suffit de voir à quel point ce sujet n’avance guère du côté de l’OGC). On peut toutefois noter l’implication d’EDINA (l’un des contributeurs au livre de recettes) dans l’organisation d’un prochain test d’interopérabilité (Interoperability Experiment) de l’OGC sur l’emploi conjoint de Shibboleth et de services web géospatiaux (cf. ici).

Une lecture intéressante qui laisse tout de même une légère impression d’inachevé. Celle-ci n’est pas uniquement imputable aux auteurs. En effet, reconnaissons que certains sujets ne sont pas tout à fait mûrs à la fois du côté de la Commission Européenne et du côté des solutions logicielles (pour ne pas citer l’OGC, les éditeurs et les projets libres). Les auteurs en sont conscients puisqu’ils insistent sur le fait que ce document est destiné à évoluer. Ils annoncent également qu’un livre de recettes pour WFS devrait voir le jour en 2010 ou 2011.

Quelques points qui ont éveillé mon intérêt :

• le Forum Français de l’OGC (avec l’aide de l’AFIGEO) a commencé un travail de rédaction de fiches en français sur les standards de l’OGC afin de démystifier la chose. La première fiche, consacrée à WMS, a été produite et est disponible ici ;
• des clefs USB du projet GIGAS étaient disponibles en libre-service. Elles contiennent l’ensemble des résultats de ce projet Européen visant à émettre des recommandations quant à l’emploi des standards de l’information géographique. Ces recommandations sont basées sur l’analyse des standards, exigences et retours d’expérience de différents projets (dont INSPIRE, GMES et GEOSS). Très intéressant même si la quantité d’information est importante (et en anglais) ;
• une vidéo réalisée par une dizaine d’éditeurs de services et clients WMS membres du Forum français de l’OGC montrant le niveau d’interopérabilité que l’on peut atteindre à l’aide de leurs outils favoris (des produits libres faisaient également partie de la démonstration). Chaque éditeur disposait de 5 minutes pour démontrer le niveau d’interopérabilité de sa solution (en exploitant à la fois les couches de données qu’il publiait et celles publiées par les autres éditeurs). Cette vidéo est intéressante : elle brosse un rapide paysage des solutions disponibles sur le marché français tout en introduisant de manière concrète les travaux de l’OGC. C’est le premier exercice de ce genre mené par le Forum français. Gageons que l’exercice se poursuivra l’année prochaine avec des ambitions encore plus élevées ;
• une présentation des Technical Guidances des View Services d’INSPIRE faite par Didier Richard de l’IGN : l’idée générale était de présenter les recommandations d’implémentation des services de visualisation d’INSPIRE (dans le cas d’une mise en œuvre sur la base de services WMS 1.3.0) et de souligner les différences entre les spécifications de l’OGC et les recommandations d’INSPIRE.

<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.

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 !

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.

1. L’installation

Simplissime ! Récupérez une archive des sources sur le site de tilecache (http://www.tilecache.org/), et décompressez-la dans un répertoire publié sur le web (/tilecache dans ce qui suit).

Autorisez l’exécution des cgi pour ce répertoire :

<Directory /usr/local/apache2/htdocs/tilecache>
AddHandler cgi-script .cgi
Options +ExecCGI
</Directory>

Editez le fichier tilecache.cfg et spécifiez un répertoire de stockage des dalles, par exemple :

base=/usr/local/apache2/htdocs/tileFolder

(NB : ce répertoire doit exister et être accessible en écriture à l’utilisateur apache).

Vous pouvez déjà tester en chargeant la page http://nom_du_serveur/tilecache/. Vous devriez voir apparaître une interface OpenLayers avec une carte du monde. Vérifiez le contenu de votre répertoire de stockage, vous devriez y voir un sous-répertoire « basic », nom de la couche WMS chargée par défaut, contenant des sous-répertoires numérotés.

Arrivé là, vous êtes déjà en train de mettre en cache les couches WMS que vous exploitez. Le reste n’est donc plus qu’une question d’optimisation.

1. La configuration des ressources WMS.

Vous avez sans doute d’autres données à exploiter que les données proposées par défaut. Pour cela, il faut rajouter ces entrées dans le fichier tilecache.cfg, en commençant par le nom de la ressource (layername) entre crochets. A noter que le nom que vous donnez à la ressource est complètement libre, mais que c’est lui que vous devrez utiliser lors des appels à TileCache, depuis OpenLayers par exemple. Voici un exemple complet de configuration d’une ressource :

[geosignal]
type=WMS
url=http://www.geosignal.org/cgi-bin/wmsmap
bbox=-50000,1200000,1400000,2700000
extent_type=loose
extension=png
layers=RASTER4000K,RASTER1000K,RASTER500K,RASTER250K,\
RASTER100K,RASTER50K,RASTER25K,RASTER5K
resolutions=2116.666666667,1058.333333333,529.166666667,\
264.583333333,132.291666667,66.145833333,26.458333333,\
13.229166668,6.614583334,2.645833334,1.322916667
levels=11
srs=EPSG:27572

La pluplart des paramètres sont facilement compréhensibles. Après la bbox cependant, on trouve un extent_type=loose. Il sert à autoriser la création de dalles en dehors de la bbox. Pratique pour éviter les dalles roses dans OpenLayers, quand l’étendue de la carte est plus grande que celle de votre ressource. L’omettre pour forcer les requêtes à se situer dans la bbox. Quant aux résolutions, c’est une manière d’exprimer les échelles. On peut les calculer assez facilement (hmmm…) : les dalles par défaut font 256×256 px. Si les images issues du serveur WMS sont en 96 dpi, chaque dalle fera donc (256/96) = 2,666666667 pouces, soit 2,666666667 x 2.54 = 6,773333333 cm. Au 100000e, cela représente donc 6773,333333 mètres, ce qui ramène à (6773,333333/256) = 26,458333333 m/pixel. La résolution pour le 100000e est donc de 26,45833333, et on peut alors facilement calculer les autres par simple péréquation.

Une autre option peut s’avérer utile, c’est metaTile=true. Elle permet d’envoyer des requêtes sur de larges extents, qui sont ensuite redécoupées en 256 x 256. C’est pratique à plus d’un titre. D’une part c’est souvent plus rapide de faire une requête que 25 (la metaTile fait 5 x 5 dalles de base par défaut), même si l’image est plus grosse. D’autre part ça diminue le problème du chevauchement des labels entre dalles contigües, puisque cet effet de bord n’apparaît plus désormais qu’en frontières des grandes tuiles, donc 5 fois moins souvent (20 faces externes au lieu de 100). Elle nécessite cependant l’installation (si ce n’est pas déjà le cas) de la librairie Image de Python (http://www.pythonware.com/products/pil/) qui fait le travail de découpe. Malheureusement, elle ne gère pas les PNG entrelacés, et cette option ne pourra donc pas fonctionner si la ressource WMS diffuse ses images dans ce format. Pour MapServer, il faut ajouter un FORMATOPTION « INTERLACE=OFF » dans la définition de l’outputformat PNG.

1. Optimisation 1, utiliser mod_python.

TileCache est un programme en python, configuré par défaut pour être exécuté en mode cgi, c’est-à-dire qu’Apache charge à chaque requête l’exécutable python qui traite le fichier tilecache.cgi. C’est un peu lent. Il vaut mieux charger python dans Apache avec mod_python (à activer dans la liste des modules du httpd.conf, ou à compiler et installer directement) car le fichier est alors directement interprété par l’extension python d’Apache, résidente en mémoire.

Donc ajoutez à votre fichier httpd.conf :

LoadModule python_module modules/mod_python.so

Pas de tilecache.py dans votre répertoire tilecache ? Il suffit en fait de renommer le fichier tilecache.cgi en .py . Il faut par contre aussi adapter votre httpd.conf. La configuration du répertoire tilecache devient :

<Directory /usr/local/apache2/htdocs/tilecache>
AddHandler python-program .py
PythonHandler TileCache.Service
PythonOption TileCacheConfig /usr/local/apache2/htdocs/tilecache/tilecache.cfg
</Directory>

Petite précaution : maintenant que python et tilecache.py sont résidents en mémoire, il vous faudra redémarrer Apache à chaque modification du fichier de configuration de TileCache, qui est devenu une sorte de prolongement d’Apache… Il vaut donc mieux avoir bien configuré toutes ses ressources avant cette étape.

Comparez à présent le fonctionnement de votre TileCache, les performances devraient être sensiblement supérieures.

1. Optimisation 2, pré-remplir le cache.

L’intérêt de cette étape dépend du nombre d’échelles de vos données WMS, ainsi que de leur utilisation. Inutile de pré-générer la France au 5000e si peu d’utilisateurs s’en servent. Mais il est souvent agréable d’avoir les 2-3 premiers niveaux pré-générés. Pour ce faire, utilisez le petit programme tilecache_seed.py ainsi :

python tilecache_seed.py ‘url_du_serveur_WMS’ nom_de_la_ressource niveau_de_depart niveau_de_fin

ce qui donne pour notre ressource définie plus haut :

python tilecache_seed.py ‘http://www.geosignal.org/cgi-bin/wmsmap’ geosignal 0 2

Cela générera toutes les dalles pour les niveaux 0,1 et 2 de la ressource « geosignal », soit les trois premières résolutions décrites dans le fichier tilecache.cfg. Il faut bien veiller à utliser le même nom de ressource que dans le tilecache.cfg.

Une fois la pré-génération réalisée, l’affichage sur ces premiers niveaux devrait être beaucoup plus fluide.

1. Optimisation 3, forcer le cache client.

Vous remarquerez toutefois qu’en revenant sur un niveau de zoom déjà consulté, les images sont le plus souvent rechargées depuis le serveur. Dommage puisqu’elles sont déjà dans le cache client. Mais celui-ci (le navigateur) ne sait pas qu’elles sont encore valides. Il faut donc l’aider à le savoir. Pour ce faire, il faut utiliser le module Apache mod_expires. Il n’est pas chargé par défaut, mais peut l’être facilement en dé-commentant ou ajoutant un LoadModule mod_expires dans le httpd.conf si vous avez un version packagée. Par contre, si vous avez compilé Apache vous-même, il faudra le recompiler avec les options –enable-headers –enable-expires. Oui, j’aurais pu le dire avant… Mais Apache est votre ami, lors d’une réinstallation, le make install n’écrase que les exécutables et préserve le fichier de configuration, les modules et le contenu de cgi-bin. Donc tout va bien.

Une fois l’installation réalisée, il faut régler la durée de mise en cache dans la configuration Apache du répertoire tilecache. Rééditez donc à nouveau le httpd.conf et ajoutez dans la section Directory concernant tilecache :

ExpiresActive on
ExpiresDefault « access plus 6 months »

La durée de mise en cache peut se régler finement. Voir la documentation du module Expires pour cela. Tout dépend de la durée de vie des données sources. Si elles sont soumises à une mise à jour quotidienne, on pourra se contenter d’un ExpiresDefault « access plus 6 hours » . A noter que ceci n’a aucune incidence sur le contenu du cache serveur. Donc si les données sont mises à jour quotidiennement, il faut également purger le cache serveur tous les jours !

A l’issue de cette dernière étape, comment dire, après quelques allers-retours entre niveaux de zooms différents, l’affichage devient quasi-instantané !

1. Optimisation 4, simuler plusieurs serveurs.

La plupart des navigateurs n’effectuent pas plus de deux requêtes simultanées sur un même serveur, mais peuvent par contre en effectuer beaucoup plus vers plusieurs serveurs. En déclarant auprès de votre hébergeur de nouveaux noms de domaines (data1.myserveur.com, data2.myserveur.com, data3.myserveur.com…) pointant tous vers la même IP, les navigateurs pourront alors charger les dalles beaucoup plus vite, pour peu que l’application web que vous utilisez prenne en charge ce genre de requête. Avec OpenLayers il suffit de déclarer non plus une URL, mais un tableau d’URL :

wms_sigma = new OpenLayers.Layer.WMS( "TIGER",
["http://sigma4.openplans.org/tilecache-1.3/tilecache.py?",
"http://sigma3.openplans.org/tilecache-1.3/tilecache.py?",
"http://sigma2.openplans.org/tilecache-1.3/tilecache.py?",
"http://sigma1.openplans.org/tilecache-1.3/tilecache.py?"],
{layers: 'sigma' }, {numZoomLevels: 17});

Si avec tout ça vous allez encore moins vite que GoogleMaps, il ne vous reste plus qu’à acheter un serveur avec 36 Go de RAM et charger votre cache directement dedans. Car TileCache en est également capable !

Version PDF.