Blog Interopérabilité & GéoInformation

Table Joining Service est un des tout derniers standards mis au point par l’Open Geospatial Consortium. Si cette norme a rapidement suscité un intérêt en France, on le constate dans les cahiers des charges qui sortent, c’est parce que :

• elle soulage les gestionnaires d’applications statistiques, qui peuvent intégrer sans effort dans leurs bases des données prêtes à l’emploi ;
• elle ouvre aux utilisateurs d’observatoires un large éventail d’indicateurs utilisables : avec TJS, ils se connectent de façon transparente à de nombreux serveurs de données ;
• elle offre un format de sauvegarde intelligent de jeux de données documentées : les méta-données permettent de définir automatiquement les bons retraitements et les bonnes représentations cartographiques en fonction des caractéristiques propres des indicateurs ;
• elle est facile à implémenter, en tout cas beaucoup plus facile que GML.

TJS est le chaînon manquant entre WMS et GML. WMS distribue des images, qui sont certes d’emploi immédiat, mais offrent peu de possibilités de retraitements, d’extractions ou de valeur ajoutée. GML est un format verbeux et complexe. Son polymorphisme rend l’écriture de modules de décodage génériques rebutante. A contrario, TJS délivre des fichiers compacts, simples à lire et à générer. Ils peuvent s’intégrer dans toute sorte de retraitements, dans l’esprit des Web Processing Services. Ce n’est d’ailleurs pas un hasard si les standards WPS et TJS ont le même « Papa », à savoir le Canadien Peter Schüt.

Certains lecteurs se disent sans doute : « TJS, c’est peut-être utile pour les statisticiens, mais quel rapport avec la géomatique ? » TJS part du constat que toute information statistique peut être géo-référencée. Par exemple une donnée de PIB concerne une région particulière, identifiable en France par un code à 2 caractères. Le nombre d’habitants d’un Iris est cataloguable car cet Iris a lui aussi un identifiant alphanumérique officiel. Les listes des régions, des communes, des Iris relèvent de référentiels normalisés. Si les premiers exemples qui viennent à l’esprit concernent des territoires (représentées par des polygones sur une carte), un référentiel géographique peut également se rapporter à des points (le répertoire Sirene associe un code unique à chaque établissement de France), ou à des lignes (ex : des tronçons routiers).

On ne tranchera pas ici le fait de savoir si la donnée statistique est un attribut de la donnée géographique (vision du géomaticien), ou si l’inverse est plus pertinent (vision du statisticien). TJS organise un découplage clair entre les référentiels géographiques, en nombre limité, et les données qui peuvent s’y rattacher, bien plus foisonnantes.

Ses concepteurs considèrent qu’il est absurde d’encoder ensemble, systématiquement, des données statistiques et des données géométriques, si cette géométrie relève de référentiels normalisés. Pour visualiser une série de cartes statistiques communales, on gagne à charger le fond de carte vectoriel d’abord, une fois pour toute, et à récupérer ensuite des jeux de données. La présence des mêmes codes géographiques dans le fond de carte et dans le jeu de données permet d’apparier les deux automatiquement et de produire des analyses thématiques.

TJS encode donc des données statistiques géo-référencées, relatives à un référentiel géographique clairement identifié. Un paquet TJS annonce par exemple : « les données qui suivent s’inscrivent dans le référentiel « communes de France », millésime 2010, identifié par telle URI, géré par tel organisme ». Mais le transfert de la géométrie n’est pas son propos.

Il présente ensuite les données. Un paquet TJS peut contenir un ou plusieurs jeux de données ou « datasets ». Par exemple un dataset « état civil » : naissances, décès et mariages par commune et par année depuis 10 ans, et un dataset « risques naturels » par commune (séisme, inondations, feux de forêt). Un dataset est documenté (libellé, producteur, date de publication, documentation, URL…).

Chaque dataset expose ses clés primaires (code géographique, année…) et ses variables statistiques. Une variable, documentée de façon littérale comme le dataset, peut être d’au moins 4 types différents : caractère, rang, numérique additif, numérique non additif. D’autres informations facilitent la cartographie automatique de ces variables : palette de couleur recommandée pour les typologies, caractéristique gaussienne ou pas de la distribution… La distinction additif / non additif est utile en cartographie thématique, elle permet de décider de la représentation (symboles proportionnels ou dégradé choroplèthe). Mais elle l’est aussi dans l’optique de traitements non cartographiques, comme l’agrégation des données à un niveau géographique plus large.

Les données enfin sont listées dans le paquet TJS ligne par ligne, dans des nœuds XML simplifiés.

Le format TJS est un format XML léger, à la fois précisément documenté et optimisé pour une lecture rapide des informations qu’il contient. Mais TJS est aussi un protocole de service web, répondant à différentes requêtes :

• getCapabilities : donne les caractéristiques générales du service, langages supportés, nombre maximal d’entités renseignées dans les paquets délivrés ;
• describeFrameworks : liste les référentiels géographiques mobilisés par le serveur TJS
• describeDatasets : liste les thèmes (ou jeux de données) proposés pour un framework donné ;
• describeData : décrit les variables de chaque dataset ;
• getData : renvoie les données d’un dataset pour un jeu de variables et des entités géographiques spécifiés.

TJS sépare la gestion des fonds de carte de celles des données statistiques. Il simplifie à ce titre la vie des géomaticiens et des statisticiens. Il fonctionne aussi comme intégrateur de différents services web. Le fond de carte peut être délivré par un service WFS, les données par un serveur TJS t1, l’appariement réalisé par un serveur TJS t2, le rendu final par un serveur WMS. Différents Web Processing Services peuvent s’enchaîner après extraction d’un flux TJS : agrégations, appariement entre différents datasets, mise à jour automatisée d’un autre entrepôt de données.

En France, nombre de collectivités territoriales et d’acteurs statistiques centraux ont perçu l’intérêt de TJS. Pourquoi gérer soi-même des données de cadrage de plus en plus nombreuses alors qu’on peut les obtenir dynamiquement via TJS, toujours à jour, auprès de l’Insee ou d’autres producteurs spécialisés ?

Rédacteur : Eric Mauvière

Pour en savoir plus :
www.opengeospatial.org/standards/tjs
geoprocessing.info/tjsdoc/
www.geoclip.fr/fr/p43_tjs.php