Introduction

Actuellement en version 1.2.0, le protocole WCS est spécialement adapté à la distribution de données raster. Néanmoins, du fait de sa récente adoption et des nombreux changements peu de peu de services utilisent cette version. Celle rencontrée le plus régulièrement étant la 1.1.0.

Comment fonctionne le protocole WCS ?

Le protocole WCS permet, au moyen d'une simple requête (Get & Post), d'accéder au données brutes de couches raster (à chaque pixel est associé une donnée) telles que les images satellites, MNT...

Au contraire du WMS, un service WCS fournit à la fois une image mais également les données qui lui sont associées.

Quelles sont les requêtes possibles ?

Les trois types de requêtes possibles sont :

• GetCapabilities
• DescribeCoverage
• GetCoverage

GetCapabilities

Une requête de type GetCapabilities indique au serveur cartographique de retourner au client un fichier XML contenant un ensemble d'information relatif au service WCS ainsi que la liste des couches disponibles.

Cette requête est composée des mots clés suivant :

    http ://hostname:port/path?
        Service=WCS&
        request=GetCapabilities&
        updateSequence=XYZ123&
        AcceptVersions=1.1.0,1.0.0&
        Sections=Contents&
        AcceptFormats=text/xml

Certains de ces paramètres sont obligatoires, d'autres non :

Prenons un exemple concret et interrogeons maintenant le serveur de la NSDIC :

    http://nsidc.org/cgi-bin/atlas_south?SERVICE=WCS&REQUEST=GetCapabilities&VERSION=1.1.1

Ce fichier XML est composé notamment des balises :

• ServiceIdentification : Informations liées à ce service WCS (titre, mots clés, résumé...)
• ServiceProvider : Informations liées à l'organisation qui met à disposition ce service WCS (nom, contacts...)
• OperationsMetadata : Liste des opérations qu'implémente ce service WCS :


<ows:Operation name="GetCapabilities">
<ows:DCP>
<ows:HTTP>
<ows:Get xlink:type="simple" xlink:href="http://nsidc.org/cgi-bin/atlas_south?"/>
</ows:HTTP>
</ows:DCP>
<ows:Parameter name="service">
<ows:Value>WCS</ows:Value>
</ows:Parameter>
<ows:Parameter name="version">
<ows:Value>1.1.1</ows:Value>
</ows:Parameter>
</ows:Operation>
<ows:Operation name="DescribeCoverage">
...
</ows:Operation>
<ows:Operation name="GetCoverage">
...
</ows:Operation>

• Contents : Informations liées aux données que ce service WCS propose (identifiant, nom, résumé, mots clés, formats et projections supportés...)

DescribeCoverage

Une requête de type DescribeCoverage indique au serveur cartographique de retourner au client un fichier XML contenant une description détaillée des couches spécifiées par l'utilisateur.

Elle est similaire au résultat contenu dans la balise Contents lors d'une requête de type GetCapabilities sauf qu'elle ne décrit que la ou les couches demandées.

Cette requête est composée des mots clés suivant :

    http ://hostname:port/path?
        service=WCS&
        request=DescribeCoverage&
        version=1.1.1&
        identifiers=coverage1,coverage2

Certains de ces paramètres sont obligatoires, d'autres non :

Prenons un exemple concret et interrogeons maintenant le serveur de la NSDIC :

    http://nsidc.org/cgi-bin/atlas_south?service=WCS&REQUEST=DescribeCoverage&VERSION=1.1.1&IDENTIFIER=sea_ice_concentration_01

Attention : Entre la version 1.0 et la version 1.1.0+ quelques modifications ont été apportées. Celles-ci portent notamment sur le remplacement du mot clé coverage par identifier.

Ce fichier ">fichier XML est composé notamment des balises :

• Title : titre de la couche
• Abstract : résumé de la couche
• Identifier : identifiant unique de la couche
• Keywords : liste de mots clés liée à la couche
• Domain : Domaines disponibles (géographique "SpatialDomain" ou temporelle "TemporalDomain")
• Range : valeurs des données
• supportedCRS : liste des projections pouvant être utilisée
• supportedFormat : liste des formats disponibles en sortie (GeoTIFF, HDF-EOS...)

GetCoverage

Maintenant que nous connaissons les possibilités de notre serveur cartographique (GetCapabilities) ainsi que les couches disponibles (DescribeCoverage), il est temps d'obtenir la couverture désirée grâce à la requête GetCoverage.

Cette requête est composée des mots clés suivant :

    http ://hostname:port/path?
        service=WCS&
        request=GetCoverage&
        version=1.1.1&
        BoundingBox=43,33,44,34,urn:ogc:def:crs:EPSG::4326&
        FORMAT=image/tiff
        identifiers=coverage1

Certains de ces paramètres sont obligatoires, d'autres non :

Attention : Entre la version 1.0 et la version 1.1.0+ quelques modifications ont été apportées. Ainsi le mot clé BBOX a été remplacé par BoundingBox, COVERAGE par Identifier
De plus les paramètres GRIDBASECRS, GRIDCS, GridOrigin, GridOffsets permettent de spécifier une nouvelle résolution spatiale. Le résultat final étant bien évidemment à metre en relation avec le paramètre BoundingBox.

De plus comme nous l'avons vu, il est possible de spécifier l'extension géographique désirée. Le découpage nécessaire fait alors intervenir différentes méthodes d'interpolation (bilinear, bicubic, plus proche voisin...)

Prenons un exemple concret et interrogeons maintenant le serveur de la NSDIC. Attention, dans l'exemple ci-dessous, même si la version du service est 1.1.1 les paramètres utilisés sont obsolètes.

    http ://nsidc.org/cgi-bin/atlas_north?service=WCS&
        version=1.1.1&request=GetCoverage&
        crs=EPSG:32661&format=GeoTIFF&
        resx=25000&resy=25000&bbox=-2700000,-2700000,6700000,6700000&
        coverage=sea_ice_concentration_01

Cette requête retourne une image au format tiff semblable à celle-ci dessous :

Conclusion

Les différentes versions du WCS et surtout les changements majeurs qu'elles ont entraîné ont été je pense fortement préjudiciables à la compréhension de ce protocole. Était-il réellement nécessaire de substituer bbox (V 1.0) par BoundingBox (V 1.1.0) ? Ainsi l'écriture de ce document sur le format WCS a été rendue difficile par ces différents changements car aucune requête sur les différents serveurs cartographiques disponibles ne semblait se ressembler. Gageons que les prochaines versions seront plus stables.