1. Introduction

Au moment où l’on reparle d’imposer l’utilisation du format EDIGEO pour l’échange de certains jeux de données géographiques, il nous a semblé opportun de présenter une série d’articles sur GML, format que tout le monde connait de nom mais qui est finalement peu utilisé malgré ses nombreuses qualités.

Ce premier article est consacré à la description générale de GML.

Un second article décrira de manière plus détaillée les capacités de validation offertes par GML.

Un troisième et dernier article sera consacré à une étude de cas : l’utilisation de GML par la Communauté Urbaine du Grand Lyon.

2. Description générale

GML (Geography Markup Language) est un standard de  l’OGC (Open Geospatial Consortium) pour la représentation des entités géographiques vectorielles. La version 3.2.1 de GML  a été normalisée en 2007 par l’ISO (Norme ISO 19136).

GML n’est pas un format à proprement parler mais un langage qui permet de définir ses propres formats.

GML est un langage dérivé de XML, particulièrement conçu pour permettre la représentation d’entités, notamment d’entités géographiques. Une entité est un objet concret ou abstrait du monde réel : une route, une parcelle, une société, une personne…

Une entité peut être caractérisée par ses propriétés géométriques et non géométriques. Par exemple, une route (entité) peut être décrite par son identifiant, sa largeur, son état et la géométrie de son axe qui représentent autant de propriétés. Les entités de même type sont regroupées en types d’entités. Par exemple l’autoroute « A9 » et la « RN113 » sont deux entités du type d’entités « ROUTE ».

Là où XML ne connait que les notions d’éléments et d’attributs, GML apporte donc des concepts très proches de ceux employés par les utilisateurs d’information géographique et les informaticiens de manière générale : types d’entités, entités, propriétés, géométrie, système de coordonnées…

Contrairement à KML ou SVG, autres langages XML destinés à représenter des données géographiques, GML n’est pas lié à une technologie particulière (Google Earth pour KML, navigateur web pour SVG).

L’utilisation potentielle de GML est beaucoup plus large et il est possible de l’utiliser comme format d’échange ou dans le cadre de services de type WFS.

Les formats conformes à GML bénéficient des avantages de XML. Parmi d’autres qualités, on peut dire qu’ils sont :

• ouverts
• définis de manière formelle
• lisibles et compréhensibles par une machine ou un humain
• validables
• distribués (les données peuvent être regroupées dans un seul document ou bien réparties sur plusieurs serveurs)
• réutilisables (par héritage des types décrits dans les schémas d’application)
• manipulables par des outils génériques avec des langages et techniques standardisés : xPath, xQuery, xslt…

Toutes ces qualités n’empêchent d’ailleurs pas de pouvoir produire des choses horriblement complexes en GML. Un bon outil ne suffit pas à produire des chefs-d’œuvre…

3. Création d’un format GML

GML a déjà servi à créer de nombreux formats : CityGML, GeoSciML, Dutch Top 10 GML, German AA-GML, NEN3610, AIXM…

Mais il ne faut pas croire que seuls des formats riches et complexes tels que ceux-ci peuvent bénéficier de GML. Nous allons le démontrer en créant en quelques lignes un nouveau format.

3.1 Schéma d’application

Pour créer un nouveau format GML, il suffit de décrire un schéma d’application.

Un schéma d’application est un simple fichier au format Schema XML  « .xsd » (http://fr.wikipedia.org/wiki/XML_Schema) qui permet de décrire totalement et de manière formelle la structure d’un format.

Un schéma d’application a des caractéristiques très intéressantes :

• il permet de remplacer des centaines de pages de spécifications ;
• il permet de décrire un modèle de données ainsi que l’ensemble des contraintes associées (clé primaire, intégrité référentielle, domaine de valeurs…) ;
• il permet de valider des documents contenant les données, c’est à dire de vérifier si un fichier de données est totalement conforme aux spécifications du format.

Pour détailler le contenu d’un schéma d’application nous allons créer un nouveau format : « big ».

Le format « big » est destiné à décrire un seul type d’entité « Departement », lui-même composé de deux attributs « NOM » et « POPULATION ».

La figure ci-dessous montre le schéma d’application correspondant :

Figure 1 : Exemple de schéma d'application GML

Sans trop rentrer dans les détails, il est intéressant de décrire grossièrement le contenu de ce fichier.

3.1.1 Espace de nommage

Le schéma d’application GML doit déclarer un espace de nommage cible qui correspond à l’espace de nommage dans lequel les types du schéma d’application sont déclarés. La déclaration est effectuée dans les attributs de l’élément racine :

L’espace de nommage est une URI (Uniform Resource Identifier) contrôlée par l’organisation qui génère le schéma d’application (Veremes dans notre exemple). Cette URI est simplement utilisée comme identifiant unique pour éviter les confusions entre types de même nom définis par deux organismes différents.

Tous les espaces de nommage utilisés dans ce schéma sont également déclarés avec leur préfixe (gml, xlink, big). Ce préfixe est utilisé dans le document XML pour identifier l’origine des éléments et attributs. Dans notre exemple le préfixe de l’espace de nommage cible est « big » :

3.1.2 Importation des types GML

La ligne suivante permet d’importer la définition de tous les types prédéfinis par GML et décrits dans le schéma « gml.xsd » :

Il est nécessaire d’importer ces types prédéfinis pour pouvoir déclarer un nouveau type par héritage, par exemple pour la définition des types d’entités.

3.1.3 Définition des types d’entités

La définition d’un type d’entités s’effectue obligatoirement par dérivation (héritage) du type GML prédéfini AbstractFeatureType.

Ainsi, les lignes suivantes définissent un nouveau type « DepartementType » dérivé de « AbstractFeatureType » et affectent ce type à l’élément « Departement » » qui devient ainsi un type d’entités au sens GML.

3.1.4 Définition des attributs/propriétés

Pour éviter toute confusion entre les définitions « base de données » et  « xml » du terme « attribut », il est préférable de parler de propriétés.

Le schéma décrit donc trois propriétés pour les objets du type d’entités « departement » :  « NOM », « POPULATION » et la géométrie qui est décrite par le type GML « surfaceProperty ». Ce type permet de représenter la géométrie d’un polygone simple.

3.2 Structure d’un document GML

Le code suivant montre un exemple de document au format « big ». Ce document contient la description d’un département conformément au schéma d’application défini précédemment.

Figure 2 : Exemple de document GML au format big

Sans trop rentrer dans la structure on peut faire les constatations suivantes :

• le fichier est lisible. On y trouve en effet sans difficulté le nom du type d’entité « Departement », les attributs « NOM » & « POPULATION » et leurs valeurs ainsi que la géométrie (système de coordonnées et coordonnées).
• toutes les entités contenues dans le document sont décrites sous l’élément « gml:featureMember » dans un sous-élément portant le nom du type d’entité (« big:Departement » dans notre exemple)
• les propriétés (attributs) de l’entité sont décrites sous forme d’éléments et non d’attributs XML
• dans cet exemple, l’élément « gml:surfaceProperty » décrit la géométrie de l’objet mais il existe un grand nombre de types permettant de représenter une grande diversité de structures géométriques simples ou complexes (2D ou 3D)
• l’emplacement du schéma d’application est défini dans l’attribut xsi:schemaLocation de l’élément racine. La valeur « http://www.veremes.com/big big.xsd » peut se lire ainsi : le schéma d’application correspondant à l’espace de nommage « http://www.veremes.com/big » est le fichier « big.xsd » (même répertoire que le jeu de données source). Pour éviter de fournir le fichier .xsd avec le fichier .gml il est généralement préférable de déposer le schéma d’application sur Internet et de fournir une définition du type « xsi:schemaLocation= »http://www.veremes.com/big http://www.veremes.com/schemas/big.xsd » »

A titre de comparaison, l’image ci-dessous montre la description des attributs d’une parcelle dans un fichier EDIGEO :

Figure 3 : Extrait d'un fichier Edigeo décrivant la valeur des attributs d'une parcelle

La différence avec l’exemple GML précédent est évidente : dans un cas la structure de données est facilement compréhensible, dans l’autre il est nécessaire de faire appel à la documentation de référence pour essayer de comprendre comment est structurée l’information.

3.3 Validation

Un des grands intérêts des documents GML est leur capacité à être facilement validés.

La validation permet d’assurer que le document est totalement conforme au schéma d’application du format.

Pour valider un document GML il suffit d’utiliser un outil de validation XML. Il en existe de nombreux, libres  ou propriétaires, en ligne ou autonomes.

Par exemple, si nous modifions le document précédent en attribuant une valeur décimale à l’attribut « POPULATION » alors qu’il est défini comme un entier, la validation va générer un message d’erreur :

Figure 4 : Message d'erreur lors de la validation d'un document GML (logiciel XMLSpy)

La validation n’est pas un gadget. C’est une fonctionnalité indispensable à la création de tous nouveaux formats dès lors que l’on cherche à satisfaire les exigences minimum de qualité. La validation permet d’économiser de nombreux coûts et facilite l’automatisation des chaînes de production.

Sur le terrain de la qualité, la possibilité de valider un jeu de données est sans doute plus importante que la normalisation du format.

Bien qu’Edigeo soit une norme AFNOR, l’absence d’outils de validation publics a permis la diffusion d’un nombre important de fichiers non conformes avec tous les problèmes et les coûts que cela engendre :

• un fichier lisible par un logiciel X peut être non lisible ou afficher des données différentes dans un logiciel Y…
• il faut parfois modifier manuellement certains fichiers pour les rendre lisibles par certains logiciels.

Dans la suite de cet article nous verrons comment il est possible d’implémenter des structures de données complexes avec GML et comment spécifier des contraintes particulièrement utiles dans un schéma d’application : unicité, intégrité référentielle, domaines de valeurs…

Auteurs : Olivier Gayte (Veremes) et Matthieu Ambrosy (Veremes)