Service de mise en correspondance des données tabulaires (TJS)

Aperçu

Le service de mise en correspondance des données tabulaires (TJS) définit une manière simple de décrire et d’échanger des données tabulaires qui contiennent des renseignements sur des entités géographiques. Il met en correspondance des données des attributs (qui désignent des entités spatiales, ou des données géoliées) avec un ensemble de données géospatiales pour qu’un service de cartes Web (WMS) puisse l’insérer dans une carte ou qu’un système d’information géographique (SIG) puisse l’utiliser. Il constitue le service frontal d’un service de cartes Web et permet la représentation graphique en temps réel des données enregistrées dans des bases de données non spatiales.

Le service de mise en correspondance des données tabulaires utilise les attributs d’un ensemble de données géoliées et les fusionnent avec un ensemble connexe de données géospatiales afin de produire un ensemble combiné de données géospatiales qui contient ces attributs. La fusion des ensembles de données repose sur l’utilisation d’un champ de liaison commun aux deux ensembles de données (champ clé). Le service permet la publication de renseignements au moyen d’un service de cartes Web (WMS) existant. L’ensemble connexe de données géospatiales peut résider localement ou être fourni par un service d’entités géographiques Web (WFS).

Presque toutes les bases de données d’entreprises contiennent un certain type d’identificateur géographique, peu importe si la base de données héberge dans un environnement informatique soutenant un SIG. Un identificateur géographique peut être un code postal, le nom d’une ville, un indicatif régional, ou un identificateur polyvalent, comme un arrondissement scolaire. La technologie de liaison géospatiale permet la recherche et l’utilisation des données d’une entreprise à des fins de cartographie et d’analyse spatiale.

Information supplémentaire

Norme

OpenGIS® Georeferenced Table Joining Service Implementation Standard

Renseignements connexes

Service de cartes Web (WMS)

Service d’entités géographiques Web (WFS)

Service de traitement Web (WPS)

Note

Selon les travaux initiaux entrepris dans le cadre de l’Infrastructure canadienne de données géographiques (ICDG), la norme TJS a été publiée par l’Open Geospatial Consortium (OGC).

Information supplémentaire - service de mise en correspondance des données tabulaires (TJS)

Élaboration de la norme TJS

Liaison des données des attributs à un cadre géographique

Optimisation de la gestion des données

Élaboration de la norme TJS

Cette norme résulte des travaux entrepris initialement à l’appui de l’ICDG et, en particulier, du Système d’information sur les sols du Canada (SISCan) et du Système national d’information sur les forêts (SNIF). Elle a été mise en œuvre sous forme de prototype en 2002 par Agriculture et Agroalimentaire Canada (AAC). En 2004, l’Open Geospatial Consortium (OGC)® a publié un jeu de documents de travail (04-010: Geolinked Data Access Service (GDAS) et 04-011: Geolinking Service (GS)).

Le concept et les interfaces connexes ont été peaufinés pour donner lieu à la recommandation de diverses améliorations qui doivent être apportées aux normes, y compris leur fusion en une seule norme, publiée sous forme du service de liaison des données géographique (Geographic Linkage Service – GLS) en 2008, en même temps qu’une demande de commentaires de l’OGC.

La version actuelle, c.-à-d., le service de mise en correspondance des données tabulaires (TJS), comprend d’autres recommandations et remplace tous les documents antérieurs.

Pour illustrer l’évolution des documents, voyons la figure suivante :

Liaison des données des attributs à un cadre géographique

Le service TJS précise la manière de lier un tableau de données spatiales, dont les attributs réside sur un serveur, à un cadre spatial hébergé sur un autre serveur.

Le service TJS est un service Web qui procure une méthode uniformisée d’accéder aux données des attributs et de les lier à un cadre géographique connexe. Les données des attributs constituent un ensemble de valeurs référencées à un ensemble d’entités géographiques exemptes d’emplacements spatiaux. Les attributs des données géographiques sont en général présentés sous forme de données tabulaires (comme les chiffres de la population) qui désignent un cadre connu (comme les provinces), où un identificateur unique (comme le nom de la province) fait référence aux éléments (les provinces). La population, la température et le revenu sont tous des exemples de données des attributs qui peuvent référencer un cadre géographique.

Les identificateurs géographiques (ou les attributs) utilisés dans les bases de données d’entreprises font en général référence à un cadre géographique (ou spatial). Dans ce contexte, un cadre géographique est une subdivision de la surface terrestre qui représente une unité de gestion. Les municipalités, les écorégions et les bassins hydrologiques sont tous des exemples de cadres géographiques qui ont un élément en commun – ils contiennent un descripteur qui peut servir à identifier de manière distincte toute unité de gestion. Ce même descripteur, ou identificateur, se trouve dans la base de données de l’entreprise. Voyons quelques contenus de bases de données et leurs cadres géographiques :

• ventes selon la succursale ou la municipalité;
• paiements d’assurance selon le code postal;
• numéros de téléphone selon l’indicatif régional;
• fermes selon la région agricole de recensement;
• élèves selon l’arrondissement scolaire.

Pour permettre la cartographie ou l’analyse géospatiale, le service TJS offre une manière :

• de présenter géographiquement les données désignées des bases de données d’entreprises à d’autres ordinateurs pour en permettre la recherche et l’accès;
• de fusionner ces données avec les données qui décrivent le cadre géographique.

Optimisation de la gestion des données

Les données tabulaires échangées par le service TJS doivent comporter un identificateur géographique, qui désigne une entité spatiale dans un ensemble distinct de données géospatiales. Pour lier les données tabulaires à un autre ensemble de données, les deux ensembles de données doivent contenir le même identificateur géographique (c.-à-d., champ clé). Comme exemple de données tabulaires, supposons un ensemble de chiffres de population selon la ville. Le tableau comprend les noms des villes et aucun autre identificateur géographique. Ces noms peuvent servir à lier les données de la population à une couche d’un SIG qui contient les coordonnées spatiales de chaque ville, pour ainsi mettre en correspondance l’information ou effectuer une analyse géospatiale.

Le service TJS procure une manière uniformisée simple d’échanger des renseignements sur les attributs propres à un ensemble de données géospatiales bien connues (un ensemble de données cadre). Les renseignements sur les attributs fournis par le service TJS peuvent servir de diverses manières, y compris avec des modèles pour effectuer des calculs ou pour les visualiser sur une carte Web.

La norme TJS a pour avantage de permettre à une organisation d’héberger ses données dans des systèmes dont la gestion est optimisée et de profiter de la technologie du SIG pour examiner et analyser ces données. En outre, la norme procure les avantages suivants :

• elle est simple à mettre en œuvre;
• elle est conviviale;
• elle est légère;
• elle est très adaptable;
• elle est multifonctionnelle.

La norme TJS permet la tenue à jour des données d’une entreprise à proximité de sa source et l’obtention des données les plus actualisées lors d’une analyse, peu importe si le système géospatial peut établir une connexion directe avec le système de gestion des données de l’entreprise. La présentation des données par un service TJS permet aux gestionnaires des données de l’entreprise de modifier la conception de la base de données sous-jacente et les mesures de sécurité sans compromettre l’accès aux données accessibles aux autres systèmes. En fait, le service TJS reconnaît la gestion répartie des données et le traitement réparti des données géospatiales.

Opérations reconnues par le service TJS

Le service TJS reconnaît des opérations avec lesquelles un client peut interagir avec la mise en œuvre connexe. Chaque opération appuie la recherche du service, la recherche des données et leur accès ou la liaison des données des attributs à un cadre spatial.

Toutes les instances du service TJS doivent mettre en œuvre l’opération de recherche du service (GetCapabilities). Elles peuvent choisir de mettre en œuvre les opérations de recherche des données et d’accès aux données ou les opérations de liaison des données, ou les deux. La mise en œuvre de l’un de ces groupes d’opérations exige la mise en œuvre de toutes les opérations du groupe.

Opération de recherche du service (obligatoire)

• GetCapabilities– Avec cette opération, un client demande et reçoit les documents des métadonnées (ou les fonctions) du service qui décrivent les fonctions propres à la mise en œuvre du serveur. L’opération reconnaît aussi la négociation de la version de la norme utilisée lors des échanges entre le client et le serveur.

Pour demander un document des fonctions d’un service TJS, un client peut envoyer la requête d’opération GetCapabilities suivante codée en format KVP avec un contenu minimal :

http://foo.bar/foo&service=TJS&request=GetCapabilities

Opérations d’accès aux données(optionnelles)

Le service TJS comporte quatre opérations qui appuient la récupération des données des attributs géospatiales. La livraison des données des attributs se fait au moyen de l’opération GetData. Plusieurs opérations sur les métadonnées connexes procurent des renseignements sur les données des attributs que peut obtenir le service TJS.

• DescribeDatasets– Permet au client d’obtenir les descriptions générales des tableaux de données des attributs accessibles sur le serveur. Le serveur doit permettre un transfert HTTP GET pour cette opération au moyen du codage KVP, qui utilise les paramètres précisés dans la norme. Le codage XML de la requête est optionnel, au moyen de HTTP POST. Voyons un exemple d’une opération DescribeDatasets valable codée en format KVP pour HTTP GET :

http://foo.bar/foo?

Service=TJS&
Version=1.0&
Request=DescribeDatasets&
FrameworkURI=http://foo.bar2/Provinces/2001&
Language=fr-CA

• DescribeData – Permet au client d’obtenir une liste qui décrit le contenu précis des données des tableaux de données des attributs (c.-à-d., les attributs) accessibles sur le serveur. Le serveur doit mettre en œuvre un transfert HTTP GET pour cette opération au moyen du codage en format KVP, qui utilise les paramètres précisés dans la norme. Le codage XML de la requête est optionnel, au moyen de HTTP POST. Voyons un exemple d’une opération DescribeData valable codé en format KVP pour HTTP GET :

http://foo.bar/foo?

Service=TJS&
Version=1.0&
Request=DescribeData&
FrameworkURI=http://foo.bar2/Provinces/2001&
DatasetURI=http://foo.bar/2001Census/2001&
Language=fr-CA

• DescribeFrameworks– Permet au client d’obtenir une liste des cadres spatiaux pour lesquels le serveur contient des données géotabulaires. Le serveur doit mettre en œuvre un transfert HTTP GET pour cette opération au moyen du codage en format KVP, qui utilise les paramètres précisés dans la norme. Le codage XML de la requête est optionnel, au moyen de HTTP POST.Voyons un exemple d’une opération DescribeFrameworks codée en format KVP pour HTTP GET :

http://foo.bar/foo?

Service=TJS&
Version=1.0&
Request=DescribeFrameworks&
Language=fr-CA

• GetData– Permet au client d’obtenir un ensemble précis de données géotabulaires. Le serveur doit mettre en œuvre un transfert HTTP GET pour cette opération au moyen du codage KVP, qui recourt aux paramètres précisés dans la norme. Le codage XML de la requête est optionnel, au moyen de HTTP POST. Voyons un exemple d’une opération GetData valable codée en format KVP pour HTTP GET :

http://foo.bar/foo?

Service=TJS&
Version=1.0&
Request=GetData&
FrameworkURI=http://foo.bar2/Provinces/2001&
DatasetURI=http://foo.bar/2001Census&
Attributes=cattlecalves,cows&
LinkageKeys=10-13,24,35,46-48&
XSL=http://foo.bar/xslt

Les résultats de ces opérations sont un ensemble de données, un cadre et les métadonnées des attributs qui décrivent les données accessibles sur l’instance du serveur. Ces résultats peuvent servir à garnir des registres du service. Si le service TJS reconnaît l’accès aux données, toutes ces opérations sont alors obligatoires.

Opérations de liaison des données (optionnelles)

Le service TJS comporte trois opérations qui reconnaissent la liaison des renseignements sur les attributs à sa géométrie. La fusion des données se fait au moyen de l’opération JoinData. L’opération DescribeJoinAbilities connexe donne des renseignements sur les cadres spatiaux auxquels il est possible de lier les attributs, alors que l’opération DescribeKey donne le contenu du champ clé du cadre propre à un ensemble de données du cadre. Si l’instance du service reconnaît la liaison des données, toutes les prochaines opérations sont alors obligatoires.

• DescribeJoinAbilities– Donne un document XML qui désigne tous les cadres spatiaux auxquels l’instance du service peut lier les données des attributs. La description comprend des renseignements qui désignent de manière distincte chaque cadre spatial et des renseignements descriptifs de chaque cadre utilisé pour appuyer la recherche du service et garnir les registres du service. Le serveur doit mettre en œuvre un transfert HTTP GET pour cette opération au moyen du codage KVP qui utilise les paramètres précisés dans la norme. Le codage XML de la requête est optionnel, au moyen de HTTP POST. Voyons un exemple d’une opération DescribeJoinAbilities codée en format KVP pour HTTP GET :

http://foo.bar/foo?

Service=TJS&
Version=1.0&
Request=DescribeJoinAbilities&
Language=fr-CA

La réponse normale à une opération DescribeJoinAbilitiesvalable est une structure de données JoinAbilities, qui contient des descriptions d’au moins un cadre auquel le serveur peut lier des tableaux de données.

• DescribeKey– Donne un document XML qui désigne toutes les clés d’un cadre spatial auquel l’instance du service peut lier des données. La description comprend aussi des renseignements descriptifs du cadre spatial. La liste peut servir à déboguer l’opération JoinData ou à créer un nouvel ensemble de données des attributs pour le cadre spatial. Le serveur doit mettre en œuvre un transfert HTTP GET pour cette opération au moyen du codage KVP qui utilise les paramètres précisés dans la norme. Le codage XML de la requête est optionnel au moyen de HTTP POST. Voyons un exemple d’une opération DescribeKey codée en format KVP pour HTTP GET :

http://foo.bar/foo?

Service=TJS&
Version=1.0&
Request=DescribeKey&
FrameworkURI=http://foo.bar/foo&
Language=fr-CAc

La réponse normale à une opération DescribeKe y valable est une structure de données FrameworkKeyDescription, qui dresse la liste de tout le contenu du champ FrameworkKey pour lequel le serveur reconnaît l’opération JoinData.

• JoinData– Indique au serveur de fusionner le tableau des données des attributs codé dans un format GDAS (ensemble des attributs des données géographiques) (c.-à-d., accessible au moyen d’une requête GetData) avec son cadre spatial. Le serveur effectue la liaison et prépare les résultats sous la forme demandée par le client. Les résultats comprennent les renseignements sur la liaison nécessaire pour accéder aux données de sortie. Le serveur doit mettre en œuvre un transfert HTTP POST pour cette opération au moyen du codage KVP qui utilise les paramètres précisés dans la norme. Le serveur peut aussi mettre en œuvre un transfert HTTP POST de l’opération JoinDataau moyen du codage XML, conformément au schéma XML tjsJoinData_request.xsd. Noter que l’utilisation de ce codage XML procure d’autres fonctions pour cette requête, p. ex., des options pour la partie GetData de la requête JoinData au moyen de HTTP GET ou de HTTP POST. Voyons un exemple d’une opération JoinData codée en format KVP pour HTTP POST :

Service=TJS&
Version=1.0&
Request=JoinData&
Language=en-CA&
FrameworkURI=http://foo.bar2/foo& 
GetdataURL="http://foo.bar2/foo& 
StylingURL="http://foo.bar3/foo&
StylingIdentifier=SLD_1.0

Le résultat normal d’une opération JoinData valable est une structure de données JoinDataResponse, qui contient une copie de la requête, l’état de l’exécution et des références aux résultats créés par le service.

Autres ressources d’information

La norme OpenGIS® Georeferenced Table Joining Service Implementation Standard donne une définition d’une interface standard pour un service TJS qui s’applique à la création et à l’utilisation d’un service TJS. La norme comprend une définition de toutes les requêtes et des réponses du service TJS, y compris la spécification du format de codage GDAS au moyen du langage XML (version 1.0). La norme ne porte pas sur l’archivage, le catalogage, la recherche ou la récupération des documents XML sur le codage GDAS ou autres documents XML sur le service TJS.

Le site Web http://geoprocessing.info/tjsdoc/index procure un contexte important sur le service TJS, un glossaire et la procédure d’inscription et d’accès à un service TJS.