WMS

Introduction

Le protocole Web Map Service (WMS) développé par l'Open Geospatial Consortium (OGC) s'impose aujourd'hui comme une référence dans le monde du WebMapping. Il permet à partir d'une simple requête normalisée vers un serveur cartographique de retourner l'image demandée.

Un peu d'histoire

C'est en Avril 2000 que la première version (1.0) voit le jour, de suite suivi quelques mois plus tard par la 1.1. Puis en janvier 2002 c'est au tour de la 1.1.1, qui est la version la plus largement supportée par les moteurs cartographiques. il faut souligner néanmoins que depuis Décembre 20004 une nouvelle version (1.3) est disponible.

Comment fonctionne le protocole WMS ?

Comme nous l'avons abordé rapidement en introduction, le protocole WMS permet au moyen d'une simple requête d'interroger n'importe quel serveur ayant intégré cette norme. Cette requête est assez simple et pourrait se traduire par :

> Quel est le service que l'on souhaite utiliser? Quelle est sa version? Quelle est la requête ?

Ce qui se traduit informatiquement par :

    http ://hostname:port/path?
        service=WMS&
        version=1.1.1&
        request=GetCapabilities

Il est important de comprendre que dans une requête WMS (comme d'ailleurs dans les autres protocoles) il y a deux acteurs : Le serveur cartographique et le client cartographique.
Côté serveur et en fonction du choix du moteur cartographique utilisé (MapServer, ArcGisServer, GeoServer...) la configuration de ce service sera plus ou moins aisée.

Nous verrons par la suite qu'il existe différents types de requêtes et qu'en fonction de celle-ci un certain nombre d'arguments doivent être ajoutés.

Quelles sont les requêtes possibles ?

Les trois types de requêtes qu'il est possible d'utiliser sont :

GetCapabilities : Retourne une description du serveur, des services et des couches disponibles
GetMap : Retourne une carte sous forme d'image
GetFeatureInfo : Retourne les informations de l'objet interrogé

Même si le type de requête ci-dessous n'est pas directement rattaché au protocole WMS (mais au SLD), il me parait important que vous en connaissiez l'existence :

GetLegendGraphic : Retourne la légende associée

Nous allons maintenant étudier en détail chacun des trois types de requête disponibles.

GetCapabilities

Une requête de type GetCapabilities indique au serveur cartographique de renvoyer au client un fichier XML contenant un ensemble d'information relatif à ce service. Prenons un exemple concret et interrogeons le serveur de geosignal :

 http://www.geosignal.org/cgi-bin/wmsmap?version=1.1.1&service=WMS&request=GetCapabilities

Dans ce fichier XML on retrouve notamment :

ContactInformation : Description générale de l'organisme/personne qui fournit le service WMS (Adresse, Nom, Pays...)
Capability : C'est la partie la plus importante. Celle-ci spécifie les capacités du serveur cartographique. On y trouve le type de requête acceptée (GetMap, GetFeatureInfo), le format de données en fonction du type de requête, les couches disponibles :

request : Liste les requêtes qu'il est possible de réaliser :
<Request>
<GetCapabilities>...</GetCapabilities>
<GetMap>...</GetMap>
<GetFeatureInfo>...</GetFeatureInfo>
<DescribeLayer>...</DescribeLayer>
<GetLegendGraphic>...</GetLegendGraphic>
</Request>
Layer : Chacune des couches disponibles sera décrite à l'intérieur d'un bloc de type ce type. Les informations que l'on retrouve sont notamment : Nom, SRS (EPSG), Extension géographique, Style... Six paramètres peuvent également être ajoutés directement dans la balise layer:

queryable : La couche est ou non interrogeable (seulement si le serveur supporte les requêtes de type GetFeatureInfo)
cascaded : Dans le cas d'ajout de couche provenant d'un serveur WMS tiers.
opaque : Spécifie que les zones vides d'une couche doivent être transparentes. Il faut néanmoins préciser que cet attribut n'est qu'indicatif. En effet, pour que ce paramètre soit effectif, il faudra préciser au serveur cartographique de générer une image prenant en compte la transparence et définir un format capable de gérer celle-ci.
noSubsets : Précise si le serveur cartographique est capable d'envoyer une image contenant une zone plus petite que celle définie par l'extension initiale
fixedWidth et FixedHeight : Précise si le serveur cartographique est capable de changer la taille, l'interpolation, la résolution de l'image par rapport à sa résolution initiale

GetMap

Une requête de type GetMap spécifie au serveur cartographique de renvoyer au client une image. Cette requête respecte une syntaxe précise contenant un certain nombre de mots clés. Regardons en détail l'exemple ci-dessous :

http://www.geosignal.org/cgi-bin/wmsmap?version=1.1.1&service=WMS
&request=GetMap&SRS=EPSG:4326&BBOX=-5.13452,41.3593,10.8074,51.0757
&WIDTH=400&HEIGHT=400&LAYERS=Communes&STYLES=&FORMAT=image/png

Le début de la requête ne change pas on y retrouve le service, la version ainsi que le type de requête. Mais comme nous avons spécifié que nous désirions une requête de type GetMap, certains paramètres doivent être ajoutés. Seuls ceux qui sont indispensables sont présentés ci-dessous (il en existe d'autres optionnels) :

Layers : Liste des couches séparée par une virgule qui seront sur la carte
Styles : Style à appliquer aux layers. Optionnel si le paramètre est présent
SRS : Systéme de projection utilisé
BBOX : Extension géographique des données (dans le même système d'unité que le SRS)
Width : Largeur en pixels de la carte
Height : longueur en pixels de la carte
Format : Format de l'image

GetFeatureInfo

GetFeatureInfo n'est disponible que pour les couches dont le paramètre queryable est égal à 1 (true). Celui-ci permet d'interroger les données pour en récupérer les informations attributaires.

http://www.geosignal.org/cgi-bin/wmsmap?version=1.1.1&service=WMS&request=GetFeatureInfo
&X=200&Y=200&QUERY_LAYERS=Communes&LAYERS=Communes

Retourne :

Layer 'Communes'
  Feature 23413: 
    NOM = 'Azay-sur-Cher'
    CODE_GS = '305971778'
    CODE_INSEE = '37015'
    CODE_CANTO = '3'
    CODE_ARRON = '2'
    CODE_DEPAR = '37'
    CODE_REGIO = '24'
    NOM_CANTON = 'Bléré'
    NOM_ARROND = 'Tours'
    NOM_DEPART = 'Indre-et-Loire'
    NOM_REGION = 'Centre'

Regardons maintenant en détail comment est construite la requête :

Au début rien ne change nous retrouvons les informations habituelles (service, version, requête). Mais certains paramètres additionnels ont été ajoutés :

X : Coordonnées en pixels de la donnée à interroger
Y : Coordonnées en pixels de la donnée à interroger
QUERY_LAYERS :Liste des couches à interroger

Conclusion

La pérennité de tous mouvements vient du fait qu'à un moment donné un langage commun permettant de s'affranchir de toutes les particularités liées à un éditeur voit le jour.
Au travers des exemples et explications présentés tout au long de cette page il est facile de voir les possibilités de ce protocole. Il permet en effet d'uniformiser et d'unifier les différents acteurs (propriétaires comme libres) en fournissant une norme adaptée et simple à utiliser.

more tags

GeoTribu

WMS