====== Les standards de l'OGC : WMS, WFS, WMC, WCS, WMC, WSC, ... ====== * Mailing-list : http://lists.eogeo.org/pipermail/wms-dev/ ===== Introduction ===== Ce document est constitué de plusieurs parties. Il s'agit ici de décrire les standards WebServices de l'OGC. Dans une première partie, plus générale, je décrirai ce qu'est un WebService, pourquoi devrait on les utiliser, à quoi sert l'OGC et son fonctionnement. Je donnerai ensuite quelques exemples de liens de WebService francophone et anglophone. Ensuite, je proposerai un certain nombre de logiciels client et serveur qui gère les standards de l'OGC. Dans une seconde partie, spécifique aux standards, je décrirai les WebServices proposés (principalement par l'OGC) avec quelques exemples de configuration pour un serveur (Mapserver UNN, Geoserveur, deegree, etc.). Cette partie sera séparée en deux sections qui contiendra les standards publiés pour la première section et les standards en discussion pour la deuxième section. ===== Généralité ===== ==== Qu'est ce qu'un WebService ? ===== <>. En géomatique un WebService propose un Service qui va permettre la prise en charge distante de données, soit pour l'affichage simple de carte (WMS), soit pour du stockage de données (WCS et WFS) soit pour du traitement distant pour éviter d'utiliser du temps d'utilisation du processeur et de la mémoire. En d'autre terme, une requête est effectuée à un serveur distant qui va réaliser la requête et renvoyer sa réponse sous forme de fichier XML, voire dans certain cas particulier un fichier image. Ces serveurs fonctionnent d'une manière équivalente à tout serveur : HTTP, SMTP, ... Plusieurs étapes sont nécessaires pour obtenir ce que l'on veut. Par exemple lors d'un envoi d'un mail, notre client va contacter le serveur d'envoi de mail (SMTP, le contact se fait par envoie d'une requête HELO ((Plus d'information sur les serveur SMTP : http://www.commentcamarche.net/internet/smtp.php3))), puis lui envoyer les données (l'adresse de l'expéditeur, puis l'adresse de destination et enfin le mail). Un autre exemple pris dans la vie réelle est l'exemple du bar. Lorsque vous voulez boire un verre, vous vous //déplacez// dans un bar, demandez la carte au //serveur//, vous lui //posez des questions sur les boissons// puis vous //commandez// votre commande. Nous retrouvons chacune des ces étapes dans un webservice, comme nous le verrons plus tard. Du côté des services spatiaux, notre client envoit une requête pour connaitre les possibilités du serveur (GetCapabilities), il peut demander une description supplémentaire pour une couche particulière puis demande les données, le traitement, (GetMap ou GetFeatureInfo dans le cas d'un WMS). Après chaque requête le client reçoit une réponse sous forme de fichier XML ou image dans le cas des WebService de l'OGC. En géomatique, un WebService est un service qui propose des cartes (WMS, WTS), des données brutes (WFS, WCS, GML, GeoRSS), des données sur les données ou méta-données (CAT), des informations sur la sémiologie (SLD), sur les données d'une carte (WMC), etc. ==== Autres définitions ===== Lorsque l'on parle de webservice, on parle rapidement de standard, de norme et d'intéropérabilité. Il est important de connaître les différences et la signification de ces termes. === Standard/Norme === <>((Source : http://fr.wikipedia.org/wiki/Standard)) D'après Gordon Bell (Microsoft) et Rob Gingell (Sun Microsystems), un standard : - Précise des points d'homogénéité, autorisant toute variété et toute innovation sur les points non spécifiés. - Se fonde par principe sur une spécification, pas une implémentation. - Importe plus que pour ce qu'il apporte à son utilisateur que par ses qualités propres. - Concerne et n'est censé affecter que la communauté qui y adhère. - Ne vaut que par l'efficacité de l'organisme qui confère les certifications à ce standard. - Ne doit pas, pour être adopté, « du passé faire table rase » - Doit laisser une place adéquate aux innovations futures - Disparaît quand il devient un obstacle à l'innovation au lieu d'en être une plateforme. Les standards de l'OGC sont normalisé par l'ISO. === Intéropérabilité === <>((Source : http://fr.wikipedia.org/wiki/Interop%C3%A9rabilit%C3%A9)) L'intéropérabilité permet ainsi une meilleure communication entre les différentes briques logiciels : client, serveur, à source ouverte ou propriétaire. Elle peut être considéré comme une langue universelle. Ainsi dans le monde réelle, nous trouvons des personnes qui parlent en anglais, d'autres en français, allemand, italien. La communication se fait mal, certaines personnes sont bilingues mais ce n'est jamais parfait. Une langue universelle, connu et surtout parlé de tous, simplifie la communication. ==== Pourquoi utiliser/proposer un WebService ?==== === Introduction === L'apport des webservice peut être classé en trois catégories : * mutualisation des compétences : travail collaboratif ; * mutualisation des données : utilisation de données communes à l'ensemble des utilisateurs, plutôt que de copier des répertoires sur chaque poste ; * mutualisation des ressources : décharger les ressources sur un serveurs commun pour éviter d'acheter x poste très puissant et souvent onéreux pour chaque géomaticien. Le fait que les webservices soient des standards apporte aussi une interopérabilité client-serveur, et une intéropérabilité historique. Vous pouvez migrer vos serveurs et vos clients d'une manière asynchrone : la transition sera plus fluide et donc moins problématique. Vous pouvez également coupler vos webservices avec différents clients : client lourd (arcgis, mapinfo, grass), client léger (udig, gvSIG, QGIS), webmapping (openlayers et ses dérivées mapfish, mapbender, mapbuilder, développement personnel, etc.). Ainsi vous éviter de multiplier les serveurs de données évitant des problèmes de gestion (quelle serveur a quelle version de donnés ?) Cela permet également des mapshup entre les différents services d'une société (services environnement, service production, service ...), entre différentes sociétés (ou collectivités bien sur), etc. La question pourrait aussi se poser à l'envers, pourquoi ne faut il pas proposer de webservice ? Si vos données évolues très peu, que vous ne voulez pas ou pouvez pas proposer ce genre d'infrastructure (coût, compétence). === Architecture à mettre en place === Plusieurs architectures réseaux peuvent être mises en place. Chaque architecture répondra à une problématique, mais ce qu'il faut comprendre est que les webservices permettent de s'adapter facile et de faire évoluer l'architecture en souplesse. ==== Logiciels ==== Il est possible de connaitre les logiciels en fonction des Web Service qu'ils implémentent à cette page : http://www.opengeospatial.org/resource/products/byspec/?specid=32 === Côté serveur === Les logiciels proposant un service par Internet : * Mapserver * GeoServer * QGIS * PyWPS * deegree (Web Services, iGeo3D et iGeoSecurtiy) * TinyOWS * ArcGIS Server * ... === Côté client === Les logiciels qui gèrent l'utilisation des webservices sont listés ci-dessous : ^^Logiciels ^^ WMS ^^ WFS ^^ WCS ^^ WAS/WSS ^^ WTS ^^ SOS ^^ WPS ^^ ||QGIS || Oui || Oui || Non || Non || Non || Non || Non || ||uDIG || Oui || Oui || Non || Non || Non || Non || Non || ||GvSIG || Oui || Oui || Oui || Non || Non || Non || Non || ||GRASS || Oui || Non || Non || Non || Non || Non || Non || ||JUMP || || || || || Non || Non || Non || ||ArcGIS || Oui || Oui || Oui|| Non || Non || Non || Non || ||Mapserver || Oui || Oui || Non || Non || Non || Non || Non || ||deegree || Oui || Oui || Oui || Oui || Oui || Oui || Oui || ||OpenLayers et dérivé || Oui || Oui || Non || Non || Non || Non || Non || === Astuces générales === == Cacher l'adresse du mapfile == Créer un fichier wms (ne pas oublier de le rendre éxécutable avec un //chmod g+x wms//) #! /bin/sh MS_MAPFILE=/vers/le/mapfile export MS_MAPFILE /vers/le/script/mapserv Puis appeller l'adresse http://0.0.0.0/vers/wms& pour appeller le webservice WMS. ==== Les points commun aux différents webservice ==== L'ensemble des webservices présentent des points communs, dans la manière de les structurer, dans les types de requête, les contraintes. Parmi ces dernières, certains caractères sont réservés : * ? : début de la liste des couples paramètres/valeurs, ''localhost/cgi/sript?...'' * = : séparation du paramètre de ces valeurs, ''parametre=valeur'' * & : séparation des couples paramètres/valeurs, ''parametre=valeur¶metre=valeur'' * ' : * + : remplace l'espace dans les valeurs. Du fait de la compatibilité historique, il est nécessaire que le serveur et le client sache quelle version doit être utilisée. * Questionnement du numéro de version du serveur : * Format de sortie des réponses : * texte : toujours xml * image : gif, png, jpeg, tiff, SVG, WebCGM ou tout autre format d'image lu par un navigateur. * Règles des variables dans les requêtes : * pas d'ordre * les paramètres ne doivent pas être sensible à la casse * les valeurs dans les listes de valeurs des paramètres doivent être séparé par des virgules. Si une valeur contient un espace ou une virgule, ceux-ci doivent être échappé. * les valeurs vides doivent être définie avec la chaine vide '' ==== Trouver des informations ou de l'aide sur ces standards ==== === Francophone === * Forum/liste sur Géorezo : [[http://georezo.net/forum/viewforum.php?id=38|Geolibre_web]] * Forum sur forumsig : http://www.forumsig.org === Anglophone === * Forum de l'OGC : http://feature.opengeospatial.org/forumbb/ [<<<>>>]