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

wms.png

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