La torpeur estivale est propice à l’introspection, et me permet, enfin diront certains, de composer une petite synthèse sur une technologie devenue indissociable du webmapping, à savoir le tuilage cartographique, cette technique qui vise à précalculer ce qui sera affiché ensuite dans le client.

  1. Au commencement était la cartographie dynamique
    Jusqu’en 2005, le webmapping consistait essentiellement en la composition par le serveur d’une carte répondant à la demande d’un client, encore qu’il fut rare… La requête émise contenait la liste des couches à afficher et leur étendue géographique (bbox). Le serveur cartographique (MapServer, ArcIMS…) se chargeait alors de générer cette image à partir des sources de données. Problème : à chaque modification du contenu à afficher (couche en plus ou en moins, étendue géographique), il fallait régénérer l’ensemble de l’image. Les applications de webmapping avaient donc ce défaut ergonomique bien désagréable d’afficher à chaque manipulation de la carte un message d’attente avant la mise à jour de la vue. Mais c’était un peu alors la norme et on s’en accommodait, jouant sur les performances du serveur et l’optimisation de la donnée (indexation, simplification) pour diminuer cette attente.
  2. Google Maps
    Ces petites habitudes furent bouleversées en quelques mois par l’application Google Maps lancée par Google en 2005. D’abord limitée à de l’image satellite, elle intégra rapidement la cartographie routière des Etats-Unis. Surtout, elle rompait avec tout ce qu’on connaissait en termes d’ergonomie en introduisant le concept de carte glissante, « slippy map » en V.O. Les déplacements latéraux étaient continus, fluides grâce à un mécanisme de préchargement de la zone jouxtant la partie visible de la carte. Les déplacements verticaux (zooms avant ou arrière) étaient rapides et ne nécessitaient pas de message d’attente car quasi immédiatement des petits bouts de l’image s’affichaient, laissant à entendre que le reste arriverait vite, ce qui était en effet le cas.
    Tout ceci était rendu possible par l’utilisation d’une technologie de cache déjà éprouvée dans le web généraliste. Il existe des caches serveurs et des caches clients. Google Maps exploitait les deux. A savoir que son application cliente, plutôt que d’envoyer une requête quelconque correspondant à l’exacte emprise demandée par l’utilisateur au serveur, découpait celle-ci selon une grille prédéfinie qui permettait, chaque requête correspondant à un résultat pré-calculable et  ré-exploitable, de préparer l’image (la tuile) et de la stocker au préalable sur le serveur. Dès lors, ce qui nécessitait jusqu’alors de faire intervenir un serveur cartographique accédant aux données à chaque requête se résumait en un calcul simple de la tuile à utiliser et de son renvoi direct comme n’importe quelle image d’un site web. Certes il faut quelque mécanique côté client pour assembler ces tuiles et redonner l’illusion finale d’une image unique formant carte, mais le gain en terme de temps de traitement est énorme. Surtout, cela permet également de multiplier les capacités d’absorption de charge puisque l’impact serveur généré par chaque visiteur est drastiquement diminué.
    Certes, GoogleMaps n’affiche alors qu’une couche à la fois, et deux en tout, mais le sort en est jeté, le succès de l’application fait que la carte glissante devient le standard ergonomique de fait.
  3. OpenLayers et TileCache.
    La réaction de la communauté OpenSource Geospatial ne se fait guère attendre. On ne en effet peut bien longtemps proposer une ergonomie de moindre qualité que celle de Google, même si nos applications, c’est bien connu, sont différentes, affichent de nombreuses couches au contenu parfois personnalisé selon l’utilisateur. Lors du FOSS4G 2006 de Lausanne, une première réflexion fut menée concernant la mise au point d’un standard ouvert de tuilage cartographique. Cette réflexion débouchera rapidement sur la mise au point d’un client capable des mécanismes d’appel et de composition de cartes tuilés, le toujours sémillant OpenLayers, et d’un serveur capable de traiter les requêtes, récupérer les tuiles ou les faire fabriquer par le serveur, le désormais quasi-défunt TileCache.
    Forte de ces outils, la communauté de développeurs d’applications cartographiques se trouvait en mesure de proposer des cartes fluides et intuitives (maintenant que tout le monde savait faire marcher une carte sur ordinateur grâce à GoogleMaps). Et les ennuis pouvaient donc commencer…
  4. Tuilage et prisedetetage…
    Comme on l’a vu plus haut, GoogleMaps avait plusieurs atouts dans sa manche qui lui facilitaient la vie. D’une part GoogleMaps n’affichait qu’une couche à la fois, certes composite pour la cartographie routière, mais sans surcouche. D’autre part, Google disposait d’une infrastructure informatique démesurée qui permettait d’obtenir des performances très élevées.
    L’utilisation de tuilages en cartographie dynamique disons professionnelle s’est heurtée à plusieurs obstacles. Très souvent le nombre de couches à intégrer interdisait de tout tuiler, car certaines couches peu complexes à générer peuvent répondre plus vite en une seule image qu’en 24 tuiles. D’autre part, le volume disque nécessaire au stockage des tuiles pouvait rapidement devenir gigantesque, notamment pour les applications fonctionnant à très grande échelle (cadastre, voirie…). Au 1000e, une tuile de 256 pixels de côté couvre 4538 m2 environ, il en faut donc 220 pour remplir un kilomètre carré. Quatre fois plus au 500e, mais quatre fois moins au 2000e.
    Autre difficulté, le fait d’avoir des niveaux de zoom fixes, puisque devant respecter la grille préconçue du tuilage, et de les faire correspondre à des niveaux d’échelle utiles ou de référence. La saisie d’une échelle libre n’était plus possible, et cela a parfois été dur à faire accepter par les utilisateurs habitués à piloter des SIG leur obéissant au doigt et à l’œil. De même, un tuilage utilise un système de coordonnées et un seul, et les applications durent s’y mettre aussi (sauf à démultiplier le nombre de tuilages dans des projections différentes, mais cela renvoie au problème de l’espace de stockage), rendant parfois complexe les opérations de mise à jour des données et de régénération du cache.
    Mais la difficulté la plus pénible fut certainement quand il s’agit d’utiliser le tuilage du voisin…
  5. Tuilage et inter-opérabilité.
    Nous ne sommes alors pas en nos temps INSPIRéS, ou le service WMS s’échange comme une poignée de main. Non, ça balbutie, et à part quelques services étatiques éclairés (hommage discret à Cartorisque…), c’est encore un peu le temps du chacun pour soi. Mais la sauce est en train de prendre, concomitamment à l’usage du tuilage. Sauf que… Comment on fait pour utiliser un cache cartographique de manière inter-opérable ? Il faut connaître la grille, les niveaux de zoom, la projection… Malheur, la technologie qui vient de redonner des couleurs à la cartographie en ligne se révèle bien peu partageuse, et plus adapté à une relation monogame client-serveur qu’à la multiplicité des partenaires du sulfureux monde interopérable. Il va falloir bricoler…
    Les standards OGC ne sont pas connus pour leur simplicité. Ils sont conçus par de grandes multinationales et agences gouvernementales d’une manière suffisamment obscure et complexe tant dans le processus d’élaboration que dans l’exposition du résultat final pour éviter que le commun des mortels vienne y mettre trop facilement son nez. Le site web de l’OGC est d’ailleurs construit sur ce principe. Les standards OGC n’avaient pas envisagé le tuilage, et le WMS, norme à utiliser pour les services de visualisation (l’affichage de cartes donc), est incapable de véhiculer l’information nécessaire à l’inter-opérabilité tuilée. Quelle est-elle ? Tout simplement la liste des couches, les projections, la définition de la grille, les échelles,… en gros tout ce qui permet de configurer le client afin qu’il interroge proprement le serveur en structurant les appels selon la même grille que celle utilisée pour le tuilage. La réflexion se porte sur du WMS-C, qui serait un WMS capable d’exposer dans ses capacités habituelles celles des couches tuilées. Mais l’OGC n’y prête guère attention, et l’inter-opérabilité des services tuilées passe généralement par le SMTP (envoi de mails décrivant la configuration) ou le HTML (page de configuration, voir ici ou ici, tout en bas). L’OSGEO promeut également la référence normative TileMapService qui permet d’interroger un cache selon un formalisme z/x/y.png ou x est la colonne, y la ligne et z le niveau de zoom de la tuile, l’extension exprimant le format souhaité. Sur des grilles un peu standard (type Spherical Mercator en couverture mondiale) cela est un premier pas, mais si de nombreux services fonctionnent selon ce modèle (GoogleMaps, Bing, OSM…), la standardisation envisagée par le TMS peine à s’imposer, notamment faute de clients compatibles, les logiciels SIG privilégiant le WMS (parfois bien péniblement).
    Il faut attendre 2009 pour voir apparaître de manière un peu structurée le standard OGC WMTS (pour Web Map Tile Service) qui dispose d’un document de capacités (la réponse à une requête getCapabilities) décrivant la structuration de la matrice et exposant la méthode getTile pour récupérer les tuiles elles-mêmes. Son usage est en cours de lente démocratisation, avec le bel exemple récent qu’est son adoption par l’IGN dans le nouveau Géoportail et ses services associés. Nul doute que cet illustre exemple essaimera et qu’on verra bientôt la France et l’Europe se couvrir d’un blanc manteau de serveurs WMTS…
  6. Tuilage et usabilité.
    Il faut néanmoins apporter une légère contradiction au paragraphe précédent qui vit se structurer l’inter-opérabilité tuilée. Plaçons nous du point de vue de l’utilisateur souhaitant accéder à une source de données cartographiques. Pourquoi devrait-il se poser la question de quel service il faut utiliser pour telle ressource cartographique ? Tuilée ou pas ? WMTS ou WMS ? Son client est-il d’ailleurs capable de traiter les deux ? Malgré l’effort louable de normalisation quant à l’accès aux services tuilés, on voit bien qu’il y a en amont un problème de différenciation de services ayant une même fin. Entre WMS et WFS, je sais choisir si je veux de l’image ou du vectoriel. Mais entre WMTS et WMS, comment décider ? Pour un même fournisseur, certaines ressources seront disponibles uniquement en WMS ou en WMTS, d’autres dans les deux. Le tout pour les mêmes données sources et le même résultat visuel. Il manque donc un getCapabilities commun, listant à la fois les ressources WMS et WMTS. Cela ne semble néanmoins pas à l’ordre du jour.
    Mais qui a dit que c’est par une exposition des détails de son cache que le serveur pouvait uniquement aider le client à l’utiliser ? Dans le web en général, où un grand nombre de caches se superposent pour optimiser les temps d’accès, nul besoin de configuration particulière pour afficher la une du Monde ! Malgré tous les mécanismes de cache sous-jacent, la page arrive parfaitement construite. Notre problème est certes légèrement différent (les logiciels SIG ne lisant pas le HTML), mais sans doute que le serveur peut faire un peu plus que passer les tuiles.
  7. Le cache, on le cache (sans récursivité) !
    Quelques esprits ingénieux ont en effet rapidement envisagé d’utiliser le cache non plus pour renvoyer des tuiles précalculées aux clients mais d’utiliser ces tuiles pour composer l’image voulue par le client. Expliquons-nous… En WMS nous avons une requête avec une étendue géographique quelconque à une échelle de rendu quelconque. Dans un cache tuilé, nous avons des tuiles préparées à des échelles particulières sur des emprises particulières. L’idée est donc de sélectionner les tuiles utiles à l’image quelconque demandée par le client, de fusionner, rééchantillonner, découper et renvoyer cette image unique et particulière bien que faite à partir du cache. De la sorte n’importe quel client WMS peut exploiter le cache tuilé sans s’en rendre compte. Certes le serveur a un peu de travail supplémentaire, mais côté inter-opérabilité il y a tout à y gagner. De plus, ces systèmes permettent de gérer couches tuilées et non tuilées depuis le même point d’entrée WMS. Ainsi, plus besoin de séparer les services, le getCapabilities du WMS suffit, et c’est le serveur qui, en fonction de sa configuration et de la requête effectuée (couche, projection…) détermine s’il a un cache correspondant ou s’il doit déléguer le tout au serveur WMS. Pour une carte donnée, on a ainsi qu’une et une seule requête entre le client et le serveur, qui, malgré le travail de fusion à effectuer, est bien plus rapide à traiter que les n requêtes des appels tuilés. Infoterre fonctionne par exemple sur ce mode pour l’affichage du référentiel IGN (Scans et Orthophoto).
    Deux logiciels principaux permettent de faire fonctionner ainsi un service tuilé : MapProxy et MapCache désormais partie intégrante de MapServer. Le premier est écrit en Python et possède beaucoup de souplesse de configuration et d’utilisation. Le second est un module Apache codé en C ce qui apporte d’excellentes performances. MapCache est également capable de déléguer des requêtes selon les paramètres utilisés, par exemple renvoyer un GetFeatureInfo au serveur WMS tout en répondant aux getMap via le cache. Autre point positif : le même service interrogé en WMTS génèrera un document de capacités WMTS sur les seules couches tuilées. Et chacun des deux logiciels autorise aussi le TMS et le KML (mode pour lequel les fichiers KML contiennent des liens vers les tuiles en fonction de l’échelle. Google appelle ceci des SuperOverlays). On peut également établir des alias entre systèmes de projection (au hasard EPSG:27572 et EPSG:27582, ou EPSG:900913 et EPSG:3857) de manière à ce qu’un cache fait dans un système soit utilisé pour répondre aux requêtes demandant l’autre.
    Ainsi, via des mécanismes serveurs bien pensés, on s’affranchit des lourdeurs d’un deuxième standard et de son implémentation dans les clients. Quelques inconvénients subsistent certes, notamment pour ce qui est du ré-échantillonnage. Du texte généré au 1/5000 n’aurait pas forcément très belle allure au 1/7500. Il y a donc des arbitrages à effectuer entre ce qui doit être tuilé ou pas et la stratégie de constitution des tuilages qui demeure. A ce propos, il faut garder à l’esprit un principe de base : on ne tuile que ce qui est régulièrement utilisé ou qui coûte à générer.
  8. Conclusion
    Cet article s’est ouvert sur GoogleMaps, et j’entends déjà la question arriver : si faire fusionner les tuiles par le serveur est si bénéfique, pourquoi GoogleMaps ne le fait-il pas ? Recevable en effet. Mais une fois de plus, GoogleMaps c’est un nombre fini et réduit de couches cartographiques, traitées dans un seul système de projection, et proposant uniquement des services propriétaires. On est donc bien loin des considérations et préoccupations qui nous ont menées ici. De mon point de vue, je trouve cette approche très intéressante car elle laisse au responsable du service la responsabilité de la publication. A partir d’un seul point d’entrée wms.monserveur.com, il peut déterminer qu’une couche doit être tuilée ou pas, tuiler celle qui a soudain du succès, ne plus tuiler la vieille orthophoto de dix ans d’âge, cela sans changer les modalités d’accès au service et donc sans avoir à bouleverser les habitudes des utilisateurs. De la sorte, ce responsable de la publication géomatique peut choisir sa stratégie de diffusion de services en cohérence avec le reste de son système d’information pour ce qui est des mises à jour, des contenus diffusés ou encore des publics visés. Il se libère des contraintes techniques liées aux services de visualisation.
    Simple mécanisme technique initialement, le serveur de tuile s’est récemment mué en proxy cartographique, capable d’interpréter, rediriger, exploiter les requêtes qu’il reçoit. Nul doute que ce rôle a vocation à s’élargir encore et que nous verrons sous peu ces systèmes traiter d’autres types de services (WFS par exemple) ou adresser d’autres types de besoins (authentification, métadonnées…).
Petite histoire de tuilage
Étiqueté avec :        

9 pesnées sur “Petite histoire de tuilage

  • 21 août 2012 à 12:24
    Permalien

    Super article, clair et bien écrit ! Merci pour ces précisions et ce retour historique.

    J’espère que tu reprendras un rythme de publication plus régulier car c’est un vrai plaisir de te lire.

    A.

    Répondre
    • 21 août 2012 à 12:53
      Permalien

      Bonjour Arnaud,

      Merci pour ces encouragements. Il n’est pas toujours facile de trouver le temps et la sérénité nécessaire à cela. Mais je vais essayer !

      À bientôt

      Répondre
  • 22 août 2012 à 10:49
    Permalien

    Bonjour Guillaume,

    Excellent article. Ni trop technique, ni trop vulgarisateur et qui remet bien les idées claires concernant l’intéropérabilité. Dans l’impatience de vous lire à nouveau.

    Claire.

    Répondre
  • 9 septembre 2012 à 3:55
    Permalien

    Ahlàlà, si vous aviez pu écrire cet article quelques mois plus tôt… Article très intéressant, j’y ai beaucoup appris. Merci à vous !

    Répondre
  • 10 septembre 2012 à 9:51
    Permalien

    Bonjour Guillaume,

    Merci pour cet article. Toujours aussi intéressant à lire.

    Je réagis juste à cette phrase (un peu en marge du sujet de l’article) : « Les standards OGC ne sont pas connus pour leur simplicité. Ils sont conçus par de grandes multinationales et agences gouvernementales d’une manière suffisamment obscure et complexe tant dans le processus d’élaboration que dans l’exposition du résultat final pour éviter que le commun des mortels vienne y mettre trop facilement son nez. »

    Ben, non, les standards de l’OGC ne sont pas forcément élaborés par de grandes multinationales et agences gouvernementales. Regarde la liste des contributeurs de WMTS par exemple. Ce sont juste des contributeurs qui ont eu du temps pour travailler sur ce sujet. Ils n’ont eu quasiment aucun soutien ni commentaires constructifs de la part des autres membres de leur groupe de travail (comparativement à l’énergie qu’ils ont investie dans ce projet). Par contre, il est vrai que ce sont essentiellement des grandes multinationales et agences gouvernementales qui financent l’OGC mais il ne faut pas croire que les auteurs des standards sont payés par l’OGC.

    C’est vrai que l’élaboration des standards est opaque. WMTS a été élaboré sans aucun échange avec la communauté open source qui avait été à l’origine de TMS et WMS-C ! Cette opacité est volontaire et est peut-être liée à une question d’argent (même si certains groupes de travail sont ouverts vers l’extérieur) : les membres de l’OGC paient très cher leur adhésion.

    Par contre, je ne pense pas que la complexité des standards de l’OGC soit volontaire. C’est plus parce que très peu de membres de l’OGC s’investissent dans leur élaboration et qu’ils votent la publication d’un document sans l’avoir lu ni compris. Il y a aussi le fait que l’OGC (contrairement à Google) pense que l’interopérabilité ne se limite pas à un seul système de coordonnées, un seul format de données, etc.

    Benjamin

    Répondre
    • 10 septembre 2012 à 15:17
      Permalien

      Ah ah, je me disais bien que cette petite grenade dégoupillée ferait réagir !

      Répondre
      • 11 septembre 2012 à 14:03
        Permalien

        J’ai été plutôt lent à la détente…

        Répondre
    • 15 octobre 2012 à 12:28
      Permalien

      « Ils n’ont eu quasiment aucun soutien ni commentaires constructifs de la part des autres membres de leur groupe de travail (comparativement à l’énergie qu’ils ont investie dans ce projet) »

      Je suis pas vraiment d’accord. L’IGN a répondu avec un long texte indiquant que le standard WMTS proposé était vraiment lourd et consommateur de beaucoup de ressources réseau (il y avait même des contre-propositions) et nos commentaires sont tombés … à l’eau !

      La complexité des standards OGC est souvent due au fait qu’ils doivent tout faire (ou presque) plutôt que de bien faire un tâche (principe bien connu dans le monde Unix). A voir les évolutions WFS, WCS … une horreur à la fin !

      Didier

      Répondre
  • Ping : neogeo | Retour d’expérience sur l’API IGN 2.0

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.