Infrastructures et web de données spatiales : OGC

L'Open Geospatial Consortium (OGC) est un consortium international qui a pour but de développer et promouvoir des standards ouverts afin de garantir l'interopérabilité des contenus, des services et des échanges dans les domaines de l'information géographique.

Les services web sont des fonctionnalités exposées sur Internet (ou un intranet, c'est à dire un internet privé) pour automatiser les échanges synchrones ou asynchrones entre systèmes informatiques.

• Intranet ou Internet → protocole HTTP et formats ouverts
• échanges synchrones → requête et réponse dans un cours laps de temps (flux)
• échanges asynchrones → lancement d'un long processus de traitement sur un serveur tiers et réponse à la fin du traitement

Les services Web facilitent l'interopérabilité entre systèmes informatiques en apportant des solutions aux contraintes de distance, de disponibilité, de formats, de sécurité.

Parmi les standards de l'OGC (http://www.opengeospatial.org/standards/) nous aborderons principalement :

• WMS - Web Map Service
• WMTS - Web Map Tiled Service
  
• WFS - Web Feature Service
• WCS - Web Coverage Service
• WPS - Web Processing Service
• CSW - Catalogue Service for the Web
• SLD - Styled Layer Descriptor
• FE - Filter Encoding

Les principaux services de l’Open Geospatial Consortium

Les points commun aux différents web-services

L'ensemble des web-services 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/script?...

= : séparation du paramètre de ces valeurs, parametre=valeur

& : séparation des couples paramètres/valeurs, parametre=valeur&parametre=valeur

+ : remplace l'espace dans les valeurs.

Du fait de la compatibilité historique (les normes évoluant au cours du temps), il est nécessaire que le serveur et le client sachent 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és" (c'est à dire qu'on utilise à la place le code correspondant au caractère. Par exemple """ pour le caractère """. Plus de détails ici.)
* les valeurs vides doivent être définie avec la chaine vide

Dans le cas des services web de l'OGC, le client envoie une requête HTTP (GET / POST) au serveur, par exemple GetCapabilities (pour connaitre les possibilités du serveur), et après chaque requête le client reçoit une réponse (flux) sous le format XML ou image (JEPG, PNG...).

Le protocole HTTP

L'HyperText Transfer Protocol (HTTP) est le protocole de communication client/serveur à l'origine du World Wide Web.

Les clients HTTP les plus connus sont les navigateurs Web.

La RFC 2616 du W3C définit les méthodes du protocole HTTP, dont notamment les quatre suivantes pleinement exploitées en architecture REST : GET (lecture), POST (tout type d’écriture), PUT (écriture à un endroit donné à la manière d’une valeur dans un tableau associatif) et DELETE (suppression).

NB : Les réseaux d'entreprise imposent souvent le passage par un serveur mandataires (proxy) ou un pare-feu pour assurer sécurité et performance. Les clients reçoivent alors une configuration propre au réseau utilisé.

Les méthodes GET et POST du protocole HTTP

La méthode GET n’est pas juste une manière de passer des paramètres dans l’URL. GET est une « méthode » (au sens d’une « fonction » d’un langage de programmation) du protocole HTTP. Par exemple l’URL http://monsite.com/ma-page?lang=fr  peut être utilisée par une requête HTTP de type GET ou POST.

S’il y a un paramètre, alors en GET il sera ajouté dans l’URL ce qui donnera : http://monsite.com/ma-page?lang=fr&mon_parametre=valeur en sachant que la taille de l'URL est limitée (variable selon navigateur/serveur). Concernant la sécurité, la requête GET apparaît dans les journaux de connexion. Dans une URL les paramètres peuvent être obligatoires (Required) ou facultatifs (Optional).

En POST l’URL est utilisée telle qu’elle est et les paramètres sont envoyés à côté.

Contrairement à la requête GET limitée (où on ne peut pas mettre tout ce qu'on veut dans l'URL) la requête POST permet de dépasser cette contrainte pour :

• • envoyer au serveur de nombreux paramètres
  • envoyer des fichiers
  • pour envoyer du XML ...

Suivi des échanges

Sur le navigateur FireFox, on peut utiliser l'outil de développement intégré ou aussi l’extension FireBug (qu'il faut installer). Cela peut nous aider à la compréhension et le suivi des échanges Client/Sserveur et le débogage en temps réel.

Même chose pour le navigateur Chrome (Bouton F12) avec encore plus d'options.

Pour comprendre les échanges (XHR = requêtes XML) on se met sur l'onglet Réseau

● temps de réponse par requête (temps serveur + temps de transit)

● poids

● paramètres envoyés

● contenu de la réponse

● + plein d'autres options

NB : Firebug ralentit sensiblement le navigateur.