Le « Web Feature Service » (WFS), est un standard OGC de Service Web qui définit une interface d’interopérabilité technique, dédiée à la publication d’objets géographiques (c'est-à-dire des données vecteur) ainsi que leur structure.

L’interface WFS décrit des opérations permettant en premier lieu le téléchargement des entités de données géographiques stockées dans des bases de données. Ces données sont exposées a minima sous forme de flux standard GML (Geographic Markup Language). Des opérations supplémentaires sont définies par WFS permettant la manipulation des données vecteur (création, suppression et mise à jour).

Le standard définit un protocole d’interopérabilité à plusieurs niveaux d'opérations :

• le premier retourne les métadonnées,
• le deuxième renvoie les données elles-mêmes (collection d’objets) ou des informations constitutives de ces données (attributs d’un objet),
• le troisième niveau d’opération, optionnel, permet de modifier/manipuler les données. On parle alors de service WFS-T pour Transactionnel (cf. détails dans la description des opérations).

Le standard WFS ne fait aucune supposition quant à l’architecture technique sur laquelle repose le service. En particulier, aucune exigence ne concerne la manière dont le stockage des données gérées par le service doit être réalisé, ni la nature des applications exploitant le service. Cela en fait un standard pouvant répondre à de multiples usages et types d’architectures. Un service WFS peut être utilisé par des clients variés (clients lourds, clients légers, serveurs d’applications, d’autres services web notamment) et peut exploiter des données stockées et structurées de manières très diverses (fichiers, bases de données centralisées voire distribuées).

La suite du document est consacrée à la description d’un service WFS relatif à la version 1.1, la plus implémentée actuellement. La version 2.0 (aussi norme ISO 19142 depuis fin 2010) n’est pour le moment que peu implémentée ; elle est cependant la version exigée par INSPIRE et fera donc l’objet d’une prochaine fiche.

Un WFS peut être implémenté à trois niveaux: soit “basique”, soit “XLink”, soit “transactionnel”.

• Les WFS basiques donnent un accès en lecture seule (c’est à dire le téléchargement) aux données.
• Les WFS XLink permettent de plus d’accéder aux objets ou à leurs propriétés par leurs identifiants (cf. opération GetGmlObject) et de résoudre des liens XLink (cf. paramètres traverseXlinkDepth et traverseXlinkExpiry des opérations GetGmlObject, GetFeature et GetFeatureWithLock).
• Les WFS transactionnels (WFS-T) supportent toutes les opérations des WFS basiques en y ajoutant les opérations de transaction. Un mécanisme de verrouillage est optionnel ; il permet à plusieurs utilisateurs d'effectuer simultanément une série d'opérations comme la création, la mise à jour, la suppression et l'interrogation de différentes entités géographiques sans risque de conflit.

WFS 1.1 décrit trois formes d’encodage des requêtes, à savoir :

• HTTP GET avec un encodage KVP (Key-Value-Pair) des requêtes,
• HTTP POST avec un encodage XML KVP des requêtes,
• SOAP (c'est-à-dire HTTP POST avec encodage de la requête dans l’élément Body du message SOAP).

Dans la suite du document seul l’encodage HTTP GET / KVP est présenté, étant le plus communément implémenté.

Les noms des paramètres ne sont pas sensibles à la casse, contrairement aux valeurs (GetCapabilities par exemple).

• Il est conseillé d'écrire les paramètres en majuscules pour une meilleure lisibilité.
• Les paramètres peuvent être définis dans n'importe quel ordre.
• Les listes de valeurs doivent utiliser la virgule comme séparateur.
• Si une virgule ou un espace est présent dans la valeur, celle-ci doit être précédée d’un caractère d’échappement.

Paramètres communs :

• VERSION (obligatoire, sauf pour l’opération GetCapabilities) : définit le numéro de version du standard WFS utilisé, 1.1.0 par exemple
• SERVICE (obligatoire) : définit le type de service, obligatoirement WFS pour un service WFS
• REQUEST (obligatoire) : indique quelle opération du service est invoquée. La valeur doit être le nom d'une opération offerte par le serveur
• NAMESPACE (optionnel) : définit l’espace de nommage permettant de qualifier un objet géographique ou ses propriétés
• FORMAT (optionnel) : définit le format de sortie de la réponse d'une opération. Le serveur doit gérer un certain nombre de formats, et doit les indiquer dans ses métadonnées
• EXCEPTIONS (optionnel) : indique le format de présentation des messages d’erreur retournés par le serveur

Les opérations offertes par un service WFS sont :

GetCapabilities (Basique) : Cette opération permet d’interroger le serveur afin d’obtenir les informations suivantes (informations présentées dans un document XML communément appelé Capabilities) :

• les métadonnées du service : identification du service et de l’entité qui fournit le service,
• les opérations, versions et encodages des requêtes supportées par le service,
• les classes d’objets servies,
• les propriétés des objets accessibles via l’opération GetGmlObject,
• les capacités de filtre du service.

Paramètres obligatoires :

• SERVICE=WFS : type de service
• REQUEST=GetCapabilities : nom de l’opération

Paramètres optionnels :

• VERSION : version de WFS (e.g. 1.1.0)
• ACCEPTFORMATS : liste des formats (sous forme de types MIME) acceptés par l’application cliente. Ce paramètre n’est pas obligatoirement reconnu par tous les services (son support est documenté dans les Capabilities du service). La valeur par défaut de ce paramètre est txt/xml et les spécifications WFS indiquent que la réponse à cette opération est obligatoirement un document XML
• ACCEPTVERSIONS : liste des versions du standard WFS supportés par l’application cliente. Exemple : 1.1.0,1.0.0. Ce paramètre n’est pas obligatoirement reconnu par tous les services (son support est documenté dans les Capabilities du service)
• SECTIONS : liste des sections des Capabilities du service à récupérer. Les noms des sections sont : ServiceIdentification, ServiceProvider, OperationsMetadata, FeatureTypeList, ServesGMLObjectTypeList, SupportsGMLObjectTypeList et Filter_Capabilities. Ce paramètre n’est pas obligatoirement reconnu par tous les services (son support est documenté dans les Capabilities du service)
• UPDATESEQUENCE : Chaîne de caractères identifiant la dernière version des “Capabilities” du service en possession de l’application cliente. A l’aide de cette information, le service peut déterminer s’il est nécessaire de renvoyer ce document à l’application cliente. Ce paramètre n’est pas obligatoirement reconnu par tous les services. Exemple de valeur : XYZ123.

Exemple de requête:
http://nsidc.org/cgi-bin/atlas_north?service=WFS&request=GetCapabilities&version=1.1.0
La réponse est un fichier XML.

Paramètres obligatoires :

• SERVICE=WFS : nom du service.
• REQUEST=GetCapabilities : type de requête.

Paramètres optionnels :

• VERSION=version : numéro de la version, 1.1.0 par exemple.
• FORMAT=MIME_Type : format de rendu.
• UPDATESEQUENCE=chaîne : Permet de maintenir la cohérence du cache. Sa valeur peut être soit un entier, soit une chaine de caractère qui représente un timestamp ou tout autre chaine.

La réponse est un fichier XML.

Exemple de requête GetCapabilities : http://geolittoral.application.equipement.gouv.fr/wfs/metropole?SERVICE=WFS&REQUEST=1.0.0&REQUEST=GetCapabilities

Paramètre obligatoire :

• REQUEST=DescribeFeatureType

Paramètres non obligatoire :

• TYPENAME=
• OUTPUTFORMAT=

Paramètres obligatoires :

• REQUEST=GetFeature
• TYPENAME=

Paramètres non obligatoires :

• OUTPUTFORMAT=
• RESULTYPE=
• PROPERTYNAME=
• FEATUREVERSION=
• MAXFEATURES=
• EXPIRY=
• SRS=
• FEATUREID=
• FILTER=
• BBOX=
• SORTBY=

Paramètres obligatoires :

• REQUEST=[GetGmlObject]
• TRAVERSEXLINKDEPTH
• GMLOBJECTID=

Paramètres non obligatoires :

• TRAVERSEXLINKEXPIRY=

1. http://www.opengeospatial.org/standards/wfs
2. http://fr.wikipedia.org/wiki/Web_Feature_Service