De la modélisation spatio-temporelle vers GML

Phi Phi Wang

Mémoire présenté sous la direction du Professeur Esteban Zimányi en vue de l’obtention du grade de Licencié en Informatique

Année académique 2007–2008

MEMBRE DE L’ACADÉMIE UNIVERSITAIRE WALLONIE-BRUXELLES ET DU PÔLE UNIVERSITAIRE EUROPÉEN BRUXELLES WALLONIE

FAC U LT É D E S S C I E N C E SD É PA R T E M E N T D ’ I N F O R MAT I q U E

Remerciements�

��

Je remercie toutes les personnes qui ont contribué de près ou de loin à ce travail. En particulier, je tiens à exprimer ma gratitude à Monsieur Zimányi, Directeur de ce mémoire, pour ses conseils judicieux et pour son encadrement tout au long de l’évolution de ce travail. Je remercie également Monsieur Devillers pour ses corrections et recommandations et Monsieur Hernalsteen pour son aide. Je remercie de tout coeur Arthur Decugnière, Geoffroy Cruxifix, Evelina Klopotowska, Prakash Fakun et Laurent Exteens pour leur soutien. Enfin, Je voudrais remercier ma mère et ma famille pour les encouragements qu’ils m’ont prodigués tout au long de ce travail.

Tables des matières

CHAPITRE 1. INTRODUCTION ............................................................................................ 1

1.1 DEFINITION .................................................................................................................. 1

1.2 LES INFORMATIONS SPATIO-TEMPORELLES .......................................................................... 1

1.3 LA GESTION DE DONNEES SPATIO-TEMPORELLES .................................................................. 2

1.3.1 Visualisation de données spatio-temporelles ...................................................... 3

1.3.2 Les bases de données spatio-temporelles ............................................................ 4

1.4 UN MODELE CONCEPTUEL ............................................................................................... 5

1.5 GML .......................................................................................................................... 6

1.6 OBJECTIFS ET MOTIVATIONS ............................................................................................ 6

1.7 STRUCTURE DU MEMOIRE ............................................................................................... 7

CHAPITRE 2. LE MODELE CONCEPTUEL MADS ................................................................... 8

2.1 CONTEXTE ................................................................................................................... 8

2.2 LE MODELE CONCEPTUEL................................................................................................. 9

2.3 VERS LA MULTI-REPRESENTATION ................................................................................... 10

2.4 ORTHOGONALITE DES DIMENSIONS ................................................................................. 12

2.5 LA DIMENSION THEMATIQUE ......................................................................................... 12

2.5.1 Le type d’objet .................................................................................................... 12

2.5.2 Les attributs ....................................................................................................... 13

2.5.3 Les méthodes ..................................................................................................... 14

2.5.4 La généralisation ................................................................................................ 14

2.5.5 Les types de relation .......................................................................................... 15

2.6 LA DIMENSION SPATIALE ............................................................................................... 19

2.6.1 Vue discrète ........................................................................................................ 21

2.6.2 Variation dans l’espace ...................................................................................... 23

2.7 LA DIMENSION TEMPORELLE .......................................................................................... 24

2.7.1 Variation dans le temps ..................................................................................... 26

2.8 LA DIMENSION MULTI-REPRESENTATION .......................................................................... 26

2.9 EXEMPLE DE SCHEMA MADS ........................................................................................ 29

CHAPITRE 3. LA SUITE D’OUTILS MADS ........................................................................... 30

3.1 LA MODELISATION ....................................................................................................... 31

3.2 L’INTERROGATION ....................................................................................................... 34

3.3 LA VISUALISATION ....................................................................................................... 36

3.4 REMARQUES .............................................................................................................. 36

CHAPITRE 4. XML ........................................................................................................... 38

4.1 INTRODUCTION ........................................................................................................... 38

4.2 EXEMPLE DE DOCUMENT XML ....................................................................................... 38

4.3 AVANTAGES DU XML ................................................................................................... 39

4.4 DTD ET XML SCHEMA ................................................................................................. 40

4.5 VALIDITE D’UN DOCUMENT XML ................................................................................... 42

4.6 DECODAGE D’UN DOCUMENT XML ................................................................................ 43

4.7 TECHNOLOGIES ASSOCIEES ............................................................................................ 44

CHAPITRE 5. GML ........................................................................................................... 45

5.1 CONTEXTE ................................................................................................................. 45

5.2 MOTIVATIONS ............................................................................................................ 45

5.3 DEFINITION DE L’INFORMATION GEOGRAPHIQUE................................................................ 47

5.4 LE MODELE GML ........................................................................................................ 47

5.5 LES MODULES DE GML ................................................................................................ 50

5.5.1 Le cœur GML ...................................................................................................... 50

5.5.2 La géométrie ...................................................................................................... 50

5.5.3 La topologie........................................................................................................ 53

5.5.4 Le temps ............................................................................................................. 53

5.5.5 La couverture ..................................................................................................... 54

5.5.6 La projection ...................................................................................................... 55

5.5.7 Normes ISO ......................................................................................................... 55

5.6 EXEMPLE ................................................................................................................... 55

5.7 LES OUTILS POUR LA CREATION DE SCHEMA APPLICATIF GML ............................................... 57

5.8 LES OUTILS DE MANIPULATION ....................................................................................... 57

5.9 LES SERVICES WEB ....................................................................................................... 57

5.9.1 Web Map Service (WMS) ................................................................................... 57

5.9.2 Web Feature Service (WFS) ................................................................................ 58

CHAPITRE 6. CORRESPONDANCE ENTRE LES CONCEPTS MADS ET LES CONCEPTS GML ..... 59

6.1 CONTEXTE ................................................................................................................. 59

6.2 ETUDE DE L’ART .......................................................................................................... 59

6.3 MADS AU LIEU DE L’UML ............................................................................................ 61

6.4 TRADUCTION .............................................................................................................. 62

6.5 REGLE DE TRANSFORMATION ......................................................................................... 62

6.6 ARCHITECTURE DU TRADUCTEUR DE SCHEMA MADS.......................................................... 63

6.7 CONVERSION D’UN SCHEMA MADS VERS UN SCHEMA GML ............................................... 65

6.8 REPRESENTATION DE LA DIMENSION THEMATIQUE ............................................................. 65

6.8.1 Type d’objet........................................................................................................ 65

6.8.2 Attributs ............................................................................................................. 66

6.8.3 Généralisation .................................................................................................... 67

6.9 TYPES DE RELATION ...................................................................................................... 68

6.9.1 Associations non porteuse d’informations......................................................... 69

6.9.1 Associations porteuse d’informations ................................................................ 70

6.10 REPRESENTATION DE LA DIMENSION TEMPORELLE .............................................................. 70

6.11 REPRESENTATION DE LA DIMENSION SPATIALE ................................................................... 71

6.12 REPRESENTATION DE LA DIMENSION MULTI-REPRESENTATION .............................................. 74

CHAPITRE 7. CONCLUSION .............................................................................................. 76

7.1 CONCLUSIONS ....................................................................... ERREUR ! SIGNET NON DEFINI.

7.2 TRAVAUX FUTURS ........................................................................................................ 77

7.2.1 GML et la création et visualisation de données ................................................ 77

7.2.2 GML et le stockage de donnée .......................................................................... 77

7.2.3 Fédération WFS au travers de MADS ................................................................. 78

BIBLIOGRAPHIQUE ........................................................................................................... 79

LISTE DES FIGURES ............................................................................................................ 82

1

Chapitre 1. Introduction

Initialement, les systèmes permettant la manipulation d'informations géographiques nécessitaient de gros ordinateurs pour fonctionner et étaient complexes et très couteux. De fait, les Systèmes d'Information Géographique (SIG) étaient strictement réservés à des spécialistes, en général des organisations militaires, gouvernementales ou scientifiques.

Depuis peu, grâce aux progrès technologiques de ces dernières années, à la généralisation d’Internet et à la puissance croissante des machines de bureau, les SIG sont désormais facilement accessibles, consultables et manipulables par le grand public.

Les sites de recherche d'adresses, les sites d'itinéraires routiers ou de transport sont des SIG. L'un des plus connus par le grand public est le SIG élaboré par Google Earth, qui permet de voir les photos satellites de l'ensemble de la planète.

1.1 Définition

Bien qu’il n’existe pas de définition précise d’un SIG, la définition la plus largement acceptée émane du comité fédéral de coordination inter-agences pour la cartographie numérique [FICCDC 1988] :

"Un système d'information géographique est un système informatique de matériels,

de logiciels, et de processus conçus pour permettre la collecte, la gestion, la

manipulation, l'analyse, la modélisation et l'affichage de données à référence

spatiale afin de résoudre des problèmes complexes d'aménagement et de gestion."

1.2 Les informations spatio-temporelles

Les SIG travaillent sur de l’information géographique. Bien souvent, cette information évolue. L’information va différer au cours du temps et/ou dans l’espace. Une information spatio-temporelle est une donnée dont on a associé une propriété géographique (spatiale) et une propriété temporelle. Comme le montre la Figure 1.1, les concepts spatio-temporels combinent les concepts spatiaux et les concepts temporels.

2

Par exemple un cours d’eau est représenté par une donnée spatio-temporelle car son lit va changer au cours du temps. La composante temporelle du cours d’eau permet de garder un historique de l’évolution au cours des années pour une analyse d’incidence future. Voilà le principal intérêt d’une base de données spatio-temporelle.

Figure 1.1 Les concepts spatio-temporels

1.3 La gestion de données spatio-temporelles

Un SIG se concentre sur la gestion des données. La gestion comprend plusieurs phases : le processus de réflexion sur les besoins auxquels il faut répondre (la modélisation), la capture des informations (la création), le stockage et l’analyse de celles-ci. La modélisation permet de définir les entités géographiques dans le langage de la plateforme SIG cible. Une fois réalisée, l’utilisateur rentre les informations géographiques suivant le modèle défini. Celles-ci peuvent être stockées dans une base de données. L’analyse est faite avec le module d’interrogation de cette base. La Figure 1.2 reprend la relation des différentes opérations avec une base de données.

3

GESTION

Définition

Acquisition

Maintenance

Intégrité

VISUALISATION

Représentation

Consultation

Acquisition / Edition

Selection

ANALYSE

Opérateur d’interrogations

Logique

Base de données

Interrogation

Visualisation

Acquisition et mise à jour

Interrogation

Prédiction

Figure 1.2. Les fonctionnalités d’un SIG

1.3.1 Visualisation de données spatio-temporelles

Le Web Mapping [Berron07] permet de diffuser des cartes en format image via un réseau. C’est un domaine en pleine expansion grâce au développement des solutions libres. Les informations cartographiques brutes ou les données spatiales sont ainsi consultables à partir de postes clients. Elles sont en général stockées dans un système de gestion de base de données (SGBD) sur un ou plusieurs serveurs et administrables de façon centralisée. Le Web Mapping est donc important pour l'avenir des SIG. Grace à lui l’utilisation des SIG sera de plus en plus démocratisée. L’utilisateur accède au service par son navigateur internet. Un moteur cartographique tournant sur un serveur lui permet d’effectuer un ensemble de manipulations sur les cartes (navigation, requêtes, mais aussi mise à jour à distance). MapServer est le moteur cartographique le plus répandu.

4

Figure 1.3. Principe de l’architecture client-serveur

L’utilisation de standards et de protocoles est indispensable afin que chaque utilisateur puisse utiliser le système.

1.3.2 Les bases de données spatio-temporelles

Une base de données permet le stockage de grandes quantités d'informations et en facilite l'exploitation par des opérations d’ajout, de suppression, de mise à jour et de recherche. Dans une base de données spatiale, les informations géographiques sont représentées de deux façons :

• La première est la représentation discrète. Dans celle-ci, un objet spatial est une

donnée vectorielle de type Point, Ligne ou Région par exemple.

• L’autre est la représentation continue (raster) de notre monde. On représente tout

l’espace par une grille (type Grille) où chaque cellule possède une valeur sur

l’information à représenter.

En plus de définir les types cités précédemment, les bases de données spatiales permettent l’utilisation de prédicats spatiaux pour leur interrogation. Des exemples d’interrogation possibles sont:

• Est-ce que 2 routes se croisent ?

• Y a-t-il une intersection entre deux régions ?

• Y-a-t-il une pompe à essence a moins de 5 km de tel endroit ?

5

Les bases de données relationnelles comme Oracle, IBM DB2, PostGIS et MySQL possèdent maintenant toutes une extension pour les informations géographiques. Malheureusement ces bases de données ne permettent pas de prendre en compte l’évolution des données. Bien qu’elles permettent de stocker des données avec des attributs de type « Date » ou de type « Timestamp », elles ne supportent pas les prédicats temporels permettant des opérations sur les intervalles de temps (intersection, union,…). Cependant il est tout à fait possible d’introduire une notion de temps dans les bases de données spatiales, elles sont alors qualifiés de spatio-temporelles. Le temps peut intervenir à deux niveaux :

• Au niveau de la base de données. En stockant le moment ou les données sont ajoutées, modifiées ou supprimées. Cet intervalle de temps permet de retrouver l’état de la base de données à un instant donné.

• Au niveau des données elles-mêmes On peut représenter l'intervalle de temps pendant lequel l'information est valide.

Exemple : l’évolution du tracé d'un cours d'eau

• La durée de la transaction : Elle commence à l’instant où l’information est rajoutée, lorsque le tracé a été mis à jour, et se termine lorsqu’on supprime cette information.

• Durée de validité : C’est la durée pendant laquelle l’information pour le tracé du cours d'eau est valide.

1.4 Un modèle conceptuel

Un des avantages de la modélisation conceptuelle est que son approche permet à l’utilisateur final de s’abstraire de tout détail technique lors de la modélisation. La compréhension intuitive du schéma permet de faire participer au processus de développement les utilisateurs du futur système et donc la communication entre les différents acteurs est améliorée.

Un modèle conceptuel est dès lors indépendant du niveau logique que représente une base de données par exemple. Le niveau logique pourra être automatiquement pris en charge par un module de traduction du modèle conceptuel. On peut définir des opérations comme la manipulation de données sur ce modèle conceptuel. Ces opérations de haut niveau seront aussi traduites vers le modèle logique sur lequel se trouvent les données.

6

1.5 GML

Le Geography Markup Language (GML) est un langage de balisage pour la géographie défini par l’Open Geospatial Consortium (OGC). Basé sur XML, GML est utilisé pour structurer l’information géographique de manière à faciliter son partage sur Internet. La spécification GML comprend plus de 600 pages et des milliers de balises de noms d’objet. GML a été conçu pour couvrir de nombreux besoins. Mais de par la taille de sa spécification, il est complexe à utiliser. Il existe donc une forte barrière à son adoption. Pour accélérer celle-ci, l’OGC a créé des sous-ensembles simplifiés de GML dont l’un des plus connus est le profil GML « Simple Feature ». Des outils visuels existent pour la création du code XML et des schémas XML. Une personne devra dès lors travailler au niveau des éléments et des balises pour modéliser les concepts thématiques tels que les objets, les attributs et les relations comme vu dans l’exemple cité au chapitre GML.

1.6 Objectifs et motivations

L’objectif de ce mémoire de fin d ‘étude est de compléter la chaîne d’outils pour le modèle conceptuel MADS destiné au domaine des bases de données spatio-temporelles. Le département « Computer & Decision Engineering » (CoDE) de l’ULB en partenariat avec d’autres universités ainsi que des entreprises publiques et privées ont créé, dans le cadre du projet MurMur [Mur 02], ce modèle conceptuel MADS ainsi qu’une suite d’outils associés. Ces outils permettent de modéliser des concepts spatio-temporels, questionner les informations représentées par le schéma en utilisant le modèle conceptuel comme un outil visuel d’interrogation, ainsi qu’un outil permettant d’afficher les réponses à ces interrogations. GML est devenu le standard pour l’échange d’information géographique. Pour cette raison il a été choisi comme nouvelle cible logique pour le modèle conceptuel MADS. Le but de ce mémoire est de :

• Introduire GML.

• Expliquer la correspondance entre MADS et GML.

• Compléter la chaîne d'outils MADS en créant une extension au traducteur de schéma.

• Augmenter le nombre d'utilisateur de MADS. Le but est d'amener plus de

personnes à l'utiliser et supporter sa suite d'outils.

7

1.7 Structure du mémoire

Voici le découpage du mémoire ainsi qu'un bref aperçu : Chapitre 2. J’y présenterai le modèle conceptuel de données spatio-temporelles MADS et ses concepts clés dont le principe d'orthogonalité qui allie la simplicité et le pouvoir d'expression pour modéliser les quatre dimensions proposés par MADS : thématique, temporelle, spatiale et multi-représentation. Ces quatre dimensions seront expliquées dans ce chapitre. Chapitre 3. Dans ce chapitre je présenterai la suite d’outils MADS. Chapitre 4. Le chapitre 4 est consacré à XML, qui est incontournable pour l’échange d’informations de par sa simplicité, son expressivité et sa facilité de mise en œuvre pour la modélisation et le stockage de données. Je présenterai les éléments de base d'un document XML. Chapitre 5. Je parlerai de GML, qui est le standard pour la modélisation, l'échange et le stockage de l'information géographique. Dans ce chapitre, j’expliquerai les éléments et concepts de base. Ensuite nous verrons un exemple des différents outils pour la création de schéma applicatif GML. Chapitre 6. Une des possibilités pour la création de schéma applicatif GML est d'utiliser l'éditeur de schéma de la suite d'outils MADS. Dès lors nous étudierons la correspondance entre les concepts MADS et GML dans ce chapitre.

8

Chapitre 2. Le modèle conceptuel MADS

Dans ce chapitre, je vais parler du modèle conceptuel MADS. Nous verrons le but de ce modèle ainsi que le contexte dans lequel il s’inscrit. Je vais ensuite parler de la philosophie du modèle et de tous les concepts sous-jacents. Ce chapitre suit la structure du livre plus complet traitant du modèle MADS [ParSpaZim2006].

2.1 Contexte

Les SIG actuels ne proposent pas d’outils pour la modélisation des données avancée alors que les applications spatio-temporelles en ont besoin pour plusieurs raisons :

• Les données spatio-temporelles sont plus compliquées à gérer que les données

traditionnelles

• La technologie évolue très vite et les applications doivent souvent être repensées

pour de nouveaux systèmes.

• Le coût important de l’acquisition de nouvelles données pousse à réutiliser des

sources externes d’informations.

De plus, les modèles de données supportés par certains SIG sont des modèles logiques pauvres basés sur le modèle relationnel. Ces modèles ne supportent pas la temporalité. Le but du projet MADS est de résoudre ces problèmes en offrant un modèle de donnée conceptuel avec le support de la spatialité et la temporalité ainsi qu’un ensemble d’outils associés. MADS est l’abréviation de « Modélisation d’Applications à Données Spatio-temporelles ». C’est un projet commencé en 1995 par l’EPFL en partenariat avec des sociétés et des universités. Il était supporté par la CTI (Commission pour la Technologie et l¹Innovation). Le projet s’est terminé en 1997. Les premières spécifications du modèle conceptuel MADS était alors établies. L’implémentation des outils MADS a ensuite été achevée en tant que partie du projet MurMur (Multi-Representations and Multiple Resolutions in Geographic Databases).

2.2 Le modèle conceptuel

Un modèle est dit conceptuel s’ilperçu et sa représentation. Un des avantages de la modélisation conceptuelle est que à l’utilisateur final de s’abstraire de tout détail technique lors de la modélisaticompréhension intuitive du schéma permet de faire participer développement les utilisateurs du futur système et donc la commudifférents acteurs est améliorée

Un modèle conceptuel est dès lors indépendant du nivebase de données par exemple. Le niveau logique pourra être automatiquement pris en charge par un module de traduction du modèle conceptuel vers diffélogiques. On peut définir des opérations comme la manipulation conceptuel. Ces opérations de haut niveau seront aussi traduites vers le modèle logique sur lequel se trouvent les données.

Figure

Des modules de traductions doiventpouvoir utiliser le modèle conceptuel. Un travail de correspondance entre les concepts de MADS et les concepts proposés par le système cible doit être effectué

�

Niveau conceptuel

Niveau logique

Niveau physique

9

Le modèle conceptuel

Un modèle est dit conceptuel s’il permet une correspondance directe entre le monde

e la modélisation conceptuelle est que l’approche conceptuelle permet à l’utilisateur final de s’abstraire de tout détail technique lors de la modélisaticompréhension intuitive du schéma permet de faire participer

les utilisateurs du futur système et donc la commuaméliorée.

Un modèle conceptuel est dès lors indépendant du niveau logique que représente une base de données par exemple. Le niveau logique pourra être automatiquement pris en charge par un module de traduction du modèle conceptuel vers diffé

définir des opérations comme la manipulation de données sur ce modèle conceptuel. Ces opérations de haut niveau seront aussi traduites vers le modèle logique sur lequel se trouvent les données.

Figure 2.1 Les différentes couches de modélisation

modules de traductions doivent être conçus pour chaque système avec lequel on veut

conceptuel. Un travail de correspondance entre les concepts de s proposés par le système cible doit être effectué.

• Description des concepts (idées ou entités à représenter) et leurs relations sous forme de schéma graphique : MADS, UML, E-R , Enhanced E-R, ...

Niveau conceptuel

• Description dans le langage de définition de données d'une BD cible: table et colonnes, classes OO, tags XML, format propiétaires,...

Niveau logique

• Description du point du vue du système de fichiers (structure interne du fichier, répertoire, partition, ....) Niveau physique

permet une correspondance directe entre le monde réel

approche conceptuelle permet à l’utilisateur final de s’abstraire de tout détail technique lors de la modélisation. La compréhension intuitive du schéma permet de faire participer au processus de

les utilisateurs du futur système et donc la communication entre les

au logique que représente une base de données par exemple. Le niveau logique pourra être automatiquement pris en charge par un module de traduction du modèle conceptuel vers différents modèles

de données sur ce modèle conceptuel. Ces opérations de haut niveau seront aussi traduites vers le modèle logique sur

avec lequel on veut conceptuel. Un travail de correspondance entre les concepts de

Description des concepts (idées ou entités à représenter) et leurs relations sous forme de schéma graphique : MADS,

Description dans le langage de définition de données d'une BD cible: table et colonnes, classes OO, tags XML,

Description du point du vue du système de fichiers (structure interne du fichier, répertoire, partition, ....)

10

�

Figure 2.2 Module de traduction d’un schéma conceptuel vers un schéma logique

2.3 Vers la multi-représentation

Les bases de données permettent le stockage de données décrivant des phénomènes réels. Dans notre cas nous allons nous intéresser particulièrement au stockage de données spatio-temporelles. La particularité des bases de données spatio-temporelles est leur communauté d’utilisateurs potentiels large et variée, en attente d’outils de modélisation propres à leur environnement de travail. En effet des applications aussi diverses que la gestion des risques industriels (pollution, explosion, …) ou naturels (avalanche, séisme, inondation, …), la gestion de flottes de véhicules en temps réel, la gestion cadastrale, la réalisation de relevé géographique ou encore la gestion d’études géo-sociologique, demandent des représentations multiples afin de modéliser des phénomènes réels pour un environnement de travail spécifique. Ces représentations multiples peuvent entre autre se différencier par : l’information qui est stockée, le degré de précision des données, la forme des données, leur structure, les contraintes sur la structure ou/et les données ou encore la forme sous laquelle les données sont affichées. Outre les différences sémantiques entre les représentations, celles-ci peuvent également se distinguer par la résolution spatiale des données de la base de données et par l’échelle utilisée pour générer la carte géo-temporelle. C’est afin de permettre la coexistence de ces différentes représentations simultanément sur une même base de données, tout en préservant la cohérence des différents modèles, que le projet MurMur a vu le jour. Le but du projet MurMur est d’étendre les fonctionnalités courantes fournies par les logiciels commerciaux de gestion de données, pour supporter des schémas de

11

représentation plus flexibles, comme la coexistence de représentations multiples d’un même phénomène réel. En plus de fournir une plateforme commune de travail à différentes communautés d’utilisateurs, la représentation multiple peut offrir d’autres avantages. Considérons par exemple la possibilité d’améliorer la gestion des données lors des mises à jour par une propagation automatique des modifications d’attributs communs au travers de chaque représentation du modèle ou encore des possibilités d’amélioration des processus de vérification d’intégrité des données en vérifiant les corrélations entre les différentes représentations. L’institut géographique national français (IGN), partenaire du projet MurMur, gère plusieurs bases de données géographiques [Balley 02]. Chacune d’elle étant destinée à un usage différent, elles sont conservées de façon disjointe. Cela rend difficile leur gestion et leur mise à jour. L’IGN voudrait donc combiner ces bases de données en une seule.

Figure 2.3 Différentes représentations du même rond-point dans des bases de données [Balley 02]

En guise de solution, MurMur propose l’extension d’un modèle conceptuel existant, développé par les partenaires du projet : MADS. Ce modèle de données permet de décrire au niveau conceptuel des données spatio-temporelles sous trois dimensions.

Le projet MurMur a été financé par la commission européenne dans le cadre du 5e « Framework Programme » qui a duré de janvier 2000 à décembre 2002. Suite à cela, le projet a continué au fil des années grâce aux travaux de fin d’étude du département « CoDe » de l’Université Libre de Bruxelles. Il a rassemblé des partenaires industriels, académiques et publiques. Cette collaboration a permis de valider les idées et les outils ainsi créés. Voici les partenaires du projet :

• Star Informatics, fournisseur de système d’information géographique

12

• L’institut géographique national français (IGNF), fournisseur de données

géographiques

• L’Institut de recherche pour l'ingénierie de l'agriculture et de l'environnement

CEMAGREF, des utilisateurs de données géographiques

• L’Ecole Polytechnique Fédérale de Lausanne (EPFL)

• L’Université de Lausanne (UNIL)

• L’Université Libre de Bruxelles (ULB)

2.4 Orthogonalité des dimensions

Pour faciliter la tâche des utilisateurs, les concepteurs de MADS et de MurMur ont adopté une perspective orthogonale entre les quatre dimensions suivantes : thématique, spatiale, temporelle et multi représentation. Ceci permet de donner un pouvoir d’expression maximal à l’utilisateur. L’orthogonalité permet de décomposer les problèmes, et ainsi de gérer chaque dimension une à une, indépendamment des autres. Chacune des dimensions peut être appliquée aussi bien sur un objet, son attribut ou sa relation avec un autre objet. Dans la Figure 2.4, une Rue peut être un type d’objet spatial ou un attribut spatial.

Figure 2.4 Exemple d’orthogonalité

Voici les quatre dimensions du modèle MADS :

2.5 La Dimension thématique

La dimension thématique de MADS reprend les concepts des bases de données orienté-objet.

2.5.1 Le type d’objet

Un type d’objet a pour but de modéliser la représentation d’une entité du monde réel. Il définit un ensemble d’entités ayant un comportement et une structure similaires. La structure est définie par les attributs et le comportement par les méthodes. Un type d’objet est proche du concept de classe. Les attributs sont les propriétés d’une classe et les méthodes sont les opérations pouvant être effectuées sur cette classe. Les objets ou

13

instances du type d’objet sont uniques et identifiables par leur « Object Identifier » (oid). Un type d’objet peut être relié à un autre type d’objet (généralisation) ou à une relation. Il peut être spatial ou temporel. Par exemple, la Figure 2.5 a) montre une Rue définie comme un type d’objet et la figure b) montre Rue comme un type spatial défini par une ligne.

a) Type d’objet

Rue

b) Rue est une

ligne

c) Nom est un attribut

simple monovalué

d) Une rue possède des

pompes à essence

Figure 2.5 Exemple de type d’objet et d’attributs

2.5.2 Les attributs

Un attribut peut être de deux types :

• simple : s’il contient une valeur d’un type de base fourni par le modèle

• complexe : s’il est composé d’un ensemble d’attributs simples ou complexes

Chaque attribut doit avoir un nom, un type et une cardinalité. La cardinalité d’un attribut donne le nombre de valeurs que peut comporter l’attribut. Un attribut est dit :

• monovalué : si l’attribut ne peut comporter qu’une seule valeur.

• multivalué : si l’attribut possède plusieurs valeurs. Ces valeurs doivent être

groupées soit dans un ensemble non ordonné dans lequel les valeurs ne peuvent

apparaître deux fois (set), soit dans un groupe non ordonné dans lequel une même

valeur peut apparaitre plusieurs fois (bag), soit dans une liste si les valeurs doivent

rester ordonnées suivant un critère (list).

Exemple : À la Figure 2.5 c), une Rue possède un nom et optionnellement un code. À la Figure 2.5 d), une Rue possède un nom (ex : chaussée de Waterloo) et une liste de pompes à essences situé sur son tracé (représenté par une ligne). Une pompe à essence possède un numéro de rue et le nom de la société qui la gère. Cette liste sera ordonnée par ordre de numéro de rue croissant.

14

La valeur de l’attribut appartient au domaine du type de donnée avec lequel il est associé. MADS reprend les types les plus répandus comme: entier, nombre réel, nombre flottant, caractère, chaîne de caractère, booléen et date. MADS permet de restreindre le domaine de ces types basiques. De nouveaux types sont définissables avec comme domaine, un intervalle sur un des types basiques. MADS supporte aussi la définition d’énumérations et de types personnalisés (user-defined). Un attribut possède une valeur qui est calculée par le système suivant la formule de dérivation fournie lors de sa description.

2.5.3 Les méthodes

Comme pour les classes en orienté-objet, les méthodes ajoutent des opérations au type d’objet. Une méthode est définie par sa signature (son nom, la liste de ses arguments et la liste de ses valeurs de retour) ainsi que par son corps. Actuellement, MADS permet de définir la signature d’une méthode mais ne permet pas de définir son corps. Une description textuelle suivra donc la signature pour expliquer la nature de l’opération.

2.5.4 La généralisation

Un lien de généralisation (Is-A link) lie un type d’objet à un autre type d’objet. Il spécifique que l’objet fils (sous-type) hérite des caractéristiques (les attributs, les méthodes et les rôles) de l’objet père (super-type). Il hérite aussi des propriétés spatiales, temporelles et de multi-représentation du père.

Figure 2.6 Personne (super-type) et ses sous-types

Exemple : À la Figure 2.6, le type d’objet Personne a 2 catégories (cluster) de sous-types. La première catégorie regroupe Etudiant, Employé et retraité. Le type d’objet Malade

15

forme un cluster à lui tout seul. Une personne peut être malade et être soit un étudiant, soit un employé, soit un retraité. Ainsi il y a de multiples instances d’un même objet dans les sous-types. C’est exprimé par le lien de chevauchement (overlapping link). Une contrainte d’inclusion de population existe sur un lien de généralisation. Cette contrainte assure que chaque objet appartenant à un sous-type est aussi instancié dans le super-type. L’héritage permet donc de substituer le père par le fils étant donné que le fils possède les informations du père. Tout comme dans la programmation orientée objet, l’héritage permet aussi de raffiner ou de redéfinir les caractéristiques du père. Le raffinement permet de restreindre le domaine des définitions héritées. La redéfinition (la surcharge) a pour principe de garder la définition du père (pour pouvoir garder le principe de substitution) et de créer une définition propre au fils. Le choix de la bonne définition sera fait dynamiquement suivant le type. Le multi-héritage est aussi supporté. Les conflits (deux mêmes propriétés dans chacun des pères) sont résolus en préfixant les propriétés hérités par le nom du père (super-type). Par le principe d’orthogonalité, un lien de généralisation s’applique aussi sur les types d’associations (relations). La généralisation contribue ainsi à créer plusieurs représentations d’une même entité.

2.5.5 Les types de relation

Une relation relie plusieurs objets entre eux. Le lien qui lie un objet à une relation est appelé rôle de la relation. Il doit contenir une cardinalité et peut être nommé. Une relation est dite de type n-aire si le nombre de rôles est plus grand que un. Chaque rôle a une paire de nombres donnant le nombre minimum et maximum de liens entre l’objet et la relation. Un rôle multivalué ne peut être que de type « set » ou de type « list». La Figure 2.7 donne la notation des différents rôles possibles.

Figure 2.7 Rôles possibles

16

Figure 2.8 Exemple d’association avec attribut

Une relation peut comporter des caractéristiques comme des attributs, des méthodes, et des informations sur la spatialité et la temporalité. Exemple : À La Figure 2.8, la relation « se situe dans » porte un attribut « numéro ». Une rue peut contenir zéro ou plusieurs maisons. Une maison par contre, doit nécessairement se situer dans une rue. Si la relation porte sur un seul et même type d’objet, elle est dite cyclique. Dans ce cas, les rôles doivent être nommés afin de pouvoir les différencier. En dehors de ce cas particulier, il est optionnel de nommer les rôles.

Figure 2.9 Une relation cyclique

Afin de pouvoir distinguer deux instances de la relation liant deux fois les mêmes objets, un RID (relationship identifier) est associé à chaque instance. Exemple : À la Figure 2.9, deux remplacements peuvent avoir lieu. Il y aura deux instances de « remplace ». Une manière de les identifier univoquement est de rajouter à chaque instance, un identifiant. Le type de relation le plus fréquent est l’association. Elle lie un objet à un autre. Un autre type de relation est la multi-association. Cette relation lie un ensemble d’objets à un autre ensemble d’objets. Chaque rôle possède deux paires de cardinalités. La première (proche de l’objet) définit le nombre de fois auquel l’objet participe à une association. La deuxième définit pour chaque instance de la relation, le nombre d’objet qu’elle peut lier.

17

Figure 2.10 Exemple de multi-association

Exemple : À la Figure 2.10, certains objets ne sont jamais échangés contre des services, et certains services ne sont pas rendus contre des objets. S’il y a un échange, il y aura au moins un objet échangé contre un service. Il est tout à fait possible d’avoir un échange où trois objets sont échangés contre deux services. L’agrégation permet d’organiser les objets en hiérarchies. Un objet A est composé de plusieurs objets B, et un objet B est un composant de plusieurs objets A. La relation est représentée par un losange et ses rôles sont nommés isComposedOf et isComponentOf. L’agrégation ne peut s’appliquer qu’à une relation binaire.

Figure 2.11 Exemple d’agrégation

La transition permet de garder une trace de l’évolution des objets dans la base de données. Elle permet de savoir comment ils naissent et disparaissent. Ses rôles sont nommés isSource et isTarget. Ils indiquent la direction de l’évolution. Une transition traque l’évolution d’un objet grâce à son id.

18

Figure 2.12 Exemple de transition

Dans la Figure 2.12, un étudiant peut devenir un employé. Un employé peut être devenu un employé sans passé par le statut d’étudiant. Si un employé doit obligatoirement avoir été un étudiant, le lien isTarget ne sera plus (0 ,1) mais (1,1). La génération garde l’information sur la création d’entités d’un type de données depuis d’autres entités de types identiques ou différents. La génération est applicable sur une relation n-aire. Plusieurs objets peuvent être la source d’un autre objet, et plusieurs objets peuvent être générés par une seule source.

Figure 2.13 Exemple de génération

La génération est utilisable avec une multi-association. Cela signifie qu’un ensemble donné d’objets génère un autre ensemble d’objets.

19

Figure 2.14 Plusieurs terrains peuvent devenir plusieurs autres terrains

2.6 La dimension spatiale

Dans MADS, la spatialité s’applique de manière orthogonale aux structures de données thématiques. Elle peut s’appliquer aux types d’objets, aux relations et aux attributs. La spatialité coexiste avec la temporalité au niveau de l’objet et un objet peut être spatial et/ou temporel. Comme vu à la Section Erreur ! Source du renvoi introuvable., il y a deux manières de eprésenter l’information géographique (voir Figure 2.15 ) : la représentation « vectorielle » et la représentation « raster ». La représentation vectorielle consiste à modéliser l’espace au travers d’objets (route, rivière, maison,…). On dit que c’est une représentation discrète de notre monde car l’espace vide n’est pas modélisé. La représentation « raster » considère l’espace comme un champ continu. L’espace est subdivisé par une grille où chaque cellule contient une valeur. Une application SIG peut combiner à la fois des informations en vue discrète et des informations en vue continue. Exemple : Une application va modéliser les maisons et les routes en vue discrète, leur donnant une forme géographique précise et modéliser la température et l’altitude avec vue continue. Une question à laquelle l’application pourrait répondre est : Quelles sont les maisons situées sur une pente de plus de 10% ?

20

Vue continue

Vue discrète

Monde réel

Figure 2.15 Vue continue et vue discrète du monde réel [REPRESENTATION]

21

2.6.1 Vue discrète

Dans la vue discrète, différents types de données représentent la spatialité. Ils sont organisés sous forme hiérarchique. Il y a d’un côté les types de données simples et de l’autre les types de données complexes. Ces 2 groupes sont issus du type abstrait générique « Geo ». Les types « Simple Geo » et « Complex Geo » sont eux aussi des types abstraits génériques. Dans les types simples, on trouve les points, les lignes (orientées ou non) et les surfaces. Une surface est une région qui peut éventuellement posséder un trou à son intérieur. Ces types donnent une représentation de l’emprise (la forme associée à l’élément défini comme spatial) et de la localisation à l’aide de coordonnées dans l’espace.

Figure 2.16. Type de donnée spatiale de MADS

Chaque type de donnée spatial possède des attributs (métadonnées) tel que le système de projection utilisé, la précision numérique des coordonnées, la précision de la mesure, la date de la mesure et la qualité. Chaque type de données spatiales possède aussi des méthodes pour le manipuler. Lorsque la spatialité est appliquée sur un type d’objet ou un type de relation, un attribut système « geometry » lui est ajouté. Cet attribut de type spatial prendra la valeur du type défini pour l’objet. Les types de relation peuvent aussi posséder une dimension spatiale. Elles peuvent être soit des relations d’agrégation spatiale, soit des relations topologiques. Ces relations d’agrégations fonctionnent comme vu à la section 2.5.5. Une relation qui lie deux objets

22

spatiaux de façon hiérarchique (par ex. un pays contient des régions) permet de dériver les attributs du pays à partir des informations des régions :

pays.surface = union(régions.surface) pays.superficie = somme(régions.surperficie)

Les relations topologiques quand à elles, définissent des relations sur deux types d’objets spatiaux et spécifient des contraintes topologiques sur les objets liés. Les relations topologiques fonctionnent de deux manières :

• Manuelle : les instances de la relation doivent être insérées par l’utilisateur et le

système vérifie la contrainte spatiale entre les deux objets. Si elle est vérifiée, la

relation sera gardée. Sinon elle sera rejetée.

• Automatique : les instances de la relation seront automatiquement ajoutées par le

système pour chaque couple d’objets O1 et O2 étant en relation. On dira alors qu’elle

est dérivée.

Type d’opérateur Icone Définition

TopoDisjoint 2 géométries satisfont cette contrainte si elles n’ont aucuns points en commun.

TopoEqual 2 géométries satisfont cette contrainte si tous les points d’une géométrie se trouvent dans l’autre.

TopoWithin 1 géométrie satisfait cette contrainte si tous ses points sont contenus dans une autre et que ces géométries ne sont pas TopoEqual.

TopoTouch 2 géométries satisfont cette contrainte si leurs bords ont des points en communs.

TopoCross 2 géométries satisfont cette contrainte si leur intérieur partage certains points communs et si la dimension de l’intersection est inférieure à celle de l’une des géométries.

TopoOverlap 2 géométries satisfont cette contrainte si elles ont la même dimension, que leur intersection est de même dimension que la leur et que les contraintes TopoEqual ou TopoWithin sont fausse.

TopoGeneric

Cette icône permet de définir une contrainte personnalisée ou une contrainte générique entre 2 géométries.

Figure 2.17. Types de relation topologique dans MADS

23

La spatialité fournit une relation spécifiant une contrainte topologique entre les 2 entités spatiales qu’elle relie. Ces contraintes sont données dans la Figure 2.17. domaines

opérateurs

Surface

x

Surface

Ligne

x

Ligne

Point

x

Point

Surface

x

Ligne

TopoDisjoint

TopoTouch

TopoCross

TopoOverlap

TopoWithin

TopoEqual

Figure 2.18. Domaines pour lesquels les opérateurs sont définis

2.6.2 Variation dans l’espace

Un objet, un attribut ou une relation peuvent varier dans l’espace. Ils sont alors dénotés par f(�) s’ils sont de type générique géo. Pour les autres types, géo sera remplacé par l’icône du type spatial voulu. La fonction associe au domaine source qui est une zone de l'espace (une surface ou une ligne) un domaine de valeurs. Il y a deux types de variations définissables :

• par étape : la variation intervient par étape abruptement.

• continue : la variation évolue sur toute la surface continue. MADS utilise une grille

pour stocker toutes les informations.

24

2.7 La dimension temporelle

Différents types représentent la temporalité. Ils sont eux aussi organisés sous forme hiérarchique avec d’un côté les types simples et de l’autre les types complexes de type ensembliste basé sur des types simples. Le type Time est un type générique abstrait pour la temporalité. Il existe trois types temporels de base : l’instant, l’intervalle, et la durée (timespan).

Figure 2.19. Type de donnée temporel de MADS

Ces types temporels s’appliquent sur les types d’objets, les attributs et les types de relation. Les objets temporels et les relations temporelles doivent garder un historique de leur état. On parle dès lors de leur cycle de vie. Il est représenté par MADS par un attribut variant dans le temps nommé « lifecycle ». Un objet ou une association passe par un ou plusieurs des quatre états suivants au cours de sa vie :

• Planifié : on projette de créer l’objet.

• Actif : l’objet est pour l’instant actif et membre du type de l’objet.

• Suspendu : l’objet ne peut plus subir certaines opérations.

• Désactivé : une fois l’objet désactivé, il ne peut que rester dans cet état. On ne peut

plus le réactiver ou le suspendre. Seules les opérations de lecture ou suppression

sont autorisées.

Il existe un ordre sur la transition entre les différents états (voir Figure 2.20) Chaque objet a comme obligation d’avoir au moins un état.

25

Deux instants spéciaux, la date de création et la date de mort1, sont associés au cycle de vie.

Figure 2.20. Transitions possibles entre les états d’un objet

Soient 2 objets temporels A et B définis sur 2 intervalles de temps t1 et t2. t1 débute à l’instant t1.début et se termine à l’instant t1.fin. t2 débute à l’instant t2.début et se termine à l’instant t2.fin.

Type de synchronisation Icone Définition

SyncPrecede A syncPrecede B si t1 se situe avant t2, c'est-à-dire si t1.fin est avant t2.début

SyncWithin A SyncWithin B si t1 se situe dans t2, c'est-à-dire si t2.début est avant t1.début et t2.fin est après t1.fin.

SyncStart A et B satisfont cette contrainte si t1.début et t2.début sont égaux.

SyncFinish A et B satisfont cette contrainte si t1.fin et t2.fin sont égaux

SyncEqual A et B sont syncEqual si t1.début et t2.début sont égaux et si t1.fin et t2.fin sont égaux. Ils sont donc SyncEqual s’ils sont SyncStart et SyncFinish.

SyncMeet A syncMeet B si t1.fin et t2.début sont égaux ou t1.début et t2.fin sont égaux.

SyncOverlap A syncOverlap B si t1.début est avant t2.début, t2.début est avant t1.fin et t1.fin est avant t2.fin.

syncDisjoint A et B sont syncDisjoint s’ils n’ont aucuns instants en communs c'est-à-dire que l’intersection entre t1 et t2 est vide.

1 En anglais, date of birth (DOB) et date of death (DOD)

26

SyncGeneric

Cette icône permet de définir une contrainte personnalisée ou générique entre 2 objets temporels.

Figure 2.21. Types de relation de synchronisation dans MADS

Tout comme pour la spatialité, la temporalité fournit une relation spécifiant une contrainte sur les deux entités qu’elle relie. Les types de relation de synchronisation sont donnés dans la Figure 2.21.

2.7.1 Variation dans le temps

Un objet, un attribut ou une relation peuvent varier dans le temps. Ils sont alors dénotés par f(�). C’est une fonction du temps vers le domaine de valeurs de l'attribut. Un historique (passé, présent et futur) sera gardé par la base de données. On dit qu’un objet, un attribut ou une relation est « timestamped».

2.8 La dimension multi-représentation

La multi-représentation désigne la possibilité d’accéder à plusieurs représentations des phénomènes géographiques dans une seule base de données, ces différentes représentations étant liées entre elles pour bien spécifier qu’elles correspondent à une même entité du monde réel. Deux critères sont pris en compte lors de la comparaison de différentes représentations : le point de vue et la résolution [VANGENOT 01].

• Le point de vue matérialise l’intérêt spécifique de l’utilisateur. Ce point de vue a mené

à certains choix de contenu et de représentation, dont principalement le choix des

types d’objets et de relations présents dans la base de données, le choix des propriétés

intéressantes pour décrire ces types et le choix du mode de définition de ces

propriétés.

• La résolution définit le niveau de détail choisi, afin de ne retenir dans la base de

données que les objets reconnus comme étant significatifs.

Il y a deux manières de combiner les représentations différentes d’un même type d’objet : La première est de fusionner toutes les représentations d’un même type d’objet dans un seul objet. La deuxième est de séparer les représentations, de créer un type d’objet pour chaque représentation et de le relier avec une relation de correspondance.

27

a) Fusion des représentations

b) Chaque représentation est un type d’objet avec un lien

spécifiant qu’il représente un même type d’objet.

Figure 2.22 Multi-représentation d’un même type d’objet

Pour associer la représentation à sa perception, MADS utilise des cachets (stamps). Ils sont appliqués sur les types d’objets, les attributs, les relations, mais aussi sur les rôles de la relation, et les propriétés temporelles et spatiales de l’objet. La Figure 2.23 a) montre un schéma avec trois perceptions et la figure b) montre qu’un utilisateur ne s’intéresse qu’à la perception jaune. La Figure 2.24 présente les étapes d’une fusion de deux objets.

Figure 2.23 Utilisation des cachets (Stamps)

a) 3 perceptions combinées

b) Une perception sélectionnée

28

Figure 2.24 Fusion de deux représentations de routes en un type d’objet avec des cachets

Exemple : Soient deux représentations de route (voir la Figure 2.24). La fusion des types d’objets en un seul objet se passe comme suit : Pour chaque représentation, on crée un cachet. Ici on doit créer les cachets s et t. Ces cachets seront appliqués à la nouvelle représentation qui combinera les deux objets. Pour chaque attribut, si sa signature est identique à la signature d’un attribut de l’autre représentation et que leur valeur est identique on rajoute à cet attribut dans la nouvelle représentation les cachets des deux représentations. Par contre, si les attributs ont la même signature mais que leur valeur est différente, il est ajouté qu’en plus il varie selon la perception s et t. L’attribut « nom » est dans ce cas. Le nom diffère selon l’autorité qu’il utilise.

L’autre manière est de faire correspondre le même type d’objet. La relation de correspondance remplit cette fonction. Encore ici, l’orthogonalité de MADS permet de combiner une relation de correspondance avec une relation topologique (voir Figure 2.25) ou avec d’autres relations.

29

Figure 2.25 La relation de correspondance entre deux routes

Dans la Figure 2.25, une contrainte topologique est appliquée sur les routes. Route1 doit être à l’intérieur de Route2. (Une des route est représentée par un polygone, l’autre par une ligne)

2.9 Exemple de schéma MADS

30

Chapitre 3. La suite d’outils MADS

Dans le cadre de ce projet, plusieurs outils ont été créés. Ces outils développés en Java, sont encore au stade de prototype. Ils ont été mis depuis peu sous licence libre2. Le but de cette démarche est d'amener plus de personnes à utiliser MADS et à contribuer au développement de la suite d'outils.

Figure 3.1. La suite d’outils MADS

2 LGPL (GNU Lesser General Public License)

31

Les outils3 comprennent :

• un éditeur de schéma

• un éditeur de requête

• un outil d’affichage de résultat de requête

L’éditeur de schéma ainsi que l’éditeur de requête sont organisés en plusieurs couches. Une première couche, de haut niveau, interagit avec l’utilisateur final, en l’aidant à définir un schéma ou des requêtes, selon les critères du modèle, à un niveau conceptuel. Cette couche est par conséquent la seule couche visible par l’utilisateur. Une deuxième couche, de plus bas niveau, transforme un schéma conceptuel MADS en un schéma intermédiaire plus adapté à une plateforme cible (SIG, SGBD), afin que la requête soit facilement implantable dans celle-ci. Une troisième couche utilise un « wrapper » afin de traduire le schéma intermédiaire dans le langage DDL4/ DML5 de la plateforme cible. XML et GML sont utilisés pour faciliter l’interopérabilité entre les différents outils. XML est utilisé pour le stockage du schéma conceptuel créé par l’utilisateur. Tous les outils utilisent donc XML pour lire ou écrire dans ce schéma. GML est utilisé pour spécifier la structure des réponses : c’est le format de transport des réponses.

3.1 La modélisation

L’éditeur de schéma permet de réaliser un schéma conceptuel dans une GUI. Lorsque l’utilisateur choisit une plateforme cible (SIG ou SGBD), l’éditeur traduit le schéma en un niveau logique intelligible par la plateforme de son choix. Les plateformes cible pour lesquels les outils de translation existent déjà sont Oracle9i, ArcView et MapInfo [Souleymane 03]. Le processus de transformation utilise un modèle logique intermédiaire appelé MADSLog. L’éditeur de schéma est composé de trois types de modules :

• Le constructeur de schéma qui donne à l’utilisateur la possibilité de créer des

schémas MADS. Il gère tant la structure du schéma que ses propriétés graphiques.

Une fois le schéma clôturé il est sauvegardé dans son format graphique et

structurel.

3 Les outils MADS sont disponibles à l’adresse http://cs.ulb.ac.be/mads_tools/

4 DDL : Data Definition Language

5 DML : Data Modeling Language

32

• Le traducteur de schéma transforme le schéma conceptuel en schéma MADSLog,

faisant abstraction de toute notion absente du modèle de données cible.

• Le wrapper de schéma transforme à son tour le schéma MADSLog adapté à un

schéma logique SIG ou SGBD.

Figure 3.2. Vue du fonctionnement interne de l'éditeur de schéma

33

Fig

ure

3.3

. G

UI

de

l'é

dit

eu

r d

e s

ché

ma

34

3.2 L’interrogation

L’éditeur de requête propose à l’utilisateur de spécifier une requête sans la nécessité de connaître un langage de requête textuel (SQL par exemple). La requête se fait directement sur le schéma conceptuel. Ce mode de fonctionnement permet à l’utilisateur de se concentrer sur la sémantique de sa requête plutôt que sur la syntaxe de celle-ci.

Figure 3.4. GUI du constructeur de requête

L’éditeur de requête est composé de cinq types de modules :

• Le Framework de l’éditeur de requête est l’interface qui permet à l’utilisateur de

gérer ses requêtes, et d’interagir avec le constructeur de requête et l’outil

d’affichage de résultat de requête.

35

• Le constructeur de requête (Figure 3.4), décrit la requête dans une expression

MADS.

• Le traducteur de requête effectue le premier pas de la traduction de la requête en

MADS vers une requête adaptée au système cible.

• Le wrapper de requête se charge de la seconde étape de la traduction en

transformant l’expression fournie par le traducteur de requête en une requête

adaptée à la cible SIG ou SGBD.

• Le wrapper de réponse réorganise les résultats du système cible en instances MADS

conformes à la requête originale effectuée en MADS. Ce résultat est fourni dans le

format GML à l’outil d’affichage de résultat de requête.

Traducteur de

requêtes MADS

Oracle

SGBD

Wrapper pour une

autre plateforme

Intéraction visuelle

Editeur de requète

et outil d’affichage

de requête

Wrapper de

requête

Wrapper de

réponse

Wrapper Oracle

Constructeur de

requête

Outil d’affichage

de résultat de

requête

Framework de l’éditeur de requête

résultat MADS en GML

résultat SQLréquête SQL

expression algébrique en XML pour une

base de donnée Oracle

expression algébrique MADS en XML

Figure 3.5. Vue du fonctionnement interne de l’éditeur de requête et de l’outil d’affichage de résultat de

requête

36

3.3 La visualisation

L’outil d’affichage de résultat de requête permet de visualiser les résultats d’une requête de manière intuitive et de naviguer (zoom, déplacement, affichage des propriétés des éléments, …) au travers de ceux-ci. Un wrapper de réponse est nécessaire afin de traduire le résultat d’une requête SQL en format GML pour le rendre compréhensible par l’outil d’affichage.

Figure 3.6. GUI de l’outil d’affichage de résultat de requête

3.4 Remarques

Bien que la suite d’outils permette la modélisation, l’interrogation ainsi que la visualisation des données, elle ne propose pas de solution à la manipulation (création, mise à jour et suppression) des données à l’intérieur de la base de données. Ainsi après avoir modélisé le schéma et traduit celui-ci vers la plateforme cible choisie, on devra passer par d’autres outils pour extraire des données d’autres systèmes d’information géographique, les transformer et remplir les structures logiques de la plateforme cible choisie. L’utilisateur

37

doit donc connaître le schéma logique afin d’établir les correspondances avec le schéma conceptuel pour placer les données au bon endroit. Le projet MurMur vise à résoudre un des problèmes de fédération des bases de données géographiques. Il suppose que les utilisateurs possèdent déjà des données géographiques. Il manque actuellement des outils de création et de manipulation de données. Mais avec la mise à disposition en Open Source sous licence LGPL des outils du projet, nous espérons que les développeurs seront attirés par la modélisation conceptuelle grâce notamment aux nombreuses plateformes qu’elle supporte, telles que MapInfo, ArcView et Oracle. Depuis la fin officielle du projet MurMur, le nombre de plateforme SGBD supportant les données spatiales a considérablement augmenté. On peut citer par exemple MySQL ou encore PostGIS. La plus grosse partie du travail de transformation des concepts MADS vers des concepts relationnels a été réalisée lors du travail pour la transformation pour Oracle. Le support d’autres bases de données relationnelles avec support spatial ne devrait donc pas poser trop de problème. Ce mémoire porte sur la conversion du modèle conceptuel MADS vers les concepts GML et la création d’un outil permettant cette transformation au sein de l’éditeur de schéma (plus exactement au niveau du translateur de schéma ainsi que du wrapper). Cet outil doit donc créer un schéma applicatif GML qui sera utilisé par une base de données XML native.

38

Chapitre 4. XML

4.1 Introduction

XML (eXtensible Markup Language) [W3C:XML] est un langage de description de données. C’est un standard du W3C6 qui a pour but de faciliter le partage d’information sur internet. XML utilise des balises afin de définir la structure et le contenu d'un fichier. Il permet également de décrire d’autres langages en définissant de nouvelles balises. C’est donc un métalangage. De plus, XML est un sous ensemble de SGML (Standard Generalized Markup Language). On y retrouve ainsi certains principes comme le fait que la structure d'un document XML peut être définie et validée par un schéma. Mais SGML est très complexe à utiliser et à mettre en place. Il est peu adapté à une utilisation sur Internet. XML est donc la pour le remplacer.

4.2 Exemple de document XML

1. <?xml version='1.0' encoding='UTF-8' ?>

2. <listePays>

3. <!-- ceci est un commentaire -->

4. <pays continent= "Europe">

5. <nom>Belgique</nom>

6. <superficie>30 528</superficie>

7. </pays>

8. <pays continent= "Asie">

9. <nom>Chine</nom>

10. <superficie>9 634 057</superficie>

11. </pays>

12. </listePays>

Figure 4.1 : Code XML

6 World Wide Web Consortium

39

Figure 4.2 : Arbre de l'exemple

ligne 1 : cette ligne précise que le document contient du XML en version 1.0 et indique le jeu de caractères à utiliser. ligne 2 : une balise ouvrante débute un élément appelé listePays. C’est l’élément racine du document XML. ligne 4 : l’élément pays a un attribut continent, ayant pour valeur "Europe". ligne 12 : une balise fermante, correspondant à la balise ouvrante de la ligne 2, indique la fin de l’élément listePays.

4.3 Avantages du XML

XML est :

• Structuré : les documents XML doivent suivre une syntaxe stricte.

• Flexible : il est possible de définir ses propres balises XML.

• Simple et lisible : le langage est auto descriptif, et donc lisible sans outils

(les fichiers sont au format texte).

• Portable

Il facilite ainsi les échanges d’information et assure la pérennité de celles-ci.

40

4.4 DTD et XML Schema

Il est possible de vérifier la syntaxe d’un document XML par l’utilisation d’une DTD

(Document Type Definition) [W3C:XML] ou d’un schéma XML (XSD7) [W3C:XSD]. Tous deux décrivent la structure des documents. La notion de DTD fait partie de la spécification XML. Une DTD peut être définie sous forme interne, c'est-à-dire en l’incluant dans le document à vérifier, ou sous forme externe dans un autre fichier. Bien qu’il soit facile d’écrire une DTD, il manque certaines possibilités telles que le typage des données. XSD est la pour répondre à ces défauts. De plus, un schéma XML est lui-même un document XML, ce qui n'est pas le cas d'une DTD.

1. <?xml version='1.0' encoding='UTF-8' ?>

2. <!-- fichier pays.dtd -->

3. 4. <!ELEMENT listePays (pays+) >

5. <!ELEMENT pays (nom,superficie) >

6. <!ELEMENT nom (#PCDATA) >

7. <!ELEMENT superficie (#PCDATA) >

8. 9. <!ATTLIST pays continent (Europe|Asie|Afrique|Amérique|Océanie) #REQUIRED >

Figure 4.3 : Exemple de DTD

ligne 3 : une listePays est composée d'au moins un pays. ligne 4 : un pays est composé d’un nom et d’une superficie. ligne 5 : un nom est une donnée textuelle. ligne 6 : continent est un attribut obligatoire de pays, qui a comme valeur possibles Europe, Asie, Afrique, Amérique et Océanie.

1. <?xml version="1.0" encoding="UTF-8" ?>

2. 3. <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

7 XSD : XML Schema Definition

41

4. 5. <xsd:element name="nom" type="xsd:string" />

6. <xsd:element name="superficie" type="xsd:positiveInteger" />

7. 8. <xsd:element name="pays">

9. <xsd:complexType>

10. <xsd:sequence>

11. <xsd:element ref="nom" />

12. <xsd:element ref="superficie" />

13. </xsd:sequence>

14. <xsd:attribute name="continent" use="required">

15. <xsd:simpleType>

16. <xsd:restriction base="xsd:string">

17. <xsd:enumeration value="Europe" />

18. <xsd:enumeration value="Asie" />

19. <xsd:enumeration value="Afrique" />

20. <xsd:enumeration value="Amérique" />

21. <xsd:enumeration value="Océanie" />

22. </xsd:restriction>

23. </xsd:simpleType>

24. </xsd:attribute>

25. </xsd:complexType>

26. </xsd:element>

27. 28. <xsd:element name="listePays">

29. <xsd:complexType>

30. <xsd:sequence>

31. <xsd:element ref="pays" maxOccurs="unbounded" />

32. </xsd:sequence>

33. </xsd:complexType>

34. </xsd:element>

35. 36. </xsd:schema>

Figure 4.4 : Exemple de schéma XML

ligne 1 : comme dans tout document XML, cette ligne précise que le document contient du XML et indique le jeu de caractères à utiliser. ligne 3 : une balise ouvrante débute le schéma XML. Elle peut contenir la définition de l'espace de nom cible. ligne 5 : un élément est déclaré grâce à la balise <xsd:element>. nom est du type xsd:string (type simple prédéfini). Un type de données est associé à chaque élément déclaré. Les

42

éléments pouvant contenir des sous-éléments ou des attributs sont de type complexe. Les éléments n'en contenant pas sont de type simple. ligne 6 : superficie est du type xsd:positiveInteger (type simple prédéfini) ligne 9 : pays est du type complexType. C’est une séquence (ligne 10) d’éléments nom et superficie. ligne 11 : la balise fait référence à un nom, défini précédemment. ligne 14 : un élément attribute peut avoir plusieurs attributs optionnels. Ceux-ci permettent de paramétrer ce qui est acceptable ou non dans le document XML à valider (attribut obligatoire ou optionnel, valeur par défaut...). Par exemple, la ligne 14 permet de rendre l'attribut continent obligatoire. ligne 16 : on peut appliquer une dérivation à un type simple ou à un type complexe. La dérivation par restriction permet de former de nouveaux types simples à partir des types simples existants dans le format XSD. On applique pour ce faire des contraintes à un type simple particulier. Par exemple, ici on veut créer l’attribut continent, de type simple, et le limiter aux valeurs de l’énumération qui suit. ligne 17 à 21 : l’énumération des valeurs possibles pour l’attribut continent. ligne 31 : un schéma XML permet de définir le nombre d’occurrence d’un élément en utilisant les attributs minOccurs et maxOccurs, qui indiquent le nombre minimum et maximum de fois qu’un élément peut apparaître. Pour déclarer qu'un élément peut être présent un nombre de fois illimité, on utilise la valeur unbounded. Ici on peut donc répéter l’élément pays un nombre de fois illimité. ligne 36 : Fin du schéma XML

4.5 Validité d’un document XML

Voici les règles générales de syntaxe du XML :

• l’entête est obligatoire. • un document XML ne peut contenir qu’un seul élément racine. • chaque balise d’ouverture doit être suivie d’une balise de fermeture. Leur nom doit

correspondre. • les noms des éléments sont sensibles à la casse.

Si ces règles sont respectées, le document XML est « bien formé ». Le document XML est « valide » lorsqu’en plus d’être bien formé, il suit les règles d’une DTD ou d’un schéma XML.

43

4.6 Décodage d’un document XML

XML permet de définir un format d'échange et possède des outils pour vérifier la validité des documents. Il faut aussi pouvoir extraire les données des documents XML. Cela est réalisé grâce à un outil appelé parseur (ou encore analyseur syntaxique). Les parseurs XML sont divisés en deux catégories :

• Ceux qui construisent un arbre (Figure 4.2) à partir du document XML, en utilisant le modèle DOM (Document Object Model). Chaque balise XML, appelée élément, sera un nœud de cet arbre. DOM implémente des fonctions permettant de naviguer dans celui-ci. Cette approche est dite hiérarchique

• Ceux qui sont basés sur un modèle orienté événement (comme le début d'un élément, la fin d'un élément) comme SAX (Simple API for XML). Cette approche est dite événementielle.

DOM utilise SAX pour la construction de l’arbre d’un document XML.

Fichier XML

SAX

DOM

Objet Objet

Objet Objet

Objet

Figure 4.5. DOM et SAX

4.7 Technologies associées

DTD et XSD (XML Schema) ont été abordés au point [W3C:XSD]

XPath et XPointer sont des langage[W3C:XPath] et [W3C:XPointer] XSLT (eXtensible Stylesheet Language Transformations) transformer un document XML vers un autre type de document. [W3C:XSLT] Xlink (XML Linking Language)XML. [W3C:XLink] SVG (Scalable Vector Graphicsimages vectorielles. [W3C:SVG] VRML (Virtual Reality Modeling Language) et fichier standards pour représenter des [VRML] et [X3D]

Encodage et modélisation de données

Sélection & Pointeur

Transformation

Lien et Association

Rendu graphique

44

Technologies associées

(XML Schema) ont été abordés au point 4.4 de ce chapitre. [W3C

langages permettant d'adresser les parties d'un docu[W3C:XPath] et [W3C:XPointer]

heet Language Transformations) est un langage transformer un document XML vers un autre type de document. [W3C:XSLT]

ML Linking Language) est un langage pour décrire les liens entre les documents

Scalable Vector Graphics) est un format de fichier standard pour représenter des [W3C:SVG]

l Reality Modeling Language) et X3D (Extensible 3D) sontpour représenter des univers tridimensionnels sur le web

• DTD, XSDEncodage et modélisation de

• XPath et XPointer

• XSLT

• XLink

• SVG, VRML, X3D

de ce chapitre. [W3C : DTD] et

permettant d'adresser les parties d'un document XML.

est un langage permettant de transformer un document XML vers un autre type de document. [W3C:XSLT]

liens entre les documents

de fichier standard pour représenter des

sont des formats de sur le web.

XPath et XPointer

SVG, VRML, X3D

45

Chapitre 5. GML

Dans ce chapitre, je présente le « Geography Markup Language » 8, son contexte, les concepts de base et enfin les outils pour le manipuler.

5.1 Contexte

Le Geography Markup Language (GML) est un langage de balisage pour la géographie défini par l’Open Geospatial Consortium (OGC). Basé sur XML, GML est utilisé pour structurer l’information géographique de manière à faciliter son partage sur Internet. GML n'est pas le premier métalangage utilisé pour décrire l'information géographique, mais il est le premier à être largement accepté au sein de la communauté SIG. D’autres formats ont été conçus afin de stocker et d'échanger des informations spatiales et temporelles, mais il leur manque souvent des outils de référence et de validation. L'un des avantages de l'utilisation de GML est qu'il permet de tirer profit des outils destinés à XML. GML utilise ainsi les schémas XML, XLink et XPointer. Enfin, les données GML peuvent être mélangées avec des données non spatiales.

5.2 Motivations

L’interopérabilité est le but principal de GML. Il y a un besoin grandissant de pouvoir combiner des données de différents systèmes SIG situés à divers endroits du globe, en réponse à des événements tels que des catastrophes ou pour des besoins d’évaluation et de prédiction. Voici un exemple où les données géographiques ne sont pas centralisées sur un seul système : Des départements locaux modélisent chacun des informations dans leur système SIG. Ensuite, d’autres départements utilisent les informations de chacun de ces systèmes pour réaliser des analyses ou des prédictions au niveau global. Il faut donc que tous les départements s’accordent sur le format d’échange des données.

8 http://www.opengis.net/gml/

46

Figure 5.1. Cas d’utilisation possible

Comme spécifié par l’OGC, GML est destiné à :

• être un langage pour définir l’information géographique.

• être lisible et compréhensible par des humains. En sachant comment les données

sont définies, il est facile de les importer dans son système.

• lier les données de différentes bases de données géographiques entre elles,

autorisant ainsi une maintenance locale et un accès global.

• être facilement transformable, parce que les données géographiques sont

maintenues longtemps après leur création. Dès lors, il faut permettre la conversion

vers d’autres formats.

• servir d’entrée et de sortie pour les services web géographiques.

• être non-propriétaire et ouvert. Tout le monde peut prendre part au consortium et

aux discussions sur le futur de GML, et peut l’utiliser.

47

5.3 Définition de l’information géographique

À partir de la version 3, GML est défini par un Schéma de définition XML (XSD) 9. GML rajoute ses propres structures et types à XSD. L’utilisateur réalise un modèle avec les structures et types de son choix. Cette étape s’appelle la création d’un schéma GML applicatif. Elle consiste à modéliser les objets et les relations en créant des balises spécifiques en XSD. Il existe des schémas GML applicatifs déjà définis pour certains domaines. Il est préférable que l’utilisateur se base sur ces schémas afin de faciliter les échanges de données.

Figure 5.2. Définition d’un schéma applicatif

Mon travail automatise la création du schéma GML applicatif, pour autant qu’il existe une correspondance entre les concepts MADS utilisés et des concepts GML. Il consiste donc à représenter correctement les concepts MADS à l’aide des concepts GML équivalents ou dans le cas contraire, à les représenter de façon proche.

Une fois le schéma GML applicatif créé, les données sont encodées suivant la structure qu’il définit. Le résultat est un document GML.

5.4 Le modèle GML

Le modèle GML est proche du modèle Entité-Relation. Les entités sont des « features » qui représentent des objets ou phénomènes qui peuvent avoir des propriétés géographiques. Les relations sont modélisées par les featureMembers et les Xlinks. . Mais il est tout à fait

9 Dans la version 2, GML est défini par une DTD.

Types prédéfinis de Schéma XML

Types principaux du Coeur de GML

Schéma GML applicatif A

Schéma GML applicatif B

Schéma GML applicatif C

possible d’utiliser GML pour des domaines autres que l’information géographiqueprofiter des constructions que ce lan La représentation en GML d’un objet est un élément XML. Les propriétés de cet objet sontles éléments fils de celui-cigéométrique (un point, une ligne, …). Dans l’exemple cielle possède trois propriétésboite qui englobe le pays.

Figure 5.3. Définition de la balise pays avec trois propriétés, dont une géographique

La définition n’est pas complète si on ne précise pas que la structure du pays (PaysType) est dérivée d’AbstractFeatureType. De même, une balise _Feature plus général

1. <element name="Pays" type=" PaysType " substitutionGroup="gml:_Feature"/>

2. <complexType name = “PaysType” >

3. <complexContent>

4. <extension base="gml:AbstractFeatureType">

5. <sequence>

6. …

7. </sequence>

8. </extension>

9. </complexContent>

10. </complexType>

Pays

nom

supeficie

BoundedBy

48

possible d’utiliser GML pour des domaines autres que l’information géographiquer des constructions que ce langage a définies.

La représentation en GML d’un objet est un élément XML. Les propriétés de cet objet sontci. Une propriété est dite spatiale si sa vale

géométrique (un point, une ligne, …). Dans l’exemple ci-dessous, Pays est une feature et propriétés : nom, superficie et BoundedBy. Cette dernièr

1. <element name = “Pays” type = “PaysType” />

2. <complexType name = “PaysType” >

3. <sequence>

4. <element name = “nom” type=“string” />

5. <element name = “superficie” type=“double” />

6. <element ref = “gml:BoundedBy” />

7. </sequence>

8. </complexType>

. Définition de la balise pays avec trois propriétés, dont une géographique

complète si on ne précise pas que la structure du pays (PaysType) est eatureType. De même, la balise Pays doit être utilisée partout où

générale. C’est le concept d’héritage.

<element name="Pays" type=" PaysType " substitutionGroup="gml:_Feature"/>

<complexType name = “PaysType” >

<extension base="gml:AbstractFeatureType">

Figure 5.4. Pays est une feature

possible d’utiliser GML pour des domaines autres que l’information géographique, pour

La représentation en GML d’un objet est un élément XML. Les propriétés de cet objet sont . Une propriété est dite spatiale si sa valeur est un objet

ssous, Pays est une feature et : nom, superficie et BoundedBy. Cette dernière représente la

<element name = “Pays” type = “PaysType” />

<element name = “nom” type=“string” />

<element name = “superficie” type=“double” />

. Définition de la balise pays avec trois propriétés, dont une géographique

complète si on ne précise pas que la structure du pays (PaysType) est ys doit être utilisée partout où il y a

<element name="Pays" type=" PaysType " substitutionGroup="gml:_Feature"/>

49

Les relations entre deux features sont représentées de trois manières possibles :

• Une relation lie directement une feature à une autre en l’incluant dans celle-ci.

Dans le cas 1 de la Figure 5.5, la relation « possede » a directement comme fils un

élément région.

• Une relation possède une référence à une feature interne au document. Dans le cas

2, un attribut xlink :href donne l’adresse de la feature référencée. La feature region

se trouve dans le même document que pays. Son adresse locale est formée par le

caractère # suivi son id.

• Une relation possède une référence à une feature externe au document. Dans le

cas 3, les features pour pays et region se trouvent sur des serveurs différents.

L’adresse d’identification uniforme de ressource (URI), est composée de l’adresse

du serveur, du chemin vers le document ainsi que de la situation locale de la

ressource, représentée par # suivi de son id.

cas 1

1. <Pays gml:id=”p1”> 2. <nom>Belgique</nom> 3. … 4. <possede> 5. <region gml:id=”r1”> 6. … 7. </region> 8. </possede> 9. … 10. </Pays>

cas 2

1. <Pays gml :id= ”p1”>

2. <nom>Belgique</nom>

3. … 4. <possede xlink :href= ”#r1”> 5. … 6. </Pays> 7.

8. <region gml :id= ”r1”> 9. … 10. </region>

cas 3

1. <Pays gml :id= ”p1”> 2. <nom>Belgique</nom> 3. … 4. <possede xlink:href=”http://www.gov.be/sig/regions.xml#r1”> 5. … 6. </Pays>

� �

Figure 5.5 Les relations en GML

50

Les relations entre les features en GML se basent sur les spécifications de XLink. L’attribut xlink :href dans un document GML signifie que la valeur de l’élément se trouve à l’adresse référencée et qu’elle doit être récupérée.

5.5 Les modules de GML

Pour aider à caractériser et encoder les informations, GML propose cinq grands modules :

Figure 5.6 Les cinq modules principaux de GML

5.5.1 Le cœur GML

C’est le minimum requis pour qu’un parseur puisse comprendre le document. Il contient les définitions des objets GML, des features et des relations. Il contient également tous les types abstraits des autres modules. Lorsque le parseur rencontre un élément « Curve », il ne connait pas sa structure. Par contre, il sait qu’il a à voir avec le module géométrie. En remontant la hiérarchie des éléments du schéma définissant « Curve », il retombera sur AbstractGeometryType. Le cœur GML est défini par gmlBase.xsd, xlinks.xsd et basicTypes.xsd.

5.5.2 La géométrie

C’est l’un des plus gros modules de GML. Il implémente tous les types géographiques définis par l’ISO 19107. Le module géométrique de GML supporte les dimensions 0, 1 ,2 et 3. Les objets correspondants à celles-ci sont les points, les courbes, les surfaces et les solides. Dans la version 2 de GML, les seules primitives géométriques supportées étaient les points et les lignes: Point, LineString, LinearRing, Box et Polygon ; ainsi que les agrégats suivants : MultiPoint, MultiLineString, MultiPolygon. La version 3 supporte de nouveaux types comme Arc, Circle, CubicSpline, Ring, OrientableCurve, OrientableSurface, Solid ; et leurs agrégats correspondants comme MultiCurve, MultiSurface, etc… Cette version supporte aussi les types composites suivants: CompositeCurve, CompositeSurface, et CompositeSolid. La différence entre un agrégat de Curve et un type

Coeur GML

Géométrie Topologie Temps Couverture Projection

51

composite Curve dans GML est que les membres géométriques d’un type composite sont tous connectés alors que les membres d’un agrégat peuvent être disjoints. Les types sont répartis dans 5 schémas :

• geometryBasic0d1d.xsd, geometryBasic2d.xsd, geometryAggregates.xsd

contiennent les géométries linéaires. Ces schémas sont compatibles avec GML2.

• geometryPrimitives.xsd, geometryComplex.xsd contiennent tous les types et

éléments de la géométrie non linéaire (par exemple les courbes).

La Figure 5.7 donne la hiérarchie des types géométriques utilisés dans MADS.

52

Figure 5.7 La hiérarchie des types géométriques de GML telle que décrite par l’OGC

53

5.5.3 La topologie

La topologie décrit les propriétés spatiales qui restent inchangées lorsqu’on déforme des objets de façon continue (étirement par exemple). Dans GML, la topologie spatiale est basée sur des nœuds, des arrêtes, des faces et des solides et la description de leur relations. Ce sont les primitives de la topologie. GML laisse l’utilisateur choisir le type de relation. Il doit lui-même définir la propriété topologique d’un lien. Les primitives fournies ne servent que de conteneurs pour des éléments géométriques. Le fichier topology.xsd définit tout cela.

5.5.4 Le temps

Ce module comprend la définition des primitives simples de temps comme Instant et Période, et des primitives complexes. Ces dernières fournissent la base de la topologie temporelle. Tout comme la topologie spatiale, la topologie temporelle fournit des nœuds et des arrêtes. Ceux-ci permettent de modéliser l’historique d’un objet variant dans le temps (ordre sur le temps). Les fichiers utilisés sont temporal.xsd et dynamicFeature.xsd.

Figure 5.8 La hiérarchie du temps

54

5.5.5 La couverture

Une couverture GML est une fonction de distribution, définie sur un domaine spatial.

Figure 5.9 La fonction de distribution

Voici les trois composants formant une couverture (voir la Figure 5.10)

• Domain Set : l’ensemble des domaines comprend soit une collection d’éléments

spatiaux (point, ligne et régions) soit une grille (Grid) à qui l’on doit assigner une

valeur

• Range Set : l’ensemble des valeurs assignées aux éléments du domaine.

• Coverage Function : la fonction de couverture associe un domaine à sa valeur.

Les fichiers qui composent le module de couverture sont coverage.xsd et grid.xsd.

Figure 5.10 Les composants d’une couverture

5.5.6 La projection

Un autre module importantfonction qui à chaque point de la surfaGML contient un dictionnaire des projections existantdéfini une fois pour tous les documents ou être définit géométrique. Six fichiers forment le module coordinateSystems.xsd, datums.xsd, dataQuality.xsd, coordinateReferenceSystems.xsd.

5.5.7 Normes ISO

Tous les modules de GML suivent les norme ISO.

Figure

5.6 Exemple

Voici l’exemple donné par représentant une ville et ses propriétés géographiques.

10

Coordinate Reference System

GML 3

• OGC Abstract Specification

• W3C XML, SMIL, SVG

• ISO 19107 Spatial Schema

• ISO 19108 Temporal Schema

• ISO 19109 Applicatoin Schemas

• ISO 19118 Encoding

• ISO 19115 Metadata

• ISO 19123 Coverages

55

projection

important de GML est le système de projection (CRSchaque point de la surface (3d) de la Terre associe un point sur un

GML contient un dictionnaire des projections existantes. Le système de projection doit être défini une fois pour tous les documents ou être définit petit à petit pour

forment le module CRS: referenceSystems.xsd, coordinateOperations.xsd, coordinateSystems.xsd, datums.xsd, dataQuality.xsd, coordinateReferenceSystems.xsd.

Tous les modules de GML suivent les norme ISO.

Figure 5.11 Les normes ISO sur lesquelles repose GML

donné par l’Open Geospatial Consortium (OGC) d’un documentes propriétés géographiques.

OGC Abstract Specification

W3C XML, SMIL, SVG

ISO 19107 Spatial Schema

ISO 19108 Temporal Schema

ISO 19109 Applicatoin Schemas

ISO 19118 Encoding

ISO 19115 Metadata

ISO 19123 Coverages

(CRS10). Il décrit une de la Terre associe un point sur un plan (2d).

s. Le système de projection doit être petit à petit pour chaque type

referenceSystems.xsd, coordinateOperations.xsd, coordinateSystems.xsd, datums.xsd, dataQuality.xsd, coordinateReferenceSystems.xsd.

d’un document GML

56

Figure 5.12 Représentation graphique de l’exemple

1. <?xml version=”1.0” encoding=”UTF-8”?>

2. <CityModel xmlns=”http://www.opengis.net/examples” … >

3. <gml:name>Bruxelles</gml:name>

4. <gml:boundedBy>

5. <gml:Box srsName=”http://www.opengis.net/gml/srs/epsg.xml#4326”>

6. <gml:coord><gml:X>0.0</gml:X><gml:Y>0.0</gml:Y></gml:coord>

7. <gml:coord><gml:X>100.0</gml:X><gml:Y>100.0</gml:Y></gml:coord>

8. </gml:Box>

9. </gml:boundedBy>

10. <cityMember>

11. <River>

12. <gml :description>Elle passe par Bruxelles</gml :description>

13. <gml:name>Senne</gml:name>

14. <gml:centerLineOf>

15. <gml:LineString srsName=”http://www.opengis.net/gml/srs/epsg.xml#4326”>

16. <gml:coord><gml:X>0</gml:X><gml:Y>60</gml:Y></gml:coord>

17. <gml:coord><gml:X>80</gml:X><gml:Y>70</gml:Y></gml:coord>

18. <gml:coord><gml:X>100</gml:X><gml:Y>40</gml:Y></gml:coord>

19. </gml:LineString>

20. </gml:centerLineOf>

21. </River>

22. </cityMember>

23. …

Code XML de l’exemple

57

5.7 Les outils pour la création de schéma applicatif GML

Il existe plusieurs moyens pour créer le schéma applicatif GML :

• Le premier moyen, le plus classique et d’utiliser un éditeur de texte ou un outil

gérant le format XML.

• Une autre façon d’y parvenir est de modéliser visuellement les concepts et de

transformer le modèle ainsi créé en schéma applicatif GML correspondant. Mon

travail porte sur cette deuxième manière de faire.

5.8 Les outils de manipulation

GML étant basé sur le standard W3C XML, il bénéficie de facto des outils créés pour celui-

ci. Ainsi, des outils de manipulation comme SAX ou JDOM, de base de données comme

eXist-db, de transformation comme XSLT et encore beaucoup d’autres, pourront être

utilisés avec GML.

Un outil pour l’affichage de données GML en passant par SVG est inclus dans la suite

d’outils MADS [Deb2003]. Pour la composante temporelle, l’instant de la visualisation est

choisi sur une ligne de temps. Faire défiler le slider sur cette dernière permet de voir

l’évolution des données spatio-temporelles.

5.9 Les services Web

5.9.1 Web Map Service (WMS)

Un service qui implémente la spécification Web Map Service permet de produire des cartes de données géographiques à partir de différents serveurs de données. Cela permet de mettre en place un réseau de serveurs cartographiques à partir desquels des clients peuvent construire des cartes interactives. Un service WMS retourne une image visualisable sur un écran d'ordinateur. Le serveur produit des cartes au format image comme JPEG, PNG ou GIF, ou sous forme d'éléments vectoriels comme le SVG.

58

5.9.2 Web Feature Service (WFS)

Un service qui implémente la spécification Web Feature Service permet à un client d’obtenir et de modifier une feature sur le serveur. Les opérations suivantes sont définies dans les spécifications de WFS :

• GetCapabilities : cette opération permet au serveur WFS de décrire les opérations

possibles et d’indiquer les features supportées. Certains WFS n’implémentent pas tous

les spécifications optionnelles de WFS (Transaction et LockFeature).

• DescribeFeatureType : Pour chaque feature supportées, le serveur WFS envoie au

client la structure de données (un schéma d’application GML) du feature demandée.

• GetFeature : un serveur WFS envoie une liste de features lorsqu’il reçoit une

demande de features formulée en Catalog Query Language (CQL). CQL est un langage

de filtrage. Il permet de faire des sélections spatiales et non-spatiales.

Si le support transactionnel est implémenté, le serveur WFS possède en plus ces opérations-ci

• Transaction : Un serveur WF s’il implémente le support de la transaction possède ses

opérations sont 'Create', 'Update' et 'Delete' sur les features.

• LockFeature : Le support de la transaction doit empêcher l’écriture concurrente sur

une ou plusieurs instances pendant la durée d'une transaction. LockFeature permet de

faire une demande de blocage.

Les serveurs WFS permettent de partager les features sur Internet, et de fédérer les bases de données.

59

Chapitre 6. Correspondance entre les concepts

MADS et les concepts GML

Dans les chapitres précédents, j'ai parlé du modèle MADS pour la modélisation de base de données spatio-temporelles ainsi que du modèle d’échange GML. Nous allons maintenant voir comment obtenir un schéma GML applicatif à partir du modèle MADS.

6.1 Contexte

La spécification GML comprend environs 600 pages et plus de 1000 balises de noms d’objet. Elle définit un grand nombre de géométries pour décrire les features et offre également la possibilité d'encoder des couvertures, des topologies, le temps et les features dynamiques. GML a été conçu pour couvrir de nombreux besoins. Mais de par la taille de sa spécification, il est complexe à utiliser. Il existe donc une forte barrière à son adoption. Pour accélérer celle-ci, l’OGC a créé des sous-ensembles simplifiés de GML dont l’un des plus connus est le profile GML « Simple Feature ». Des outils visuels existent pour la création du code XML et des schémas XML. Une personne devra dès lors travailler au niveau des éléments et des balises pour modéliser les concepts thématiques tels que les objets, les attributs et les relations comme vu dans l’exemple cité au chapitre GML.

6.2 Etude de l’art

Pour palier à ce problème, le projet GeNorway [UML2GML 02] a utilisé le langage UML (Unified Modeling Language) pour modéliser le schéma GML applicatif et pour générer automatiquement du code GML à partir d’un schéma de classe UML. Une équivalence entre UML et GML a été réalisée en formulant plusieurs contraintes de conception :

• Le schéma UML doit être conforme aux règles spécifiées par le modèle conceptuel UML. C’est la seule règle propre à UML.

• Le schéma UML doit être conceptuel et neutre de toute implémentation. Il ne doit rien savoir à propos de GML.

60

• Le schéma GML applicatif généré doit être pleinement déterminé par le schéma UML. Aucunes modifications ultérieures par l’utilisateur ne doivent être nécessaires sur le schéma GML applicatif. Du côté positif, s’il y a un accord entre 2 parties sur le schéma UML, cela implique que les 2 parties seront aussi en accord sur le schéma GML.

• Le schéma GML applicatif généré doit exploiter des constructions fournies par XML schéma comme l’héritage, les types de données et les liens XLink afin de faciliter la lecture de ce schéma et sa compréhension.

• Le schéma GML généré, ainsi que les documents GML correspondants, doivent remplir les spécifications GML.

Voici les problèmes que l’équipe du projet GeNorway a rencontrés :

a) Héritage en GML : D’après GML, tout type qui contient d’autres types doit nécessairement être une featureCollection, ce qui veut dire qu’il contient des features. Ainsi une feature ferme peut avoir plusieurs champs. Dès lors elle doit être de type featureCollection selon les règles GML. Mais si cette ferme hérite d’Habitation de type feature, il y aura un conflit.

b) Héritage multiple en UML : UML possède l’héritage multiple alors qu’il n’existe pas en Schéma XML. Si l’on veut suivre les contraintes de conceptions, on ne peut pas simplement copier les attributs des supertypes dans le fils.

c) Ordre des sous-éléments en GML : Il n’existe pas de manière de définir l’ordre des attributs et des associations dans UML alors qu’ils suivent un ordre en GML. Il faut définir un ordre pour éviter qu’à chaque génération, le schéma GML soit modifié alors que le schéma UML reste identique. C’est ce que les responsables du projet on fait.

d) Déclaration globale en GML : Les associations sont représentées par une balise ayant le nom du rôle de l’association. Les balises sont définies globalement. Les noms de tous les rôles devront être uniques alors qu’en UML les rôles sont seulement uniques au sein d’une classe. La solution proposée est de combiner le nom de la classe aux rôles.

e) Modélisation des restrictions de domaine de valeur en UML : GML permet de restreindre des valeurs à un domaine par le mécanisme de restriction.

f) Définition compliquée de l’association en GML : GML modélise l’association par une balise qui contient ou réfère aux éléments qui participent à l’association, alors qu’il suffirait d’inclure directement un élément dans l’autre élément de l’association.

61

Le point a) est résolu en créant une classe de type featureCollection pour chaque feature. Cette classe fait office de conteneur pour la feature. L’héritage se fait uniquement entre les features et non les conteneurs. C’est une modélisation explicite car elle viole le concept de la modélisation conceptuelle. L’utilisateur doit connaitre les spécificités de GML. [Galdos02] Je reviendrais sur certains de ces points plus tard lorsque le problème sera rencontré. Le projet GeNorway ne s’intéresse qu’à l’utilisation des concepts de base de GML : les features, les relations et attributs combinés à la temporalité et la spatialité simple. En effet, les concepts comme la topologie, la couverture ou les éléments dynamiques (évoluant soit dans le temps, soit dans l’espace) ne sont pas pris en compte.

6.3 MADS au lieu de l’UML

MADS est un modèle conceptuel, tout comme l’UML mais spécifiquement conçu pour la modélisation spatio-temporelle. Ses avantages par rapport à l’UML sont :

• L’utilisation d’icônes pour marquer un élément d’un type temporel et/ou spatial. Avec

l’UML, on doit apprendre à utiliser les types temporels et spatiaux défini par la norme

ISO. L’utilisation d’icônes dans MADS permet une compréhension plus facile du

schéma entre les différents utilisateurs.

• L’orthogonalité des dimensions. Avec l’UML, pour marquer les objets d’une classe

comme étant spatiaux, il faut créer un attribut avec le type spatial. Pour reconnaître

cet attribut comme étant l’emprise de l’objet, il faut s’accorder sur un nom et l’utiliser

partout.

• Le support des prédicats topologiques et de synchronisation sur les relations.

• Le support de nombreux langages cibles (SQL, GML, …) avec un même schéma

conceptuel.

• La multi-représentation. L’UML ne propose pas de mécanisme pour combiner deux

représentations différentes.

62

6.4 Traduction

Comme expliqué dans [ParZimMinAis2002], tous les concepts que propose le modèle conceptuel MADS n’existent pas forcément dans les modèles logiques cibles. Le concept de spatialité d’un objet n’existe pas tel quel dans les modèles tels que MySQL ou encore Oracle. Pour les implémenter sur ces modèles, il faut transformer le modèle conceptuel. Cette transformation consiste à remplacer un concept C du modèle MADS par une construction similaire. Elle remplace le concept C par des concepts C1, C2, …, Cn qui eux, existent sur le modèle logique cible. Le modèle conceptuel intermédiaire s’appelle MADS minus. Le schéma basé sur le modèle intermédiaire est ensuite retranscrit vers le modèle logique cible. La production du modèle logique cible consiste à réécrire le schéma MADS minus avec la syntaxe du modèle logique cible.

6.5 Règle de transformation

Une règle de transformation est une classe héritant de TransformRule et implémentant la fonction applyTransformRule qui prend comme paramètres le document XML, le nœud actuel à traiter et le nœud grand père du nœud actuel. Chaque règle de transformation peut posséder une condition d’application sur le nœud courant servant à filtrer les nœuds sur lesquels elle doit être appliquée. Voici un exemple de règle de transformation de concept. Le type interval est remplacé par le concept d’instants. Il y en a deux : un instant de début et un instant de fin. Ces deux attributs forment un attribut de type complexe. Object E { attribute a (x, y) interval }

�

Object E { attribute a (x, y) {

attribute start (1,1) instant

attribute end (1,1) instant

}

}

Figure 6.1 Transformation du type Interval en un type groupant deux instants

L’implémentation de cette règle de transformation ne se fait pas tout à fait comme expliqué ci-dessus. Bien que l’idée générale soit correcte, l’implémentation dépend de la structure XML de la représentation du schéma MADS (voir la Figure 6.2).

63

Attribute { Attributedeclaration { Name = ‘a’ Predefineddomain {

Temporaldomain { type=’interval’ }

}

} }

Par

Attribute { Attributedeclaration { Name = ‘a’ Complexattribute {

Attribute {

Attributedeclaration {

name = ‘start’

Predefineddomain {

Temporaldomain { type=’instant’ }

}

}

}

Attribute {

Attributedeclaration {

name = ‘end’

Predefineddomain {

Temporaldomain { type=’instant’ }

}

}

}

}

} }

Figure 6.2 Transformation de la structure XML du schéma MADS

6.6 Architecture du traducteur de schéma MADS

Le module de traduction est constitué de deux parties : une partie visuelle (GUI) et une partie réalisant l’application des règles pour la traduction. La partie visuelle « VisualTranslator » prend un fichier MURMUR en input et demande le driver à utiliser. Un driver est un fichier XML définissant la liste de règles à appliquer pour traduire un schéma MADS vers un schéma cible. Il existe déjà des drivers pour Oracle8 et Oracle9 [MUR 02] ainsi que Arcview [COB 02].

Figure

Une fois le driver sélectionné et le processus de traduction déclenché, l’outil va appliles différentes règles sur le fichier input pour produire le fichier output. Algorithme :

- Ouvrir le fichier « driver

- Ouvrir le fichier MURMUR spécifié en input, le transformer

DOM.

- Chaque règle listée correspond à une classe, elle sera chargée dynamiquement puis sera

insérée dans un vecteur en fonction de son préfixe (GD, MR, R, ST, C). Chaque vecteur

représente une famille de règles. Il a cinq gr

transformation de type générales (GD), les règles de transformation pour la multi

représentation (MR), les règles de suppressions (R), les règles de transformations des types

spatio-temporelles et les règles de tran

familles de règles et qui dépendent de la cibles(C).

- Chaque famille de règles

suppression R, puis les règles MR, les règles ST, les règles GD

- Pour chacune des ces familles, un pa

Cela signifie qu’on parcourt

courant. Toutes les règles

courant. A chaque fois qu’une règle de transformation est appliquée avec succès (le nœud

64

Figure 6.3 Capture d'écran du traducteur de schéma

Une fois le driver sélectionné et le processus de traduction déclenché, l’outil va appliles différentes règles sur le fichier input pour produire le fichier output.

driver » qui est un fichier XML définissant une liste de règle à appliquer.

Ouvrir le fichier MURMUR spécifié en input, le transformer en forêt de nœuds au moyen de

Chaque règle listée correspond à une classe, elle sera chargée dynamiquement puis sera

insérée dans un vecteur en fonction de son préfixe (GD, MR, R, ST, C). Chaque vecteur

représente une famille de règles. Il a cinq grandes familles de règles

transformation de type générales (GD), les règles de transformation pour la multi

représentation (MR), les règles de suppressions (R), les règles de transformations des types

temporelles et les règles de transformation n’appartenant à aucune des autres

familles de règles et qui dépendent de la cibles(C).

Chaque famille de règles est appliquée suivant un ordre particulier : d’abord les règles de

suppression R, puis les règles MR, les règles ST, les règles GD et enfin les règles C.

Pour chacune des ces familles, un parcours en profondeur de type pos

’on parcourt les nœuds fils de gauche à droite avant de

courant. Toutes les règles d’une famille seront testées au moment du traitement du

haque fois qu’une règle de transformation est appliquée avec succès (le nœud

Une fois le driver sélectionné et le processus de traduction déclenché, l’outil va appliquer

» qui est un fichier XML définissant une liste de règle à appliquer.

en forêt de nœuds au moyen de

Chaque règle listée correspond à une classe, elle sera chargée dynamiquement puis sera

insérée dans un vecteur en fonction de son préfixe (GD, MR, R, ST, C). Chaque vecteur

andes familles de règles : les règles de

transformation de type générales (GD), les règles de transformation pour la multi-

représentation (MR), les règles de suppressions (R), les règles de transformations des types

sformation n’appartenant à aucune des autres

: d’abord les règles de

et enfin les règles C.

rcours en profondeur de type post-ordre est effectué.

les nœuds fils de gauche à droite avant de traiter le nœud

au moment du traitement du nœud

haque fois qu’une règle de transformation est appliquée avec succès (le nœud

65

courant répond à la condition de la règle), le processus reprend depuis la racine du

document XML pour la famille de règles en cours. Une fois qu’il n’est plus possible

d’appliquer une règle avec succès, la traduction passe à la prochaine famille de règles.

6.7 Conversion d’un schéma MADS vers un schéma GML

La conversion du schéma MADS est réalisée par partie :

• La partie thématique est proche du travail effectué par [UML2GML].

• La partie spatiale fait la correspondance entre les modèles pour les types spatiaux et

définit la variation dans l’espace.

• La partie temporelle fait la correspondance entre les modèles pour les types temporels

et définit la variation dans le temps.

• La partie multi-représentation introduit le concept dans GML.

6.8 Représentation de la dimension thématique

Les concepts de GML sont très proches des concepts thématiques de MADS. Voici les règles de transformation à appliquer pour chaque concept MADS.

6.8.1 Type d’objet

Soit un objet T avec des attributs quelconques, il sera représenté par une classe T-Type (la balise complexType) héritant structurellement de la classe AbstractFeatureType de GML. Cet objet sera représenté par une balise T qui pourra être utilisée en lieu et place de toute balise appartenant au groupe « _feature ».

<element name="T" type="app:T-Type " substitutionGroup="gml:_Feature"/> <complexType name="T-Type”> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> ... <sequence> </extension> </complexContent> </complexType>

Figure 6.4 Représentation d’un type d’objet T en GML

Bien qu’un objet ait été défini, si nous voulons pouvoir avoir plusieurs instances de cet objet, nous devons définir un conteneur d’objets. GML fournit une FeatureCollection. Pour chaque objet T, un ensemble T-set ayant des objets T est créé.

66

<element name="T-Set" type="app:T-Set-Type" substitutionGroup="gml:FeatureCollection"/> <complexType name="T-Set-Type"> <complexContent> <extension base="gml:FeatureCollectionType" /> </complexContent> </complexType>

Exemple : <T-Set> <featureMember> <T gml:id="t1"> ... </T> </featureMember> <featureMember> <T gml:id="t2"> ... </T> </featureMember> </T-Set>

L’utilisation de FeatureCollection impose d’encadrer chaque instance de T par une balise featureMember (comme dans l’exemple) ou d’encadrer tous les T en une fois à l’aide de la balise featureMembers. Dans la définition ci-dessus de T-Set, celui-ci peut contenir n’importe quelle feature. Pour se restreindre aux objets T, remplacer la balise restriction par la balise extension n’aura aucun effet. T-Set est défini comme contenant des featuresMember ou un featureMembers. Dès lors nous devons créer un complexType T-member(s)-type avec comme balise T-member(s) pouvant remplacer featureMember(s). T-member-(s)-type sera une restriction sur featurePropertyType ou featureArrayPropertyType contenant soit une fois T-type en l’important pour featureMember soit plusieurs fois en l’important pour featureMembers.

6.8.2 Attributs

Les attributs supportés par MADS sont aussi supportés par GML. Ce sont les propriétés d’une feature.

Attribut Monovalué et Multivalué

Pour un attribut monovalué, il n’est pas nécessaire de préciser la cardinalité c’est-à-dire le minOccurs ainsi que le maxOccurs de la balise, étant donné qu’ils sont mis à 1 par défaut. Pour un attribut multivalué, il faut mettre le maxOccurs à unbounded.

67

Attribut Simple et Complexe

Un attribut simple (comme l’attribut B de l’exemple ci-dessous) ne pose pas de problème. GML supporte les types définis par MADS. Un attribut complexe A composé d’attributs simples ou complexes A1, A2, …, Am est défini par une classe A-Type reprenant les attributs A1, A2, …, Am. Nous appliquons la règle tant qu’il reste des attributs complexes. Exemple : <complexType name="T-Type"> <complexContent> <extension base="gml:AbstractFeatureType"> <sequence> <element name="A" type="A-Type" /> <element name="B" type="…" > <element name="C" type="…" __________________________minOccurs="1" maxOccurs="unbounded" > <sequence> </extension> </complexContent> </complexType>

<complexType name="A-Type"> <sequence> <element name="A1" type="…" /> <element name="A2" type="…" /> ....... <element name="Am" type="…" /> <sequence> </complexType>

Attribut Enuméré

Un attribut énuméré (ex : etat) est créé en passant un type simple (ex :etat-enum) basé sur un type de valeur (ex : string) sur lequel nous avons imposé une restriction sur le choix possible des valeurs (ex : des mots). Nous pouvons créer une énumération de chiffres en restreignant le range d’integer par exemple. <element name="etat" type="etat-Enum"> <simpleType name="etat-Enum"> <restriction base="string"> <enumeration value="scheduled"/> <enumeration value="active"/> <enumeration value="suspended"/> <enumeration value="disabled"/> </restriction> </simpleType>

6.8.3 Généralisation

Soit un objet T et un objet TE héritant de T, ce cas est similaire au cas pour un type d’objet à une exception près. Le groupe de substitution doit être modifié pour refléter le fait que la

68

balise TE peut être utilisée en lieu et place de la balise T. Nous pouvons spécifier la substitution car le type de T est T-Type et TE-Type dérive de T-Type.

<element name="TE" type="app:TE-Type" substitutionGroup="app:T"/> <complexType name="TE-Type"> <complexContent> <extension base="app:T-Type"> <sequence> ... <sequence> </extension> </complexContent> </complexType>

Figure 6.5 Représentation d’un héritage en GML

L’héritage multiple est plus compliqué à reproduire avec les concepts de XML. En effet, la balise complexContent ne peut contenir qu’une seule fois la balise extension. Soit un objet T qui hérite des classes T1, T2, … , Tn , seul un des parents pourra être choisi comme base pour l’extension, les attributs des autres parents restants seront ajoutés dans sequence par des <element ref= > . Le concept de substitution permet d’utiliser TE en lieu et place de T, ainsi un conteneur de T peut contenir des T et des TE. Mais il est aussi intéressant de séparer TE du conteneur de T, cela signifie que TE possède son propre conteneur. Pour pouvoir encore maintenir que TE appartient à T, un xlink peut être introduit dans le conteneur de T. Cette idée est intéressante dans le cas de l’héritage multiple, au lieu de spécifier un des pères comme base de l’extension nous incorporons dans TE chaque type des pères (cela donne une séquence de <element ref= «élément père i »>) et dans le conteneur de chacun des objets pères nous incluons comme membres le xlink vers la partie importée du père correspondant dans l’élément TE.

6.9 Types de relation

Une association est une représentation d’un lien existant entre 2 objets dans le monde réel. Par exemple, plusieurs personnes peuvent suivre un cours tout comme une personne peut suivre plusieurs cours différents au cours de l’année. Nous allons analyser le cas des associations binaires ainsi que les n-aires. Pour celles-ci nous verrons le cas où l’association ne comprenant pas d’attributs, ainsi que le cas contraire.

69

6.9.1 Associations non porteuse d’informations

Binaire

La Figure 6.6 présente deux objets reliés par une relation Rel avec des rôles de cardinalités (1 :n). Ces rôles ne sont pas nommés. C’est un cas général.

Figure 6.6 Relation binaire non porteuse d’information

Un rôle sans nom de l’objet A à l’objet B est nommé A-Rel. S’il a un nom, le rôle sera nommé A-nomDuRole. Pour chaque objet, nous allons inclure dans ses attributs, le nom du rôle s’il existe ou dans le cas contraire, le nom de l’association plus le nom de l’objet à lier. Ainsi pour ce cas, l’attribut représentant le rôle de A vers B est A-Rel. Ce rôle doit référencer un ou plusieurs objets B. Mais nous ne pouvons pas inclure <element ref= "app:B"> dans l’objet A étant donné qu’il ne fait que reprendre/inclure/réimporter la définition de B c’est à dire <element name="B" type="b-Type">. Donc nous allons dupliquer l’information. Or seule la référence est vers la bonne instance. Pour résoudre ce problème, GML introduit le FeaturePropertyType qui consiste à lier des features à d’autres features. Deux manières sont proposées. On peut soit inclure directement l’élément référencé dans l’objet, soit utiliser l’AssociationAttributeGroup qui ajoute au rôle l’attribut xlink :href pour référencer l’objet. Bien qu’inclure l’objet lié directement est autorisé, seul les références avec l’attribut xlink :href seront utilisées. Une des principales raisons est que l’attribut xlink :href permet de référencer des objets en dehors du document, et ainsi de lier des documents GML et donc les features entre eux à travers Internet. Cela signifie aussi que même si les cardinalités des deux rôles permettent d’inclure l’un des objets dans l’autre, la décision prise au-dessus ne rend ce choix pas important. En effet, un moteur XLink doit savoir récupérer l’objet pointer et le réinclure comme s’il était local selon la définition que GML lui donne. <complexType name="FeaturePropertyType"> <sequence minOccurs="0"> <element ref="gml:_Feature"/> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> </complexType>

<element name="A-Rel" type="app:A-Rel-Type" substitutionGroup="featureProperty"/> <complexType name="A-Rel-Type"> <complexContent>

70

<extension base="gml:FeaturePropertyType"> </extension> </complexContent> </complexType>

Pour la relation binaire, chaque objet possède un lien (le nom du rôle) avec la référence vers les objets liés.

Relation n-aire

Figure 6.7 Relation ternaire non porteuse d’information

Pour une relation n-aire non porteuse d’information, la relation Rel est transformée en type d’objet Rel. Il sera composé d’attributs de type Role de cardinalités (1,1) vers A1, A2, …,An. Chaque objet A1, A2, …,An auront un lien vers l’objet Rel de cardinalité du rôle vers Rel.

6.9.1 Associations porteuse d’informations

Une relation peut être porteuse d’informations. Par exemple, une association qui lie un élève à un examen peut contenir une information sur les points que l’élève a obtenu. Dans le cas d’une relation porteuse d’informations binaire ou n-aire, la situation est identique à l’association n-aire non porteuse d’informations. La relation est transformée en objet et contient en plus des liens vers les objets participants, l’information qu’elle porte.

6.10 Représentation de la dimension temporelle

Les Instant et Intervalle de MADS ont leur équivalent en GML comme vu au chapitre GML : TimeInstant et TimePeriod (il est composé de 2 TimeInstants). Nous avons omis jusqu’à présent de ne discuter pas discuter des types temporels complexes. GML possède un type Bag mais il introduit une complexité inutile or nous pouvons utiliser minOccurs et maxOccurs. <element name="InstantBag" type="mads:InstantBagType" ____________________

substitutionGroup="mads:ComplexeTime" /> <complexType name="InstantBagType" final="#all"> <complexContent> <extension base=" AbstractComplexTimeType">

71

<sequence> <element name="instant" type="mads:InstantType" minOccurs="1" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType> <element name="IntervalBag" type="mads:IntervalBagType" ____________________ substitutionGroup="mads:ComplexeTime" /> <complexType name="IntervalBagType" final="#all"> <complexContent> <extension base=" AbstractComplexTimeType"> <sequence> <element name="interval" type="mads:IntervalType" minOccurs="1" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType>

Pour les variations dans le temps, GML fournit les types AbstractContinuousCoverageType et AbstractDiscreteCoverageType. Le domainSet de Coverage est défini comme temporel. GML avec dynamicFeature.xsd supporte aussi les objets spatio-temporels, des objets qui bougent dans le temps (ex : un avion) ou des objets fixes qui ont des propriétés qui changent dans le temps (le niveau d’eau d’un lac). Les cycles de vie sont modélisés à l’aide de la topologie temporelle de MADS. Les transitions entre les divers états des cycles de vie seront correctement modélisées.

6.11 Représentation de la dimension spatiale

Toute comme pour la temporalité, il faut traduire les types spatiaux dans leurs équivalents en GML. Point : Il est représenté par <Point> qui est de type gml :PointType. Line : Les lignes peuvent être représentées sous GML par plusieurs types ; dès lors un élément abstrait les représentent tous : <_Curve> de type gml :AbstractCurveType. Parmi les types qui dérivent de ce type abstrait, il y a <LineString> de type gml :LineStringType. Surface : De la même manière, tous les types de surfaces héritent sous GML de <_Surface> de type gml :AbstractSurfaceType. Parmi les surfaces, il y a <Polygon> de type gml :PolygonType. Un polygone est composé d’une limite extérieure et 0 ou plusieurs limites intérieures représentant les éventuels trous possibles.

72

OrientedLine : il est représenté par <OrientableCurve> de type gml :OrientableCurveType. Ce type comprend un élément découlant de <_Curve> et une orientation représentée par un signe soit +, soit -. Par défaut, l’orientation est +, ce qui indique que l’orientableCurve est identique à la _Curve inclus. Par contre, - indique que l’orientation est donné par l’inverse de la _Curve. SimpleSurface : Une surface ne possédant pas de trou peut être défini à partir du type gml :Polygon mais sans les limites intérieures. <xs:complexType name="SimpleSurfaceType"> <xs:complexContent> <xs:restriction base="gml:PolygonType"> <xs:sequence> <xs:element ref="exterior" minOccurs="1"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="SimpleSurface" type="SimpleSurfaceType" substitionGroup="gml:Polygon">

PointBag : Son equivalent dans GML est <MultiPoint> de type gml:MultiPointType. LineBag : Son equivalent dans GML est <MultiCurve> de type gml:MultiCurveType. SurfaceBag : Son equivalent dans GML est <MultiSurface> de type gml:MultiSurfaceType. OrientedLineBag : Pour créer ce type, nous partons de MultiCurve et le dérivons pour obtenir MultiOrientedLineBag mais avec comme contrainte qu’il ne puisse avoir que des membres de type OrientableCurve. <xs:complexType name="MultiOrientedLineType"> <xs:complexContent> <xs:restriction base="gml:MultiCurveType"> <xs:sequence> <xs:element ref="oCurveMember" minOccurs="0" _maxOccurs="unbounded" /> <xs:element ref="oCurveMembers" minOccurs="0" /> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="MultiOrientedLine" type="MultiOrientedLineType" substitionGroup="gml:MultiCurve"> <element name="oCurveMember" type="gml:OrientableCurvePropertyType"> <element name="oCurveMembers" type="gml:OrientableCurveArrayPropertyType">

<xs:complexType name="OrientableCurvePropertyType"> <xs:complexContent> <xs:restriction base="gml:CurvePropertyType"> <xs:sequence>

73

<xs:element ref="gml:OrientableCurve" minOccurs="0"/> </xs:sequence> <xs:attributeGroup ref="gml:AssociationAttributeGroup" /> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="OrientableCurveArayPropertyType"> <xs:complexContent> <xs:restriction base="gml:CurveArrayPropertyType"> <xs:sequence> <xs:element ref="gml:OrientableCurve" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType>

SimpleSurfaceBag : de façon similaire, simple surface sera représenté par un MultiSimpleSurface défini comme : <xs:complexType name="MultiSimpleSurfaceType"> <xs:complexContent> <xs:restriction base="gml:MultiSurfaceType"> <xs:sequence> <xs:element ref="simpleSurfaceMember" minOccurs="0" maxOccurs="unbounded" /> <xs:element ref="simpleSurfaceMembers" minOccurs="0" /> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:element name="MultiSimpleSurface" type="MultiSimpleSurfaceType" substitionGroup="gml:MultiSurface"> <element name="simpleSurfaceMember" type="gml:SimpleSurfacePropertyType"> <element name="simpleSurfaceMembers" type="gml:SimpleSurfaceArrayPropertyType">

Nous réutilisons SimpleSurface défini dans les types simples : <xs:complexType name="SimpleSurfacePropertyType"> <xs:complexContent> <xs:restriction base="gml:SurfacePropertyType"> <xs:sequence> <xs:element ref="SimpleSurface" minOccurs="0"/> </xs:sequence> <xs:attributeGroup ref="gml:AssociationAttributeGroup" /> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="SimpleSurfaceArayPropertyType"> <xs:complexContent> <xs:restriction base="gml:SurfaceArrayPropertyType">

74

<xs:sequence> <xs:element ref="SimpleSurface" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType>

Récapitulatif :

MADS GML

Geo AbstractGeometryType

SimpleGeo AbstractGeometryPrimitiveType

ComplexGeo MultiGeometryType

Point PointType

Line AbstractCurveType

Surface AbstractSurfaceType

OrientedLine OrientableCurveType

SimpleSurface Restriction sur PolygonType

PointBag MultiPointType

LineBag MultiCurveType

SurfaceBag MultiSurfaceType

OrientedLineBag Création de MultiOrientableCurveType

SimpleSurfaceBag Création de MultiSimpleSurfaceType

Figure 6.8 Tableau de correspondance

Pour les variations dans l’espace, GML fournit les types AbstractContinuousCoverageType et AbstractDiscreteCoverageType. Le domaine sera alors spatial.

6.12 Représentation de la dimension multi-représentation

Nous avons vu dans le chapitre MADS que la multi-représentation se sert de cachets pour associer une représentation à une perception. Pour résoudre le problème du passage au GML, je pars du but du projet MurMur ainsi que du problème de l’IGN. IGN a plusieurs bases de données géographiques à des résolutions différentes couvrant la France. Pour l’IGN, un des problèmes était la gestion des mises à jour car celles-ci doivent être répercutées sur toutes les cartes. Les bases de données ont été rassemblées en un schéma avec les cachets correspondants à chacune d’elles. MurMur a permis de pouvoir faire des interrogations au niveau conceptuel (langage d’interrogation de haut niveau) sur la nouvelle base. Pour créer la base, un processus d’extraction, de transformation et de chargement (ETL) a lieu. Un service WFS résoudrait en partie le problème parce qu’il supporte de nombreuses bases de données et parce qu’il supporte les transactions (ajout, suppression, mise à jour). Dès

75

lors, L’IGN ne doit pas rassembler ses bases de données en une seule. Seul un service WFS doit être rajouté. Le WFS utilise GML comme format de résultat et de transaction et CQL (Catalog Query Language) pour le filtrage des features à envoyer. L’idée proposée est d’utiliser MADS comme système fédérateur. Au niveau des schémas conceptuels, chaque cachet est associé à une base de données. Au niveau des requêtes, les cachets sont déjà supportés par l’éditeur de requête. Un travail est nécessaire par le traducteur de requête pour scinder la requête en sous-requêtes pour les services WFS. La scission se fera sur base du cachet. Lorsque les cotés d’une jointure sont répartis sur deux services, les sous-requêtes récupèrent les éléments et c’est à l’interrogateur de faire le travail. Le problème montre tout l’intérêt de devoir scinder un schéma GML applicatif en de nombreux autres schémas GML : Il faut un schéma par représentation ou encore une par serveur WFS. Chaque système reste indépendant des autres. Et chaque système peut toujours connaitre l’évolution des schémas en demandant l’information au WFS. L’autre idée est de garder toutes les représentations en un endroit. Dans le modèle conceptuel, un utilisateur met des cachets sur des objets, des attributs, des relations etc. De la même manière, l’idée serait d’ajouter un attribut jouant le rôle du cachet pour chaque balise d’objets, d’attributs et de relations. Mais un lourd travail ETL11 doit être fait pour réunir toutes les données identiques dans un même document XML. La maintenance pose aussi problème car le système d’insertion doit prendre en compte les cachets et bien associer les données. Avec la fédération au travers de WFS, les schémas sont récupérés et peut être retransformés vers l’éditeur de schéma. Une personne peut utiliser n’importe quel système WFS disponible, importer les schémas, faire correspondre les features voulus et commencer à faire des requêtes. La personne ne doit plus se préoccuper de scinder elle-même ces requêtes vers le bon service WFS.

11

Extract-Transform-Load : Data dumping

76

Chapitre 7. Conclusion

L’objectif de ce mémoire était de concevoir une extension au traducteur de la chaine d’outils MADS. En plus des traductions vers les modèles relationnels déjà existants (Oracle8i et Oracle9i), une traduction vers GML a été envisagée. Pour arriver à réaliser cette traduction, il a d’abord fallu comprendre les concepts du modèle MADS expliqués au Chapitre 2. Ce modèle très puissant et complet est destiné à faciliter le travail de conception de l’utilisateur notamment par l’orthogonalité des différentes dimensions. MADS permet de ne plus se préoccuper de la création des schémas au niveau logique cible, par exemple pour Oracle8i, Oracle9i ou ArcView. Ce modèle cache l’implémentation au niveau logique. Pour cela, il propose en plus d’un éditeur visuel de schéma, un éditeur visuel de requête. Ce dernier se charge de transformer une requête au niveau conceptuel en une requête qui peut être comprise par la cible au niveau logique. Ces outils jouent un rôle important et font partie intégrale du modèle. GML est devenu le standard pour l’échange d’information géographique notamment grâce aux services web WMS et WFS. Il est en pleine expansion grâce à l’effort de l’Open Geospatial Consortium (OGC) mais aussi grâce à son adoption massive par de nombreuses sociétés spécialisées. GML couvre tous les besoins pour la modélisation de l’information géographique. Mais sa complexité est l’un des ces points faibles. Pour y remédier, l’OGC a introduit un profil simplifié de GML. C’est ce profil qui est utilisé dans les serveurs fournissant un service WFS. Pour permettre la traduction, une correspondance entre les concepts de MADS et les concepts du modèle GML a été effectuée. Certains concepts de MADS sont cependant absents du modèle GML. Notamment au niveau temporel. Outre cela, certaines limitations proviennent de XML Schéma. La solution fut de remplacer les concepts manquants par plusieurs sous-concepts existants dans GML. A la fin de la traduction, un schéma applicatif GML est produit. Plusieurs études pour la création visuelle de ce type de schéma ont déjà été réalisées comme vue à la section 6.2. Dans le cas de l’étude « UML-to-GML », il faut que l’utilisateur connaisse les types ISO pour l’information géographique, ce qui est fort contraignant. Aucune des études réalisés jusque là ne fournit la puissance et l’expressivité de MADS. Mon mémoire a porté sur la création d’un outil de traduction de MADS vers GML. La disponibilité d’un tel outil devra permettre d’augmenter la visibilité de MADS auprès de la communauté SIG.

77

7.1 Travaux futurs

Une fois le schéma applicatif GML obtenu, il pourra être utilisé à diverses étapes de la vie de l’information géographique. De sa création à son stockage en passant par les requêtes et l’analyse de celles-ci. La grande force du modèle GML est de pouvoir profiter des nombreux outils disponibles pour son cousin XML.

7.1.1 GML et la création et visualisation de données

À partir du schéma applicatif GML, il est envisageable de créer un formulaire d’entrée couplé avec le logiciel open source JUMP Unified Mapping Plateform Workbench [JUMP], un framework pour la création, la manipulation ainsi que le visionnage d’information géographique. Ce framework a la particularité de reprendre un design similaire aux outils commerciaux (Figure 7.1).

Figure 7.1 Design de l'interface proche des outils commerciaux.

7.1.2 GML et le stockage de donnée

GML permet de modéliser les concepts spatio-temporels de MADS. Reste qu’il ne gère pas la préservation sémantique de bon nombre de concepts. Or les bases de données XML natives implémentant et utilisant XQuery [W3C:XQuery] comme langage d’interrogation permettent d’utiliser ses propres fonctions dans la requête. XQuery permet par exemple

78

d’invoquer des fonctions écrites en Java. Ainsi à titre de test, j’ai réalisé l’intégration de la libraire open source JTS Topology suite12 de Vivid solutions dans eXist-db13, qui est une base de données XML utilisant XQuery. EXist-db supporte grâce à cela les opérations sur les types géométriques et les types temporels. L’implémentation de ces fonctions ne veut pas dire pour autant que la base de données est spatio-temporelle. Toute la structure logique interne du schéma conceptuel de l’utilisateur est exposée. En effet, l’utilisateur doit connaître le schéma applicatif GML équivalent pour faire ses requêtes. Une façon de ne pas exposer la structure est de créer des fonctions additionnelles dans XQuery qui vont maintenir automatiquement les structures internes en GML représentant des concepts MADS. De la même façon que les requêtes en algèbre MADS ont été traduites vers le modèle relationnel ou encore le modèle OO [ZimMin2006], l’algèbre MADS doit être traduite vers le langage d’interrogation de XQuery.

7.1.3 Fédération WFS au travers de MADS

La fédération WFS au travers de MADS a été proposée au chapitre précédent pour résoudre le choix de la gestion de la multi-représentation. L’idée est qu’à partir de l’éditeur de schéma, un utilisateur puisse importer les schémas des features servis par un ou plusieurs serveurs WFS. Pour cela, un traducteur du modèle GML vers le modèle MADS devra être crée. Une fois le schéma GML synthétisé vers le modèle MADS, l’utilisateur pourra effectuer une requête sur des features de provenances diverses. L’outil scindera la requête en plusieurs sous-requêtes qui seront envoyé aux serveurs WFS. Plusieurs études ont été faites à ce sujet [Boucelma2003, Essid2004]. Il y a donc encore de nombreuses pistes de recherches possibles.

12

http://www.vividsolutions.com/jts/jtshome.htm 13

http://exist.sourceforge.net/

79

Bibliographique

[Balley 02] Vers la représentation multiple : le projet MurMur, BI n°73 Bilan de la Recherche

2001, pp. 61-74, France, IGN 2002 [Berron07] Julien Berron, Développement d'une application de webmapping

MapServer/PostGIS, Université d'Avignon et des Pays de Vaucluse, 2007. [Boucelma2003] Boucelma, O., Garinet, J., and Lacroix, Z. 2003. The virGIS WFS-based spatial mediation system. In Proceedings of the Twelfth international Conference on

information and Knowledge Management (New Orleans, LA, USA, November 03 - 08, 2003). CIKM '03. ACM, New York, NY, 370-374 [COB 02] Cobalt : Conception de Bases de Données Localisées Temporelles, Rapport final INTEREG II, Laboratoire THEMA, Université de Franche-Comté,Besançon et EPFL-LBD, Lausanne, Mars 2002. [Deb2003] E. Debois. Interrogation de bases de données spatio-temporelles : Conception

d'un outil de visualisation des réponses aux requêtes. Mémoire d'Ingénieur Civil en Informatique, Université Libre de Bruxelles, Brussels, Belgium, 2003. [Essid2004] Essid, M., Boucelma, O., Colonna, F., and Lassoued, Y. 2004. Query processing in a geographic mediation system. In Proceedings of the 12th Annual ACM international

Workshop on Geographic information Systems (Washington DC, USA, November 12 - 13, 2004). GIS '04. ACM, New York, NY, 101-108. [FICCDC 1988] The proposed standard for digital cartographic data, The American

Cartographer, Vol 15(1). [JUMP] http://openjump.org/wiki/show/HomePage [MinZim2004] M. Minout and E. Zimányi. A Tool for Transforming Conceptual Schemas of Spatio-Temporal Databases with Multiple Representations. In Proc. of the IASTED Int. Conf.

on Database Applications, DBA'2004, pages 1-6, Innsbruck, Austria, February 2004. IASTED/ACTA Press. [MUR 02] http://lbd.epfl.ch/e/MurMur, répertoire contenant toutes les documentations produites au cours du projet MurMur. [ParSpaZim2006] C. Parent, S. Spaccapietra, and E. Zimányi. Conceptual Modeling for

Traditional and Spatio-Temporal Applications: The MADS Approach. Springer-Verlag, 2006. ISBN : 978-3-540-30153-0.

80

[ParZimMinAis2002] C. Parent, E. Zimányi, M. Minout, and A. Aissaoui. Implantation d'un

modèle conceptuel avec multi-représentation. In A. Ruas, editor, Traité IGAT sur la représentation multiple et la généralisation, chapter 7, pages 131-147. Hermès, 2002. [REPRESENTATION] http://www.ifremer.fr/drogm/Realisation/Vulgar/SIG/SIG.htm [Souleymane 03] T. Souleymane, M.H. De Sède-Marceau, C. Parent, COBALT: A Design Tool for Geographic and Temporal Data Application. In Proceedings of the 6th AGILE Conference, pp.333-343, PPUR, 2003. [UML2GML 02] Roy Grønmo, Ida Solheim, David Skogan. Experiences of UML-to-GML

Encoding. The 5th AGILE Conference on Geographic Information Science Palma, Mallorca, Spain, 2002. [VANGENOT 01] C. Vangenot : Multi-représentation dans les bases de données

géographiques, thèse de doctorat de l’École polytechnique fédérale de Lausanne, 2001. [VRML] http://www.web3d.org/x3d/vrml/ [W3C:DTD] Extensible Markup Language (XML) 1.0 (Fourth Edition), http://www.w3.org/TR/xml/ [W3C:SVG] Scalable Vector Graphics (SVG) 1.1 Specification, http://www.w3.org/TR/SVG/ [W3C:XLink] XML Linking Language (XLink) Version 1.0, http://www.w3.org/TR/xlink/ [W3C :XML] Extensible Markup Language (XML) 1.0 (Fourth Edition), http://www.w3.org/TR/xml/ [W3C:XPath] XML Path Language (XPath) Version 1.0, http://www.w3.org/TR/xpath [W3C:XPointer] XML Pointer Language (XPointer), http://www.w3.org/TR/xptr/ [W3C:XSD] XML Schema Part 0: Primer Second Edition, http://www.w3.org/TR/xmlschema-0/ [W3C:XSLT] XSL Transformations (XSLT) Version 1.0, http://www.w3.org/TR/xslt.html [W3C :XQuery] XQuery 1.0: An XML Query Language, http://www.w3.org/TR/xquery/ [X3D] http://www.web3d.org/x3d/specifications/x3d/ [ZimMin2006] E. Zimányi and M. Minout. Implementing Conceptual Spatio-Temporal Schemas in Object-Relational DBMSs. In Proc. of the On the Move to Meaningful Internet

81

Systems 2006: OTM Workshops, number 4278 in LNCS, pages 1648-1657, Montpellier, France, October 2006. Springer-Verlag.

82

Liste des figures

Figure 1.1 Les concepts spatio-temporels ............................................................................... 2

Figure 1.2. Les fonctionnalités d’un SIG ................................................................................... 3

Figure 1.3. Principe de l’architecture client-serveur ............................................................... 4

Figure 2.1 Les différentes couches de modélisation ............................................................... 9

Figure 2.2 Module de traduction d’un schéma conceptuel vers un schéma logique ........... 10

Figure 2.3 Différentes représentations du même rond-point dans des bases de données [Balley 02] ...................................................................................................................... 11

Figure 2.4 Exemple d’orthogonalité ...................................................................................... 12

Figure 2.5 Exemple de type d’objet et d’attributs ................................................................. 13

Figure 2.6 Personne (super-type) et ses sous-types ............................................................. 14

Figure 2.7 Rôles possibles ...................................................................................................... 15

Figure 2.8 Exemple d’association avec attribut .................................................................... 16

Figure 2.9 Une relation cyclique ............................................................................................ 16

Figure 2.10 Exemple de multi-association ............................................................................. 17

Figure 2.11 Exemple d’agrégation ......................................................................................... 17

Figure 2.12 Exemple de transition ........................................................................................ 18

Figure 2.13 Exemple de génération ...................................................................................... 18

Figure 2.14 Plusieurs terrains peuvent devenir plusieurs autres terrains ............................ 19

Figure 2.15 Vue continue et vue discrète du monde réel [REPRESENTATION] ..................... 20

Figure 2.16. Type de donnée spatiale de MADS .................................................................... 21

Figure 2.17. Types de relation topologique dans MADS ....................................................... 22

Figure 2.18. Domaines pour lesquels les opérateurs sont définis ......................................... 23

Figure 2.19. Type de donnée temporel de MADS ................................................................. 24

Figure 2.20. Transitions possibles entre les états d’un objet ................................................ 25

Figure 2.21. Types de relation de synchronisation dans MADS ............................................ 26

Figure 2.22 Multi-représentation d’un même type d’objet .................................................. 27

Figure 2.23 Utilisation des cachets (Stamps) ......................................................................... 27

Figure 2.24 Fusion de deux représentations de routes en un type d’objet avec des cachets........................................................................................................................................ 28

Figure 2.25 La relation de correspondance entre deux routes ............................................. 29

Figure 3.1. La suite d’outils MADS ......................................................................................... 30

Figure 3.2. GUI de l'éditeur de schéma.................................................................................. 33

Figure 3.3. Vue du fonctionnement interne de l'éditeur de schéma .................................... 32

Figure 3.4. GUI du constructeur de requête .......................................................................... 34

Figure 3.5. Vue du fonctionnement interne de l’éditeur de requête et de l’outil d’affichage de résultat de requête ................................................................................................... 35

Figure 3.6. GUI de l’outil d’affichage de résultat de requête ................................................ 36

Figure 4.1 : Code XML ............................................................................................................ 38

Figure 4.2 : Arbre de l'exemple .............................................................................................. 39

Figure 4.3 : Exemple de DTD .................................................................................................. 40

83

Figure 4.4 : Exemple de schéma XML .................................................................................... 41

Figure 4.5. DOM et SAX .......................................................................................................... 43

Figure 5.1. Cas d’utilisation possible ...................................................................................... 46

Figure 5.2. Définition d’un schéma applicatif ........................................................................ 47

Figure 5.3. Définition de la balise pays avec trois propriétés, dont une géographique ........ 48

Figure 5.4. Pays est une feature ............................................................................................ 48

Figure 5.5 Les relations en GML ............................................................................................ 49

Figure 5.6 Les cinq modules principaux de GML ................................................................... 50

Figure 5.7 La hiérarchie des types géométriques de GML telle que décrite par l’OGC ........ 52

Figure 5.8 La hiérarchie du temps ......................................................................................... 53

Figure 5.9 La fonction de distribution ................................................................................... 54

Figure 5.10 Les composants d’une couverture ...................................................................... 54

Figure 5.11 Les normes ISO sur lesquelles repose GML ........................................................ 55

Figure 5.12 Représentation graphique de l’exemple ............................................................ 56

Figure 6.1 Transformation du type Interval en un type groupant deux instants .................. 62

Figure 6.2 Transformation de la structure XML du schéma MADS ....................................... 63

Figure 6.3 Capture d'écran du traducteur de schéma ........................................................... 64

Figure 6.4 Représentation d’un type d’objet T en GML ........................................................ 65

Figure 6.5 Représentation d’un héritage en GML ................................................................. 68

Figure 6.6 Relation binaire non porteuse d’information ....................................................... 69

Figure 6.7 Relation ternaire non porteuse d’information ..................................................... 70

Figure 6.8 Tableau de correspondance ................................................................................. 74

Figure 7.1 Design de l'interface proche des outils commerciaux. ......................................... 77

-