Je reviens sur une autre question posée lors de la dernière journée de l’interopérabilité du Forum Français de l’OGC : est-ce qu’une application cliente d’un service WFS peut présenter un formulaire prenant en compte le fait que certains attributs ne peuvent être renseignés à l’aide de valeurs tirées d’une liste de valeurs prédéfinies ? Prenons un exemple concret : peut-on faire en sorte qu’un outil de saisie d’un réseau routier propose à l’utilisateur uniquement les valeurs « Route départementale », « Route nationale », « Autoroute » et « Autre route » pour un attribut « Classification de la route » si seules ces valeurs sont autorisées par la base de données qui se cache derrière le service WFS-T ?
Il est tout à fait possible pour un service WFS d’informer ses applications clientes de l’existence de certaines contraintes sur les données qu’il publie. Cela passe par l’exploitation de l’opération DescribeFeatureType. Celle-ci décrit le modèle des données publiées. Par défaut, ce modèle est exprimé sous la forme d’un schéma XML. Si des listes de valeurs codées doivent être respectées, elles peuvent être définies dans le schéma. Voici un extrait d’un schéma décrivant les réseaux routiers d’INSPIRE :
<simpleType name="FunctionalRoadClassValueType"> <annotation>[...]</annotation> <restriction base="string"> <enumeration value="mainRoad"> <annotation>[...]</annotation> </enumeration> <enumeration value="firstClass"> <annotation>[...]</annotation> </enumeration> [...] </restriction> </simpleType> Cet extrait indique essentiellement que le type FunctionalRoadClassValueType peut prendre l’une des valeurs suivantes : « mainRoad », « firstClass »… Bien sûr, d’autres types de restrictions peuvent être décrits dans les schémas XML (cf. ici).
Le schéma des données permet donc à l’application cliente de présenter un formulaire de saisie ou de recherche adapté à ce type de contrainte (une liste déroulante, une case à cocher ou des boutons radios). Encore faut-il que :
- le schéma publié par le service WFS reflète les contraintes définies au niveau de la base de données elle-même ;
- l’application cliente possède « l’intelligence » nécessaire à l’interprétation de ces contraintes.
En complément, on peut noter que :
- l’expression de contraintes sur les attributs peut également être exprimée à l’aide d’autres langages que les schémas XML. Les schémas JSON sont une alternative possible (cf. ici) ;
- les schémas n’ont pas été conçus pour transmettre aux applications clientes les traductions dans le langage naturel de l’utilisateur des valeurs codées utilisées par la base de données.
Merci pour ce billet. Je suis curieux de savoir si GeoServer est capable de construire ces énumérations dans les réponses DescribeFeatureType.
Effectivement, cela vaudrait le coup de jeter un œil aux différentes implémentations pour voir de quelles manières elles se comportent. Je ne pense pas que GeoServer sache gérer ce genre de restrictions. Son extension AppSchema apporte peut-être quelque chose. A étudier.
Du côté des applications clients, je ne connais pas d’implémentation « générique » qui sache exploiter ces restrictions. Si quelqu’un en connait, je suis preneur de l’information.
Pour information, la question de l’exploitation de restrictions de valeurs par des applications clientes a été posée lors de la présentation des résultats du test d’interopérabilité de solutions clients/serveurs WFS (solutions libres et commerciales – GeoServer n’était pas représenté). Aucun des intervenants n’a indiqué que sa solution savait gérer ce cas de figure.
GeoExt fournit des classes/fonctions pour produire des champs de formulaire à partir de réponses DescribeFeatureType, et beaucoup de contraintes sont prises en compte. Je ne pense pas que les contraintes de type énum soient actuellement prises en compte (notamment parce que GeoServer ne les gère pas), mais ce serait assez facile à ajouter—création d’un combo.
Merci pour les infos sur GeoExt. Effectivement, il n’y avait pas de client basé sur GeoExt utilisé lors du test d’interopérabilité du FOF.
Petit commentaire en passant : ce serait dommage que GeoExt ne supporte pas certaines fonctionnalités uniquement parce que GeoServer aurait certaines limitations.
Biensûr. Mais GeoExt est développé au fur et à mesure des besoins, et les besoins au niveau de GeoExt, et des client OGC en général, apparaissent une fois les serveurs prêts. Donc le jour où GeoServer ou MapServer prend en charge ces énums GeoExt suivra assez rapidement je pense, parce que le besoin se fera ressentir.
Fait dans GeoExt : .
Je ne pensais que mon article aurait des répercussions sur des implémentations clientes de WFS. Merci pour ce travail.