Service des pavés cartographiques Web (WMTS)
Aperçu
Les techniques de cartographie par pavés gagnent en popularité. Un service des pavés cartographiques Web (WMTS) donne accès à des cartes de données géoréférencées, et non aux données elles-mêmes. La norme du service de pavés précise la manière dont le client demande les pavés cartographiques et la manière dont le serveur décrit ses dépôts.
Normes
OpenGIS® Web Map Tile Service Implementation Standard
Renseignements connexes
Note
La norme de mise en œuvre élaborée par l’Open Geospatial Consortium (OGC) repose sur le travail d’élaboration sur la cartographie par pavés effectué dans le cadre d’une collaboration par l’Open Source Geospatial Foundation.
Information supplémentaire - techniques de cartographie par pavés
Méthodologie du service des pavés cartographiques Web
Contexte
Le service des pavés cartographiques Web (WMTS) de l’OCG® repose sur les efforts antérieurs déployés pour élaborer des services échelonnables à haut rendement de distribution des cartes par le Web. Le service découle de la OSGeo Tile Map Service Specification. L’équipe qui a travaillé à cette norme a aussi examiné d’autres initiatives, comme les cartes Google et OnEarth de la NASA. La présente norme de l’OCG® tient compte des styles architecturales des ressources (approche RESTful) et de la procédure (codage KVP et SOAP) dans le but d’harmoniser cette norme d’interface avec la spécification de l’OSGeo Tile Map Service Specification.
Le service des pavés cartographiques Web s’ajoute aux efforts antérieurs déployés pour élaborer des services de distribution des cartes par le Web. Le service des pavés cartographiques Web de l’OGC® adopte une approche complémentaire au service de cartes Web (WMS) de l’OGC® en ce qui concerne le pavage des cartes. Le service de cartes Web porte sur le rendu de cartes personnaliséeset constitue une solution idéale aux données dynamiques et aux cartes offrant un style personnalisé (combinée avec la norme du descripteur des couches stylisées (SLD) de l’OGC®). Le service des pavés cartographiques Web échange la souplesse du rendu d’une carte personnalisée pour l’échelonnabilité en appliquant des données statiques (cartes de base), où la zone de délimitation et les échelles sont limitées, à des pavés discrets. Le jeu fixe de pavés permet à la mise en œuvre d’un service de pavés cartographiques Web d’utiliser un serveur Web qui retourne simplement des fichiers existants. Ce jeu fixe permet également l’utilisation de mécanismes standards d’un réseau pour assurer l’échelonnabilité, comme un système réparti d’antémémoires.
La norme du service des pavés cartographiques Web est structurée sous forme de norme autonome, mais partage de nombreux concepts avec le service de cartes Web (WMS).
Open Source Geospatial Foundation (OSGeo)
L’Open Source Geospatial Foundation (OSGeo) a été créée pour appuyer et développer le logiciel géospatial à code ouvert de la plus haute qualité. Elle avait pour but d’encourager l’utilisation et le développement collaboratif des projets menés par la communauté. La communauté Wiki de l’OSGeo est le lieu où peuvent être créés les documents dans le cadre de collaborations (c.-à-d., processus d’adoption, conseils des utilisateurs, suggestions, notes du comité, etc.).
La Tile Map Service (TMS) Specification est l’œuvre d’une communauté indépendante de participants qui s’intéressaient à des solutions de cartographie client-serveur reposant sur des pyramides d’images à résolutions multiples. Elle se voulait la pierre d’assise de la mise en œuvre d’un logiciel de cartographie client-serveur. Il ne s’agit pas d’une norme « officielle », et elle n’est pas reconnue par l’OSGeo à titre d’œuvre ou de projet officiel de la fondation.
Méthodologie du service des pavés cartographiques Web
La norme de mise en œuvre du service des pavés cartographiques Web procure une solution normalisée pour créer des cartes numériques à partir de pavés d’image définis. Le service annonce les pavés en sa possession par une déclaration normalisée dans le document des métadonnées du service propres à tous les services Web de l’OGC®. Cette déclaration définit les pavés offerts à chaque couche (c.-à-d., chaque type de contenu), sous chaque style de représentation graphique, dans chaque format, sous chaque système de coordonnées de référence, à chaque échelle et pour chaque fragment géographique de la zone totale couverte. Le document des métadonnées du service comporte aussi les protocoles de communication et les codes au moyen desquels le client peut communiquer avec le serveur. Le client peut interpréter le document des métadonnées du service pour rechercher des pavés particuliers.
La norme du service des pavés cartographiques Web complète l’actuelle norme du service de cartes Web (WMS). Cette dernière porte sur la souplesse inhérente à la requête du client et lui permet d’obtenir exactement l’image finale désirée. Le client d’un service de cartes Web peut demander à un serveur de créer une carte par la superposition d’un nombre arbitraire de couches, sur une délimitation géographique arbitraire, sous une couleur de fond arbitraire, peu importe le système de coordonnées de référence reconnu. Le client peut aussi demander le rendu des couches au moyen d’un style offert par le serveur ou d’un style personnalisé lorsque le serveur reconnaît la norme du descripteur des couches stylisées (SLD) de l’OGC®. Toutefois, toute cette souplesse a un prix : la vitesse de traitement de l’image du serveur dépend du nombre de clients connectés et le potentiel de mise en antémémoire des images entre le serveur et le client est limité, car la plupart des images sont différentes.
À mesure que les clients des services Web gagnent en puissance, il devient possible d’examiner une stratégie de rechange qui force les clients à créer eux-mêmes les superpositions et qui les limitent à demander des images de cartes qui ne sont pas exactement dans la bonne position, ce qui les oblige à disposer les pavés obtenus du serveur afin de créer l’image finale. Le fait de restreindre les images demandées à un jeu fixe déterminé permet aux serveurs de procéder à une mise à l’échelle en fonction des capacités de traitement des communications et non des capacités de traitement des images, parce que les serveurs peuvent faire un rendu préalable d’une partie ou de la totalité de leurs images et peuvent recourir à des mécanismes de mise en antémémoire des images. Le jeu fixe d’images permet aussi à un fournisseur de réseau de mettre en antémémoire des images entre le client et le serveur, afin de réduire le délai d’attente et l’utilisation de la largeur de bande. Des mises en œuvres commerciales populaires et personnalisées de cette approche (comme Google Maps, Microsoft Virtual Earth et Yahoo! Maps) ont déjà démontré les avantages nets en matière de performance de cette méthodologie.
Certains serveurs du service de cartes Web ont déjà adopté cette voie, et élaborent leurs propres structures de pavés en limitant les requêtes GetMap du service à un jeu fixe, puis en énonçant ces limites dans les métadonnées de leur service. Bien que ce mécanisme permette à ces serveurs de faire des mises à l’échelle, comme nous venons de les décrire, il n’y a aucune uniformité dans la structure des pavés de même que des mécanismes d’annonce et de recherche. Malheureusement, une telle approche limite la compatibilité et oblige les développeurs à créer pour chaque serveur des clients spéciaux qui peuvent comprendre les limites annoncées par le serveur et restreindre les requêtes GetMap du service de cartes Web lancées par le client au format exact des requêtes que comprend le serveur. La norme du service des pavés cartographiques Web offre une approche uniformisée pour déclarer les images que peut demander un client à un serveur, et vise le développement d’un seul type de client pour tous les serveurs. Même si on examinait au départ l’élaboration d’un profil du service de cartes Web, il était bizarre de restreindre les importantes méthodes d’accès efficace d’un service Web de cartographie à des pavés mis en antémémoire. En outre, le fait d’obliger les développeurs à lire une norme et un profil semblait moins efficace que d’élaborer la spécification autonome du service des pavés cartographiques Web.
Le service des pavés cartographiques Web décline la norme en deux étapes :
- Une spécification du résumé décrit la sémantique des ressources offertes par le serveur et demandées par le client. Cette définition du résumé précise la sémantique du document des métadonnées du service, des images des pavés ou des représentations ainsi que des documents optionnels des renseignements sur les entités qui donnent des descriptions des cartes à divers emplacements.
- La norme précise aussi plusieurs mécanismes d’échanges concrets entre les clients et les serveurs, selon deux styles architecturaux distincts. Le service des pavés cartographiques Web définit les opérations GetCapabilities, GetTileet GetFeatureInfo optionnelles des approches axées sur le style architectural orienté procédure au moyen de plusieurs codages différents des messages, y compris les messages codés au moyen des langages KVP, XML ou XML imbriqués dans des enveloppes SOAP. Le service des pavés cartographiques Web définit également les mécanismes liés aux requêtes et la stratégie de publication aux points d’extrémité afin de permettre l’utilisation d’un style architectural orienté ressource reposant sur les points d’extrémité des adresses URL. Le client peut ainsi demander simplement les ressources des métadonnées du service, des pavés et des renseignements sur les entités sous forme de documents.
Ce style architectural orienté ressource offre des avantages importants, en ce sens, qu’il facilite le déploiement, l’échelonnabilité et le réseautage des services Web. Le modèle RESTful permet la configuration simple d’un serveur du service des pavés cartographiques Web. Si toutes les images sont déjà rendues, un tel serveur pourrait même être créé sans aucune logique de traitement des images. Il devrait alors compter seulement sur un serveur Web normal pour obtenir le document statique XML des métadonnées du service et fournir les fichiers des pavés d’images. Ce précepte est important du point de vue du développement, car de nombreux fournisseurs de service internet (surtout ceux offrant un service gratuit) acceptent d’héberger les pages Web et le contenu statique, mais ne reconnaissent pas l’utilisation d’applications plus évoluées, comme CGI et ASP, entre autres, pour des raisons de sécurité. L’approche RESTful permet, par conséquent, à de petites organisations de fournir des données géographiques au moyen de services existants ou d’une simple configuration d’un serveur Web. Cette approche est beaucoup plus facile, car les problèmes liés à la présentation de ressources fixes dans un trafic élevé ont fait l’objet de nombreux efforts au cours des dernières décennies. Enfin, cette approche peut profiter des effets d’échelle des réseaux étant donné que le protocole HTTP considère que les images sont des ressources Web standard, et les fournisseurs de réseau peuvent adapter leurs technologies actuelles pour améliorer le débit de ces ressources vers les clients demandeurs.
Détails de la page
- Date de modification :