Figure 29 Utilisation du Z39.50 avec un service de découverte de données géospatiales
La spécification des Métadonnées des données géospatiales de l'ICDG définit les normes de contenu d'après lesquelles des registres pairs sont considérés comme étant compatibles avec des registres de l'ICDG à des fins de conservation des descriptions de ressources de données géospatiales. Actuellement, l'ICDG a adopté la norme de contenu américaine Content Standard for Digital GeoSpatial Metadata du Federal Geographic Data Committee (norme CSDGM du FGDC) pour le registre des ressources de données géospatiales (voir l'annexe A2.3.3.1 sur la norme CSDGM du FGDC). On prévoit que l'ICDG adoptera également la norme ISO 19115 comme format pour le registre des ressources de données géospatiales (veuillez consulter l'annexe A2.3.3.2, Norme 19115 du TC 211 de l'ISO).
Le Service de découverte de données géospatiales est une spécification de l'ICDG pour la recherche de registres des ressources de données géospatiales et l'extraction de métadonnées au sujet de données géospatiales.
Il existe deux profils pour le Service de découverte de données géospatiales : avec état et sans état.
La spécification avec état du Service de découverte des données géospatiales est basée sur le protocole de recherche et d'extraction Z39.50. Le protocole Z39.50 est approuvé par l'organisme national de normalisation des États-Unis, l'ANSI, mais est largement utilisé dans de nombreux domaines d'application à travers le monde.
Le protocole Z39.50 est un protocole de recherche et d'extraction : il permet aux clients de rechercher des catalogues d'information sur Internet et d'extraire des détails sur les dossiers de catalogues qui correspondent aux critères de recherche. Alors que le HTTP est un protocole Internet de transfert hypertexte basé sur des requêtes d'information sous forme d'URL, le protocole Z39.50 est un protocole Internet pour l'extraction de métadonnées basé sur un ensemble de spécifications de recherche détaillées dans la requête. Tout comme une application basée sur le HTTP peut avoir sa propre spécification pour les paramètres d'une URL afin de demander et d'extraire des services par HTTP, il y a de nombreux « profils » de recherche et d'extraction d'information à l'aide du protocole Z39.50.
Les avantages du protocole Z39.50 sur le HTTP comprennent le fait que ces profils de recherche peuvent être propres à des communautés d'applications. Par exemple, le profil BIB-1 a été créé pour la communauté des bibliothèques pour l'exécution de recherches dans des catalogues de bibliothèques réparties et l'extraction de l'information pour les enregistrements qui correspondent à la recherche. Il y a également un profil GEO qui facilite la recherche spatiale, temporelle et textuelle de données géospatiales et permet l'extraction d'information des catalogues (métadonnées) pour les documents résultants.
De plus, le Z39.50 a l'avantage d'être un protocole avec état. Il diffère ainsi du HTTP, où le client envoie une requête au serveur, le serveur traite la requête, retourne le résultat au client, puis revient à son état initial. Dans le Z39.50, un client peut envoyer une requête de recherche au serveur et ensuite interrompre la connexion. Le serveur Z39.50 continue à traiter la requête et le client peut se rebrancher à la même session pour vérifier l'état de sa recherche ou pour effectuer une deuxième requête à l'intérieur de l'ensemble des résultats retournés à la suite de la recherche initiale. En outre, le client n'a pas à demander que tous les résultats lui soient retournés au cours de la même connexion avec le serveur. Par exemple, il peut demander les 50 premiers résultats, puis se retirer et faire son propre traitement des interactions avec l'utilisateur, retourner ensuite au serveur Z39.50 et demander les 50 résultats suivants. Au choix, le client pourrait envoyer plusieurs recherches différentes, mais pourrait consulter les résultats de n'importe laquelle de ses recherches en tout temps. C'est ce qu'on appelle la gestion constante de l'ensemble des résultats. Tout l'avantage d'un modèle avec état réside dans le fait qu'il permet à la composante logicielle du client d'interagir avec l'utilisateur, sans avoir à retourner et refaire la recherche si plus d'information s'avère nécessaire en fonction des résultats de la recherche précédente. Il permet également au client de continuer à dispenser ses propres services tout en attendant que le serveur termine la recherche.
Le profil GEO de la norme Z39.50 est largement utilisé dans des applications géospatiales pour effectuer des recherches simultanées dans de nombreux catalogues d'inventaires répartis sur Internet. Il constitue le moyen de rechercher un contenu géospatial, en utilisant un seul ensemble de critères de recherche, qui est conservé à la source des données (c.-à-d. au site du fournisseur) et décrit par des métadonnées dans les bases de données du fournisseur. Le profil de recherche GEO est basé sur l'ensemble d'attributs de la norme CSDGM du FGDC. On peut le considérer équivalent à une spécification d'encodage de filtre pour les métadonnées d'inventaire par le protocole Z39.50.
La figure 29 illustre comment le Z39.50 peut être utilisé par un utilisateur se raccordant à un service de découverte de données géospatiales, qui cascade ensuite simultanément vers plusieurs catalogues d'inventaires de fournisseurs pour rechercher des produits individuels.
Figure 29 Utilisation du Z39.50 avec un service de découverte de données géospatiales
Veuillez consulter le chapitre 7.2, Protocoles de recherche de l'ICDG, pour les trois opérations de base du Z39.50.
La spécification sans état est destinée à servir les mêmes buts que le Z39.50, pour la recherche dans des catalogues de données géospatiales d'inventaires sur Internet, sans exiger toutefois le déploiement de composantes Z39.50 spécialisées chez le client et le serveur.
Cette spécification est actuellement en cours d'élaboration. La spécification préliminaire documentée est disponible dans la page de description du service de découverte de données géospatiales de GéoConnexions, à l'adresse : (http://www.geoconnections.org/fr/communities/developers/standards/fa=technical.geodata_discovery_service ).
Il est vraisemblable que cette spécification sera conforme à la spécification d'implémentation des interfaces sans état pour catalogue (Stateless Catalogue Interface Implementation Specification) de l'OGC. Les interfaces de cette spécification sont conformes aux interfaces de type OGC, qui comprennent les opérations suivantes :
GetCapabilities
Comme avec la plupart des services définis par l'OGC, le serveur doit répondre à une requête GetCapabilities par un document XML conforme au schéma défini par la spécification. L'énoncé des capacités doit répondre en fournissant une liste des opérations et des langages de recherche pris en charge par le serveur, le type de schéma de données géospatiales utilisé pour les résultats (p. ex. norme CSDGM du FGDC ou norme ISO 19115) et d'autres renseignements particuliers sur la fonctionnalité du service de recherche.
DescribeCollectionSchema
Lorsqu'un identificateur d'inscription est précisé dans cette requête (lorsque l'identificateur d'une inscription provient du service de découverte de données géospatiales), le serveur doit répondre à l'aide du schéma XML pour l'enregistrement dans lequel l'inscription est codée. Si l'identificateur indiqué est 0, le serveur doit répondre à l'aide du schéma pour le répertoire des métadonnées.
GetRecords
Cette opération est utilisée pour extraire les métadonnées en XML de l'entrée demandée. Le XML doit être conforme au schéma pour la norme de contenu des métadonnées (ou le type de données géospatiales) dans lequel le document est conservé.
Pour trouver un contenu géographique sur Internet, les utilisateurs doivent pouvoir lancer une recherche dans l'ensemble d'Internet. Il doit y avoir un moyen commun pour indiquer les recherches de façon à ce que les serveurs les comprennent. L'OGC élabore des spécifications qui définissent les services qui doivent être pris en charge par des serveurs de recherche géographique. Cela permettra aux utilisateurs de trouver des objets géographiques qui possèdent des propriétés similaires.
La spécification sur l'encodage de filtre procure le moyen de définir la nature de ces propriétés; elle est utilisée pour filtrer les objets extraits des serveurs géospatiaux. En termes techniques, il s'agit d'un codage en XML du langage de recherche commun de l'OGC ou, en langage simple, un schéma XML pour préciser une recherche géographique.
Bien que l'encodage de filtre ne soit pas encore une spécification adoptée par l'ICDG, il le sera dans un avenir prochain.
La spécification sur l'encodage de filtre est une notation XML servant à préciser des recherches d'objets spatiaux. Cette spécification ne comporte aucune exigence pour la formulation ou le contenu de la réponse.
Des serveurs de recherche peuvent décrire des objets géographiques à l'aide d'un ensemble d'attributs (ou descripteurs). Le filtre limitera ces attributs à l'aide des propriétés de recherche suivantes :
Le Service de couverture Web (WCS) est une nouvelle spécification de l'OGC; il n'est pas encore approuvé comme spécification et n'est pas encore accessible au public. Les interfaces du service sont basées sur la définition d'une couverture dans la spécification abstraite de l'OGC (voir http://www.opengis.org/docs/03-065r6.pdf ) Par conséquent, le Service de couverture Web n'a pas encore été adopté par l'ICDG.
Une couverture constitue un type spécial d'entité. Il s'agit essentiellement de grilles multidimensionnelles irrégulières utilisées pour décrire de nombreux types de phénomènes terrestres en chaque point de ces grilles. Les couvertures offrent l'avantage que les relations entre diverses entités géographiques peuvent être représentées et dérivées. Des relations spatiales ou temporelles entre différents types d'entités peuvent être modélisées. De nombreux types de phénomènes différents peuvent être représentés sous forme de couvertures, incluant des lignes, des images, des superficies, des géométries, des vecteurs et des points.
Des implémentations interopérables mèneront éventuellement à des applications puissantes qui pourront effectuer par Internet des analyses comparables à celles que permettent les SIG.
Les serveurs du Service de couverture Web (WCS) prennent en charge les opérations suivantes.
GetCapabilities
Un serveur WCS doit répondre à une requête sur les capacités par un document XML conforme au schéma XMS des capacités, défini par la spécification de l'interface WCS. Les capacités doivent indiquer les opérations WCS et les opérations propres au fournisseur qui sont prises en charge par le serveur, des détails sur les types de données pris en charge par les services (y compris des spécifications d'interfaces) et des contraintes d'accès au serveur. Enfin, le serveur doit retourner des liens vers des catalogues externes qui contiennent et décrivent des métadonnées pour des couvertures utilisées par le service.
DescribeCoverage
Cette opération récupérera une description complète d'une ou de plusieurs couvertures disponibles par l'entremise du serveur WCS. La réponse doit avoir la forme d'un document XML conforme au schéma XML défini dans la spécification. Pour le client, c'est une façon de trouver les couvertures disponibles sur le serveur et, pour chaque couverture, de récupérer l'étendue spatiale, le système de référence, les formats acceptés et les types d'information que renferme la couverture.
GetCoverage
Un client peut récupérer une couverture complète, une couverture limitée par une région géographique ou un intervalle de temps, ou un sous-ensemble des types de couvertures. Cela peut se comparer à une capacité de « téléchargement de données », alors que l'utilisateur obtient les données (GeoTIFF, Shapefile, etc.) au lieu du GML ou d'une image.
La spécification sur des entités simples n'est pas encore adoptée par l'ICDG.
Des entités simples sont définies par les spécifications abstraites de l'OGC (voir http://www.opengis.org/docs/99-049.pdf, http://www.opengis.org/docs/99-050.pdf, http://www.opengis.org/docs/99-054.pdf), mais elles sont essentiellement des entités à deux dimensions où les sommets sont reliés par des lignes droites. Cette spécification comporte des interfaces pour représenter et manipuler des points, des lignes, des polygones, des courbes, des surfaces, des géométries, etc.
Reconnaissant que différentes architectures de communication et de bases de données exigent des architectures différentes d'implémentation, l'OGC publie des spécifications pour l'entreposage et l'extraction d'entités simples au moyen de diverses plates-formes. Ces architectures d'implémentation sont élaborées pour :
Par exemple, la spécification SQL offre un schéma SQL pour la gestion d'entités simples par le biais d'une interface ODBC (interface universelle de connexion aux bases de données) (object database connectivity interface). L'ODBC est une interface indépendante de la plate-forme permettant à une application (dans ce cas, le service Web) d'interagir avec n'importe quel type de base de données relationnelle, à l'aide du SQL.
La figure 30, Architectures SQL, CORBA® et OLE, montre la nature de ces architectures destinées à prendre en charge des services de type OGC à titre d'architectures de système indépendantes de la plate-forme.
Figure 30 Architectures SQL, CORBA® et OLE
La spécification sur les services de transformation de coordonnées n'est pas encore adoptée par l'ICDG.
Les services de transformation de coordonnées peuvent être considérés comme un sur-ensemble des services d'entités simples. La spécification comporte des ensembles distincts d'interfaces pour le positionnement, pour les systèmes de coordonnées et pour les transformations de coordonnées. Elle comprend des interfaces pour la création, la gestion, la transformation et la description de systèmes de coordonnées multidimensionnels. Le profil peut prendre en charge tous les systèmes de coordonnées de l'European Petroleum Survey Group (EPSG), ainsi que des systèmes de coordonnées multidimensionnels et non géoréférencés. Cette spécification comporte des profils pour COM, CORBA® et Java.