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

De la modlisation spatio-temporelle vers GML

Phi Phi Wang

Mmoire prsent sous la direction du Professeur Esteban Zimnyi en vue de lobtention du grade de Licenci en Informatique Anne acadmique 20072008

MEMBRE DE LACADMIE UNIVERSITAIRE WALLONIE-BRUXELLES E T DU PLE UNIVERSITAIRE EUROPEN BRUXELLES WALLONIE

Remerciements

Je remercie toutes les personnes qui ont contribu de prs ou de loin ce travail. En particulier, je tiens exprimer ma gratitude Monsieur Zimnyi, Directeur de ce mmoire, pour ses conseils judicieux et pour son encadrement tout au long de lvolution 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 Decugnire, Geoffroy Cruxifix, Evelina Klopotowska, Prakash Fakun et Laurent Exteens pour leur soutien. Enfin, Je voudrais remercier ma mre et ma famille pour les encouragements quils mont prodigus tout au long de ce travail.

Tables des matires

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 donnes spatio-temporelles ...................................................... 3 1.3.2 Les bases de donnes 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 dobjet .................................................................................................... 12 2.5.2 Les attributs ....................................................................................................... 13 2.5.3 Les mthodes ..................................................................................................... 14 2.5.4 La gnralisation ................................................................................................ 14 2.5.5 Les types de relation .......................................................................................... 15 2.6 LA DIMENSION SPATIALE ............................................................................................... 19 2.6.1 Vue discrte........................................................................................................ 21 2.6.2 Variation dans lespace ...................................................................................... 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 DOUTILS MADS ........................................................................... 30 3.1 3.2 3.3 3.4 LA MODELISATION ....................................................................................................... 31 LINTERROGATION ....................................................................................................... 34 LA VISUALISATION ....................................................................................................... 36 REMARQUES .............................................................................................................. 36

CHAPITRE 4. XML ........................................................................................................... 38 4.1 4.2 4.3 4.4 4.5 4.6 4.7 INTRODUCTION ........................................................................................................... 38 EXEMPLE DE DOCUMENT XML ....................................................................................... 38 AVANTAGES DU XML................................................................................................... 39 DTD ET XML SCHEMA................................................................................................. 40 VALIDITE DUN DOCUMENT XML ................................................................................... 42 DECODAGE DUN DOCUMENT XML ................................................................................ 43 TECHNOLOGIES ASSOCIEES ............................................................................................ 44

CHAPITRE 5. GML ........................................................................................................... 45 5.1 CONTEXTE ................................................................................................................. 45 5.2 MOTIVATIONS ............................................................................................................ 45 5.3 DEFINITION DE LINFORMATION GEOGRAPHIQUE................................................................ 47 5.4 LE MODELE GML ........................................................................................................ 47 5.5 LES MODULES DE GML ................................................................................................ 50 5.5.1 Le cur GML ...................................................................................................... 50 5.5.2 La gomtrie ...................................................................................................... 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 LART .......................................................................................................... 59 6.3 MADS AU LIEU DE LUML............................................................................................ 61 6.4 TRADUCTION .............................................................................................................. 62 6.5 REGLE DE TRANSFORMATION ......................................................................................... 62 6.6 ARCHITECTURE DU TRADUCTEUR DE SCHEMA MADS.......................................................... 63 6.7 CONVERSION DUN SCHEMA MADS VERS UN SCHEMA GML ............................................... 65 6.8 REPRESENTATION DE LA DIMENSION THEMATIQUE ............................................................. 65 6.8.1 Type dobjet........................................................................................................ 65 6.8.2 Attributs ............................................................................................................. 66 6.8.3 Gnralisation .................................................................................................... 67 6.9 TYPES DE RELATION...................................................................................................... 68 6.9.1 Associations non porteuse dinformations......................................................... 69 6.9.1 Associations porteuse dinformations ................................................................ 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 cration et visualisation de donnes ................................................ 77 7.2.2 GML et le stockage de donne .......................................................................... 77 7.2.3 Fdration WFS au travers de MADS ................................................................. 78 BIBLIOGRAPHIQUE ........................................................................................................... 79 LISTE DES FIGURES ............................................................................................................ 82

Chapitre 1. Introduction
Initialement, les systmes permettant la manipulation d'informations gographiques ncessitaient de gros ordinateurs pour fonctionner et taient complexes et trs couteux. De fait, les Systmes d'Information Gographique (SIG) taient strictement rservs des spcialistes, en gnral des organisations militaires, gouvernementales ou scientifiques. Depuis peu, grce aux progrs technologiques de ces dernires annes, la gnralisation dInternet et la puissance croissante des machines de bureau, les SIG sont dsormais facilement accessibles, consultables et manipulables par le grand public. Les sites de recherche d'adresses, les sites d'itinraires 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 plante.

1.1 Dfinition
Bien quil nexiste pas de dfinition prcise dun SIG, la dfinition la plus largement accepte mane du comit fdral de coordination inter-agences pour la cartographie numrique [FICCDC 1988] : "Un systme d'information gographique est un systme informatique de matriels, de logiciels, et de processus conus pour permettre la collecte, la gestion, la manipulation, l'analyse, la modlisation et l'affichage de donnes rfrence spatiale afin de rsoudre des problmes complexes d'amnagement et de gestion."

1.2 Les informations spatio-temporelles

Les SIG travaillent sur de linformation gographique. Bien souvent, cette information volue. Linformation va diffrer au cours du temps et/ou dans lespace. Une information spatio-temporelle est une donne dont on a associ une proprit gographique (spatiale) et une proprit temporelle. Comme le montre la Figure 1.1, les concepts spatio-temporels combinent les concepts spatiaux et les concepts temporels.

Par exemple un cours deau est reprsent par une donne spatio-temporelle car son lit va changer au cours du temps. La composante temporelle du cours deau permet de garder un historique de lvolution au cours des annes pour une analyse dincidence future. Voil le principal intrt dune base de donnes spatio-temporelle.

Figure 1.1 Les concepts spatio-temporels

1.3 La gestion de donnes spatio-temporelles

Un SIG se concentre sur la gestion des donnes. La gestion comprend plusieurs phases : le processus de rflexion sur les besoins auxquels il faut rpondre (la modlisation), la capture des informations (la cration), le stockage et lanalyse de celles-ci. La modlisation permet de dfinir les entits gographiques dans le langage de la plateforme SIG cible. Une fois ralise, lutilisateur rentre les informations gographiques suivant le modle dfini. Celles-ci peuvent tre stockes dans une base de donnes. Lanalyse est faite avec le module dinterrogation de cette base. La Figure 1.2 reprend la relation des diffrentes oprations avec une base de donnes.

GESTION Dfinition Acquisition Maintenance Intgrit

ANALYSE Oprateur dinterrogations Logique

VISUALISATION Reprsentation Consultation Acquisition / Edition Selection

Interrogation Prdiction Acquisition et mise jour Visualisation Interrogation

Base de donnes

Figure 1.2. Les fonctionnalits dun SIG

1.3.1 Visualisation de donnes spatio-temporelles Le Web Mapping [Berron07] permet de diffuser des cartes en format image via un rseau. Cest un domaine en pleine expansion grce au dveloppement des solutions libres. Les informations cartographiques brutes ou les donnes spatiales sont ainsi consultables partir de postes clients. Elles sont en gnral stockes dans un systme de gestion de base de donnes (SGBD) sur un ou plusieurs serveurs et administrables de faon centralise. Le Web Mapping est donc important pour l'avenir des SIG. Grace lui lutilisation des SIG sera de plus en plus dmocratise. Lutilisateur accde au service par son navigateur internet. Un moteur cartographique tournant sur un serveur lui permet deffectuer un ensemble de manipulations sur les cartes (navigation, requtes, mais aussi mise jour distance). MapServer est le moteur cartographique le plus rpandu.

Figure 1.3. Principe de larchitecture client-serveur

Lutilisation de standards et de protocoles est indispensable afin que chaque utilisateur puisse utiliser le systme.

1.3.2 Les bases de donnes spatio-temporelles Une base de donnes permet le stockage de grandes quantits d'informations et en facilite l'exploitation par des oprations dajout, de suppression, de mise jour et de recherche. Dans une base de donnes spatiale, les informations gographiques sont reprsentes de deux faons : La premire est la reprsentation discrte. Dans celle-ci, un objet spatial est une donne vectorielle de type Point, Ligne ou Rgion par exemple. Lautre est la reprsentation continue (raster) de notre monde. On reprsente tout lespace par une grille (type Grille) o chaque cellule possde une valeur sur linformation reprsenter.

En plus de dfinir les types cits prcdemment, les bases de donnes spatiales permettent lutilisation de prdicats spatiaux pour leur interrogation. Des exemples dinterrogation possibles sont:
Est-ce que 2 routes se croisent ? Y a-t-il une intersection entre deux rgions ? Y-a-t-il une pompe essence a moins de 5 km de tel endroit ?

Les bases de donnes relationnelles comme Oracle, IBM DB2, PostGIS et MySQL possdent maintenant toutes une extension pour les informations gographiques. Malheureusement ces bases de donnes ne permettent pas de prendre en compte lvolution des donnes. Bien quelles permettent de stocker des donnes avec des attributs de type Date ou de type Timestamp , elles ne supportent pas les prdicats temporels permettant des oprations sur les intervalles de temps (intersection, union,). Cependant il est tout fait possible dintroduire une notion de temps dans les bases de donnes spatiales, elles sont alors qualifis de spatio-temporelles. Le temps peut intervenir deux niveaux : Au niveau de la base de donnes. En stockant le moment ou les donnes sont ajoutes, modifies ou supprimes. Cet intervalle de temps permet de retrouver ltat de la base de donnes un instant donn. Au niveau des donnes elles-mmes On peut reprsenter l'intervalle de temps pendant lequel l'information est valide.

Exemple : lvolution du trac d'un cours d'eau La dure de la transaction : Elle commence linstant o linformation est rajoute, lorsque le trac a t mis jour, et se termine lorsquon supprime cette information. Dure de validit : Cest la dure pendant laquelle linformation pour le trac du cours d'eau est valide.

1.4 Un modle conceptuel

Un des avantages de la modlisation conceptuelle est que son approche permet lutilisateur final de sabstraire de tout dtail technique lors de la modlisation. La comprhension intuitive du schma permet de faire participer au processus de dveloppement les utilisateurs du futur systme et donc la communication entre les diffrents acteurs est amliore. Un modle conceptuel est ds lors indpendant du niveau logique que reprsente une base de donnes par exemple. Le niveau logique pourra tre automatiquement pris en charge par un module de traduction du modle conceptuel. On peut dfinir des oprations comme la manipulation de donnes sur ce modle conceptuel. Ces oprations de haut niveau seront aussi traduites vers le modle logique sur lequel se trouvent les donnes.

1.5 GML
Le Geography Markup Language (GML) est un langage de balisage pour la gographie dfini par lOpen Geospatial Consortium (OGC). Bas sur XML, GML est utilis pour structurer linformation gographique de manire faciliter son partage sur Internet. La spcification GML comprend plus de 600 pages et des milliers de balises de noms dobjet. GML a t conu pour couvrir de nombreux besoins. Mais de par la taille de sa spcification, il est complexe utiliser. Il existe donc une forte barrire son adoption. Pour acclrer celle-ci, lOGC a cr des sous-ensembles simplifis de GML dont lun des plus connus est le profil GML Simple Feature . Des outils visuels existent pour la cration du code XML et des schmas XML. Une personne devra ds lors travailler au niveau des lments et des balises pour modliser les concepts thmatiques tels que les objets, les attributs et les relations comme vu dans lexemple cit au chapitre GML.

1.6 Objectifs et motivations

Lobjectif de ce mmoire de fin d tude est de complter la chane doutils pour le modle conceptuel MADS destin au domaine des bases de donnes spatio-temporelles. Le dpartement Computer & Decision Engineering (CoDE) de lULB en partenariat avec dautres universits ainsi que des entreprises publiques et prives ont cr, dans le cadre du projet MurMur [Mur 02], ce modle conceptuel MADS ainsi quune suite doutils associs. Ces outils permettent de modliser des concepts spatio-temporels, questionner les informations reprsentes par le schma en utilisant le modle conceptuel comme un outil visuel dinterrogation, ainsi quun outil permettant dafficher les rponses ces interrogations. GML est devenu le standard pour lchange dinformation gographique. Pour cette raison il a t choisi comme nouvelle cible logique pour le modle conceptuel MADS. Le but de ce mmoire est de : Introduire GML. Expliquer la correspondance entre MADS et GML. Complter la chane d'outils MADS en crant une extension au traducteur de schma. Augmenter le nombre d'utilisateur de MADS. Le but est d'amener plus de personnes l'utiliser et supporter sa suite d'outils.

1.7 Structure du mmoire

Voici le dcoupage du mmoire ainsi qu'un bref aperu :

Chapitre 2. Jy prsenterai le modle conceptuel de donnes spatio-temporelles MADS et ses concepts cls dont le principe d'orthogonalit qui allie la simplicit et le pouvoir d'expression pour modliser les quatre dimensions proposs par MADS : thmatique, temporelle, spatiale et multi-reprsentation. Ces quatre dimensions seront expliques dans ce chapitre. Chapitre 3. Dans ce chapitre je prsenterai la suite doutils MADS. Chapitre 4. Le chapitre 4 est consacr XML, qui est incontournable pour lchange dinformations de par sa simplicit, son expressivit et sa facilit de mise en uvre pour la modlisation et le stockage de donnes. Je prsenterai les lments de base d'un document XML. Chapitre 5. Je parlerai de GML, qui est le standard pour la modlisation, l'change et le stockage de l'information gographique. Dans ce chapitre, jexpliquerai les lments et concepts de base. Ensuite nous verrons un exemple des diffrents outils pour la cration de schma applicatif GML. Chapitre 6. Une des possibilits pour la cration de schma applicatif GML est d'utiliser l'diteur de schma de la suite d'outils MADS. Ds lors nous tudierons la correspondance entre les concepts MADS et GML dans ce chapitre.

Chapitre 2. Le modle conceptuel MADS

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

2.1 Contexte
Les SIG actuels ne proposent pas doutils pour la modlisation des donnes avance alors que les applications spatio-temporelles en ont besoin pour plusieurs raisons :
Les donnes spatio-temporelles sont plus compliques grer que les donnes traditionnelles

La technologie volue trs vite et les applications doivent souvent tre repenses pour de nouveaux systmes. Le cot important de lacquisition de nouvelles donnes pousse rutiliser des sources externes dinformations.

De plus, les modles de donnes supports par certains SIG sont des modles logiques pauvres bass sur le modle relationnel. Ces modles ne supportent pas la temporalit. Le but du projet MADS est de rsoudre ces problmes en offrant un modle de donne conceptuel avec le support de la spatialit et la temporalit ainsi quun ensemble doutils associs. MADS est labrviation de Modlisation dApplications Donnes Spatio-temporelles . Cest un projet commenc en 1995 par lEPFL en partenariat avec des socits et des universits. Il tait support par la CTI (Commission pour la Technologie et lInnovation). Le projet sest termin en 1997. Les premires spcifications du modle conceptuel MADS tait alors tablies. Limplmentation des outils MADS a ensuite t acheve en tant que partie du projet MurMur (Multi-Representations and Multiple Resolutions in Geographic Databases).

2.2 Le modle conceptuel

Un modle est dit conceptuel sil permet une correspondance directe entre le monde rel peru et sa reprsentation. e approche Un des avantages de la modlisation conceptuelle est que lapproche conceptuelle permet lutilisateur final de sabstraire de tout dtail technique lors de la modlisati modlisation. La comprhension intuitive du schma permet de faire participer au processus de dveloppement les utilisateurs du futur systme et donc la commu communication entre les diffrents acteurs est amliore amliore. Un modle conceptuel est ds lors indpendant du niveau logique que reprsente une niveau base de donnes par exemple. Le niveau logique pourra tre automatiquement pris en charge par un module de traduction du modle conceptuel vers diff diffrents modles logiques. On peut dfinir des oprations comme la manipulation de donnes sur ce modle conceptuel. Ces oprations de haut niveau seront aussi traduites vers le modle logique sur lequel se trouvent les donnes.

Niveau conceptuel Niveau logique Niveau physique

Description des concepts (ides ou entits reprsenter)

et leurs relations sous forme de schma graphique : MADS, UML, E-R , Enhanced E-R, ... Description dans le langage de dfinition de donnes d'une BD cible: table et colonnes, classes OO, tags XML, format propitaires,...

Description du point du vue du systme de fichiers (structure interne du fichier, rpertoire, partition, ....)

Figure 2.1 Les diffrentes couches de modlisation

Des modules de traductions doivent tre conus pour chaque systme avec lequel on veut pouvoir utiliser le modle conceptuel. Un travail de correspondance entre les concepts de MADS et les concepts proposs par le systme cible doit tre effectu s effectu.

Figure 2.2 Module de traduction dun schma conceptuel vers un schma logique

2.3 Vers la multi-reprsentation

Les bases de donnes permettent le stockage de donnes dcrivant des phnomnes rels. Dans notre cas nous allons nous intresser particulirement au stockage de donnes spatio-temporelles. La particularit des bases de donnes spatio-temporelles est leur communaut dutilisateurs potentiels large et varie, en attente doutils de modlisation propres leur environnement de travail. En effet des applications aussi diverses que la gestion des risques industriels (pollution, explosion, ) ou naturels (avalanche, sisme, inondation, ), la gestion de flottes de vhicules en temps rel, la gestion cadastrale, la ralisation de relev gographique ou encore la gestion dtudes go-sociologique, demandent des reprsentations multiples afin de modliser des phnomnes rels pour un environnement de travail spcifique. Ces reprsentations multiples peuvent entre autre se diffrencier par : linformation qui est stocke, le degr de prcision des donnes, la forme des donnes, leur structure, les contraintes sur la structure ou/et les donnes ou encore la forme sous laquelle les donnes sont affiches. Outre les diffrences smantiques entre les reprsentations, celles-ci peuvent galement se distinguer par la rsolution spatiale des donnes de la base de donnes et par lchelle utilise pour gnrer la carte go-temporelle. Cest afin de permettre la coexistence de ces diffrentes reprsentations simultanment sur une mme base de donnes, tout en prservant la cohrence des diffrents modles, que le projet MurMur a vu le jour. Le but du projet MurMur est dtendre les fonctionnalits courantes fournies par les logiciels commerciaux de gestion de donnes, pour supporter des schmas de

10

reprsentation plus flexibles, comme la coexistence de reprsentations multiples dun mme phnomne rel. En plus de fournir une plateforme commune de travail diffrentes communauts dutilisateurs, la reprsentation multiple peut offrir dautres avantages. Considrons par exemple la possibilit damliorer la gestion des donnes lors des mises jour par une propagation automatique des modifications dattributs communs au travers de chaque reprsentation du modle ou encore des possibilits damlioration des processus de vrification dintgrit des donnes en vrifiant les corrlations entre les diffrentes reprsentations. Linstitut gographique national franais (IGN), partenaire du projet MurMur, gre plusieurs bases de donnes gographiques [Balley 02]. Chacune delle tant destine un usage diffrent, elles sont conserves de faon disjointe. Cela rend difficile leur gestion et leur mise jour. LIGN voudrait donc combiner ces bases de donnes en une seule.

Figure 2.3 Diffrentes reprsentations du mme rond-point dans des bases de donnes [Balley 02]

En guise de solution, MurMur propose lextension dun modle conceptuel existant, dvelopp par les partenaires du projet : MADS. Ce modle de donnes permet de dcrire au niveau conceptuel des donnes spatio-temporelles sous trois dimensions. Le projet MurMur a t financ par la commission europenne dans le cadre du 5e Framework Programme qui a dur de janvier 2000 dcembre 2002. Suite cela, le projet a continu au fil des annes grce aux travaux de fin dtude du dpartement CoDe de lUniversit Libre de Bruxelles. Il a rassembl des partenaires industriels, acadmiques et publiques. Cette collaboration a permis de valider les ides et les outils ainsi crs. Voici les partenaires du projet : Star Informatics, fournisseur de systme dinformation gographique

11

Linstitut gographique national franais (IGNF), fournisseur de donnes gographiques LInstitut de recherche pour l'ingnierie de l'agriculture et de l'environnement CEMAGREF, des utilisateurs de donnes gographiques LEcole Polytechnique Fdrale de Lausanne (EPFL) LUniversit de Lausanne (UNIL) LUniversit Libre de Bruxelles (ULB)

2.4 Orthogonalit des dimensions

Pour faciliter la tche des utilisateurs, les concepteurs de MADS et de MurMur ont adopt une perspective orthogonale entre les quatre dimensions suivantes : thmatique, spatiale, temporelle et multi reprsentation. Ceci permet de donner un pouvoir dexpression maximal lutilisateur. Lorthogonalit permet de dcomposer les problmes, et ainsi de grer chaque dimension une une, indpendamment des autres. Chacune des dimensions peut tre applique 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 dobjet spatial ou un attribut spatial.

Figure 2.4 Exemple dorthogonalit

Voici les quatre dimensions du modle MADS :

2.5 La Dimension thmatique

La dimension thmatique de MADS reprend les concepts des bases de donnes orientobjet. 2.5.1 Le type dobjet Un type dobjet a pour but de modliser la reprsentation dune entit du monde rel. Il dfinit un ensemble dentits ayant un comportement et une structure similaires. La structure est dfinie par les attributs et le comportement par les mthodes. Un type dobjet est proche du concept de classe. Les attributs sont les proprits dune classe et les mthodes sont les oprations pouvant tre effectues sur cette classe. Les objets ou

12

instances du type dobjet sont uniques et identifiables par leur Object Identifier (oid). Un type dobjet peut tre reli un autre type dobjet (gnralisation) ou une relation. Il peut tre spatial ou temporel. Par exemple, la Figure 2.5 a) montre une Rue dfinie comme un type dobjet et la figure b) montre Rue comme un type spatial dfini par une ligne.

a)

Type dobjet Rue

b) Rue est une

ligne

c)

Nom est un attribut simple monovalu

d) Une rue possde des pompes essence

Figure 2.5 Exemple de type dobjet et dattributs

2.5.2 Les attributs Un attribut peut tre de deux types : simple : sil contient une valeur dun type de base fourni par le modle complexe : sil est compos dun ensemble dattributs simples ou complexes

Chaque attribut doit avoir un nom, un type et une cardinalit. La cardinalit dun attribut donne le nombre de valeurs que peut comporter lattribut. Un attribut est dit : monovalu : si lattribut ne peut comporter quune seule valeur. multivalu : si lattribut possde plusieurs valeurs. Ces valeurs doivent tre groupes soit dans un ensemble non ordonn dans lequel les valeurs ne peuvent apparatre deux fois (set), soit dans un groupe non ordonn dans lequel une mme valeur peut apparaitre plusieurs fois (bag), soit dans une liste si les valeurs doivent rester ordonnes suivant un critre (list).

Exemple : la Figure 2.5 c), une Rue possde un nom et optionnellement un code. la Figure 2.5 d), une Rue possde un nom (ex : chausse de Waterloo) et une liste de pompes essences situ sur son trac (reprsent par une ligne). Une pompe essence possde un numro de rue et le nom de la socit qui la gre. Cette liste sera ordonne par ordre de numro de rue croissant.

13

La valeur de lattribut appartient au domaine du type de donne avec lequel il est associ. MADS reprend les types les plus rpandus comme: entier, nombre rel, nombre flottant, caractre, chane de caractre, boolen et date. MADS permet de restreindre le domaine de ces types basiques. De nouveaux types sont dfinissables avec comme domaine, un intervalle sur un des types basiques. MADS supporte aussi la dfinition dnumrations et de types personnaliss (user-defined). Un attribut possde une valeur qui est calcule par le systme suivant la formule de drivation fournie lors de sa description.

2.5.3 Les mthodes Comme pour les classes en orient-objet, les mthodes ajoutent des oprations au type dobjet. Une mthode est dfinie 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 dfinir la signature dune mthode mais ne permet pas de dfinir son corps. Une description textuelle suivra donc la signature pour expliquer la nature de lopration.

2.5.4 La gnralisation Un lien de gnralisation (Is-A link) lie un type dobjet un autre type dobjet. Il spcifique que lobjet fils (sous-type) hrite des caractristiques (les attributs, les mthodes et les rles) de lobjet pre (super-type). Il hrite aussi des proprits spatiales, temporelles et de multi-reprsentation du pre.

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

Exemple : la Figure 2.6, le type dobjet Personne a 2 catgories (cluster) de sous-types. La premire catgorie regroupe Etudiant, Employ et retrait. Le type dobjet Malade

14

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 dun mme objet dans les sous-types. Cest exprim par le lien de chevauchement (overlapping link). Une contrainte dinclusion de population existe sur un lien de gnralisation. Cette contrainte assure que chaque objet appartenant un sous-type est aussi instanci dans le super-type. Lhritage permet donc de substituer le pre par le fils tant donn que le fils possde les informations du pre. Tout comme dans la programmation oriente objet, lhritage permet aussi de raffiner ou de redfinir les caractristiques du pre. Le raffinement permet de restreindre le domaine des dfinitions hrites. La redfinition (la surcharge) a pour principe de garder la dfinition du pre (pour pouvoir garder le principe de substitution) et de crer une dfinition propre au fils. Le choix de la bonne dfinition sera fait dynamiquement suivant le type. Le multi-hritage est aussi support. Les conflits (deux mmes proprits dans chacun des pres) sont rsolus en prfixant les proprits hrits par le nom du pre (super-type). Par le principe dorthogonalit, un lien de gnralisation sapplique aussi sur les types dassociations (relations). La gnralisation contribue ainsi crer plusieurs reprsentations dune mme 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 rle de la relation. Il doit contenir une cardinalit et peut tre nomm. Une relation est dite de type n-aire si le nombre de rles est plus grand que un. Chaque rle a une paire de nombres donnant le nombre minimum et maximum de liens entre lobjet et la relation. Un rle multivalu ne peut tre que de type set ou de type list. La Figure 2.7 donne la notation des diffrents rles possibles.

Figure 2.7 Rles possibles

15

Figure 2.8 Exemple dassociation avec attribut

Une relation peut comporter des caractristiques comme des attributs, des mthodes, et des informations sur la spatialit et la temporalit. Exemple : La Figure 2.8, la relation se situe dans porte un attribut numro . Une rue peut contenir zro ou plusieurs maisons. Une maison par contre, doit ncessairement se situer dans une rue. Si la relation porte sur un seul et mme type dobjet, elle est dite cyclique. Dans ce cas, les rles doivent tre nomms afin de pouvoir les diffrencier. En dehors de ce cas particulier, il est optionnel de nommer les rles.

Figure 2.9 Une relation cyclique

Afin de pouvoir distinguer deux instances de la relation liant deux fois les mmes 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 manire de les identifier univoquement est de rajouter chaque instance, un identifiant. Le type de relation le plus frquent est lassociation. Elle lie un objet un autre. Un autre type de relation est la multi-association. Cette relation lie un ensemble dobjets un autre ensemble dobjets. Chaque rle possde deux paires de cardinalits. La premire (proche de lobjet) dfinit le nombre de fois auquel lobjet participe une association. La deuxime dfinit pour chaque instance de la relation, le nombre dobjet quelle peut lier.

16

Figure 2.10 Exemple de multi-association

Exemple : la Figure 2.10, certains objets ne sont jamais changs contre des services, et certains services ne sont pas rendus contre des objets. Sil y a un change, il y aura au moins un objet chang contre un service. Il est tout fait possible davoir un change o trois objets sont changs contre deux services. Lagrgation permet dorganiser les objets en hirarchies. Un objet A est compos de plusieurs objets B, et un objet B est un composant de plusieurs objets A. La relation est reprsente par un losange et ses rles sont nomms isComposedOf et isComponentOf. Lagrgation ne peut sappliquer qu une relation binaire.

Figure 2.11 Exemple dagrgation

La transition permet de garder une trace de lvolution des objets dans la base de donnes. Elle permet de savoir comment ils naissent et disparaissent. Ses rles sont nomms isSource et isTarget. Ils indiquent la direction de lvolution. Une transition traque lvolution dun objet grce son id.

17

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 dtudiant. Si un employ doit obligatoirement avoir t un tudiant, le lien isTarget ne sera plus (0 ,1) mais (1,1). La gnration garde linformation sur la cration dentits dun type de donnes depuis dautres entits de types identiques ou diffrents. La gnration est applicable sur une relation n-aire. Plusieurs objets peuvent tre la source dun autre objet, et plusieurs objets peuvent tre gnrs par une seule source.

Figure 2.13 Exemple de gnration

La gnration est utilisable avec une multi-association. Cela signifie quun ensemble donn dobjets gnre un autre ensemble dobjets.

18

Figure 2.14 Plusieurs terrains peuvent devenir plusieurs autres terrains

2.6 La dimension spatiale

Dans MADS, la spatialit sapplique de manire orthogonale aux structures de donnes thmatiques. Elle peut sappliquer aux types dobjets, aux relations et aux attributs. La spatialit coexiste avec la temporalit au niveau de lobjet et un objet peut tre spatial et/ou temporel. Comme vu la Section Erreur ! Source du renvoi introuvable., il y a deux manires de eprsenter linformation gographique (voir Figure 2.15 ) : la reprsentation vectorielle et la reprsentation raster . La reprsentation vectorielle consiste modliser lespace au travers dobjets (route, rivire, maison,). On dit que cest une reprsentation discrte de notre monde car lespace vide nest pas modlis. La reprsentation raster considre lespace comme un champ continu. Lespace est subdivis par une grille o chaque cellule contient une valeur. Une application SIG peut combiner la fois des informations en vue discrte et des informations en vue continue. Exemple : Une application va modliser les maisons et les routes en vue discrte, leur donnant une forme gographique prcise et modliser la temprature et laltitude avec vue continue. Une question laquelle lapplication pourrait rpondre est : Quelles sont les maisons situes sur une pente de plus de 10% ?

19

Vue continue

Vue discrte

Monde rel

Figure 2.15 Vue continue et vue discrte du monde rel [REPRESENTATION]

20

2.6.1 Vue discrte Dans la vue discrte, diffrents types de donnes reprsentent la spatialit. Ils sont organiss sous forme hirarchique. Il y a dun ct les types de donnes simples et de lautre les types de donnes complexes. Ces 2 groupes sont issus du type abstrait gnrique Geo . Les types Simple Geo et Complex Geo sont eux aussi des types abstraits gnriques. Dans les types simples, on trouve les points, les lignes (orientes ou non) et les surfaces. Une surface est une rgion qui peut ventuellement possder un trou son intrieur. Ces types donnent une reprsentation de lemprise (la forme associe llment dfini comme spatial) et de la localisation laide de coordonnes dans lespace.

Figure 2.16. Type de donne spatiale de MADS

Chaque type de donne spatial possde des attributs (mtadonnes) tel que le systme de projection utilis, la prcision numrique des coordonnes, la prcision de la mesure, la date de la mesure et la qualit. Chaque type de donnes spatiales possde aussi des mthodes pour le manipuler. Lorsque la spatialit est applique sur un type dobjet ou un type de relation, un attribut systme geometry lui est ajout. Cet attribut de type spatial prendra la valeur du type dfini pour lobjet. Les types de relation peuvent aussi possder une dimension spatiale. Elles peuvent tre soit des relations dagrgation spatiale, soit des relations topologiques. Ces relations dagrgations fonctionnent comme vu la section 2.5.5. Une relation qui lie deux objets

21

spatiaux de faon hirarchique (par ex. un pays contient des rgions) permet de driver les attributs du pays partir des informations des rgions : pays.surface = union(rgions.surface) pays.superficie = somme(rgions.surperficie) Les relations topologiques quand elles, dfinissent des relations sur deux types dobjets spatiaux et spcifient des contraintes topologiques sur les objets lis. Les relations topologiques fonctionnent de deux manires : Manuelle : les instances de la relation doivent tre insres par lutilisateur et le systme vrifie la contrainte spatiale entre les deux objets. Si elle est vrifie, la relation sera garde. Sinon elle sera rejete. Automatique : les instances de la relation seront automatiquement ajoutes par le systme pour chaque couple dobjets O1 et O2 tant en relation. On dira alors quelle est drive.

Type doprateur TopoDisjoint

Icone

Dfinition 2 gomtries satisfont cette contrainte si elles nont aucuns points en commun. 2 gomtries satisfont cette contrainte si tous les points dune gomtrie se trouvent dans lautre. 1 gomtrie satisfait cette contrainte si tous ses points sont contenus dans une autre et que ces gomtries ne sont pas TopoEqual. 2 gomtries satisfont cette contrainte si leurs bords ont des points en communs. 2 gomtries satisfont cette contrainte si leur intrieur partage certains points communs et si la dimension de lintersection est infrieure celle de lune des gomtries. 2 gomtries satisfont cette contrainte si elles ont la mme dimension, que leur intersection est de mme dimension que la leur et que les contraintes TopoEqual ou TopoWithin sont fausse. Cette icne permet de dfinir une contrainte personnalise ou une contrainte gnrique entre 2 gomtries.

TopoEqual

TopoWithin

TopoTouch

TopoCross

TopoOverlap

TopoGeneric

Figure 2.17. Types de relation topologique dans MADS

22

La spatialit fournit une relation spcifiant une contrainte topologique entre les 2 entits spatiales quelle relie. Ces contraintes sont donnes dans la Figure 2.17.

domaines oprateurs TopoDisjoint TopoTouch TopoCross TopoOverlap TopoWithin TopoEqual

Surface x Surface

Ligne x Ligne

Point x Point

Surface x Ligne

Figure 2.18. Domaines pour lesquels les oprateurs sont dfinis

2.6.2 Variation dans lespace Un objet, un attribut ou une relation peuvent varier dans lespace. Ils sont alors dnots par f( ) sils sont de type gnrique go. Pour les autres types, go sera remplac par licne 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 dfinissables : 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.

23

2.7 La dimension temporelle

Diffrents types reprsentent la temporalit. Ils sont eux aussi organiss sous forme hirarchique avec dun ct les types simples et de lautre les types complexes de type ensembliste bas sur des types simples. Le type Time est un type gnrique abstrait pour la temporalit. Il existe trois types temporels de base : linstant, lintervalle, et la dure (timespan).

Figure 2.19. Type de donne temporel de MADS

Ces types temporels sappliquent sur les types dobjets, les attributs et les types de relation. Les objets temporels et les relations temporelles doivent garder un historique de leur tat. On parle ds lors de leur cycle de vie. Il est reprsent 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 crer lobjet. Actif : lobjet est pour linstant actif et membre du type de lobjet. Suspendu : lobjet ne peut plus subir certaines oprations. Dsactiv : une fois lobjet dsactiv, il ne peut que rester dans cet tat. On ne peut plus le ractiver ou le suspendre. Seules les oprations de lecture ou suppression sont autorises.

Il existe un ordre sur la transition entre les diffrents tats (voir Figure 2.20) Chaque objet a comme obligation davoir au moins un tat.

24

Deux instants spciaux, la date de cration et la date de mort1, sont associs au cycle de vie.

Figure 2.20. Transitions possibles entre les tats dun objet

Soient 2 objets temporels A et B dfinis sur 2 intervalles de temps t1 et t2. t1 dbute linstant t1.dbut et se termine linstant t1.fin. t2 dbute linstant t2.dbut et se termine linstant t2.fin.
Type de synchronisation SyncPrecede Icone Dfinition A syncPrecede B si t1 se situe avant t2, c'est--dire si t1.fin est avant t2.dbut A SyncWithin B si t1 se situe dans t2, c'est--dire si t2.dbut est avant t1.dbut et t2.fin est aprs t1.fin. A et B satisfont cette contrainte si t1.dbut et t2.dbut sont gaux. A et B satisfont cette contrainte si t1.fin et t2.fin sont gaux A et B sont syncEqual si t1.dbut et t2.dbut sont gaux et si t1.fin et t2.fin sont gaux. Ils sont donc SyncEqual sils sont SyncStart et SyncFinish. A syncMeet B si t1.fin et t2.dbut sont gaux ou t1.dbut et t2.fin sont gaux. A syncOverlap B si t1.dbut est avant t2.dbut, t2.dbut est avant t1.fin et t1.fin est avant t2.fin. A et B sont syncDisjoint sils nont aucuns instants en communs c'est--dire que lintersection entre t1 et t2 est vide.

SyncWithin

SyncStart

SyncFinish SyncEqual

SyncMeet

SyncOverlap

syncDisjoint

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

25

SyncGeneric

Cette icne permet de dfinir une contrainte personnalise ou gnrique entre 2 objets temporels.

Figure 2.21. Types de relation de synchronisation dans MADS

Tout comme pour la spatialit, la temporalit fournit une relation spcifiant une contrainte sur les deux entits quelle relie. Les types de relation de synchronisation sont donns 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 dnots par f( ). Cest une fonction du temps vers le domaine de valeurs de l'attribut. Un historique (pass, prsent et futur) sera gard par la base de donnes. On dit quun objet, un attribut ou une relation est timestamped.

2.8 La dimension multi-reprsentation

La multi-reprsentation dsigne la possibilit daccder plusieurs reprsentations des phnomnes gographiques dans une seule base de donnes, ces diffrentes reprsentations tant lies entre elles pour bien spcifier quelles correspondent une mme entit du monde rel. Deux critres sont pris en compte lors de la comparaison de diffrentes reprsentations : le point de vue et la rsolution [VANGENOT 01]. Le point de vue matrialise lintrt spcifique de lutilisateur. Ce point de vue a men certains choix de contenu et de reprsentation, dont principalement le choix des types dobjets et de relations prsents dans la base de donnes, le choix des proprits intressantes pour dcrire ces types et le choix du mode de dfinition de ces proprits. La rsolution dfinit le niveau de dtail choisi, afin de ne retenir dans la base de donnes que les objets reconnus comme tant significatifs.

Il y a deux manires de combiner les reprsentations diffrentes dun mme type dobjet : La premire est de fusionner toutes les reprsentations dun mme type dobjet dans un seul objet. La deuxime est de sparer les reprsentations, de crer un type dobjet pour chaque reprsentation et de le relier avec une relation de correspondance.

26

b) Chaque reprsentation est un type dobjet avec un lien spcifiant quil reprsente un mme type dobjet. a) Fusion des reprsentations
Figure 2.22 Multi-reprsentation dun mme type dobjet

Pour associer la reprsentation sa perception, MADS utilise des cachets (stamps). Ils sont appliqus sur les types dobjets, les attributs, les relations, mais aussi sur les rles de la relation, et les proprits temporelles et spatiales de lobjet. La Figure 2.23 a) montre un schma avec trois perceptions et la figure b) montre quun utilisateur ne sintresse qu la perception jaune. La Figure 2.24 prsente les tapes dune fusion de deux objets.

a)

3 perceptions combines

b)

Une perception slectionne

Figure 2.23 Utilisation des cachets (Stamps)

27

Figure 2.24 Fusion de deux reprsentations de routes en un type dobjet avec des cachets

Exemple : Soient deux reprsentations de route (voir la Figure 2.24). La fusion des types dobjets en un seul objet se passe comme suit : Pour chaque reprsentation, on cre un cachet. Ici on doit crer les cachets s et t. Ces cachets seront appliqus la nouvelle reprsentation qui combinera les deux objets. Pour chaque attribut, si sa signature est identique la signature dun attribut de lautre reprsentation et que leur valeur est identique on rajoute cet attribut dans la nouvelle reprsentation les cachets des deux reprsentations. Par contre, si les attributs ont la mme signature mais que leur valeur est diffrente, il est ajout quen plus il varie selon la perception s et t. Lattribut nom est dans ce cas. Le nom diffre selon lautorit quil utilise. Lautre manire est de faire correspondre le mme type dobjet. La relation de correspondance remplit cette fonction. Encore ici, lorthogonalit de MADS permet de combiner une relation de correspondance avec une relation topologique (voir Figure 2.25) ou avec dautres relations.

28

Figure 2.25 La relation de correspondance entre deux routes

Dans la Figure 2.25, une contrainte topologique est applique sur les routes. Route1 doit tre lintrieur de Route2. (Une des route est reprsente par un polygone, lautre par une ligne)

2.9 Exemple de schma MADS

29

Chapitre 3. La suite doutils MADS

Dans le cadre de ce projet, plusieurs outils ont t crs. Ces outils dvelopps en Java, sont encore au stade de prototype. Ils ont t mis depuis peu sous licence libre2. Le but de cette dmarche est d'amener plus de personnes utiliser MADS et contribuer au dveloppement de la suite d'outils.

Figure 3.1. La suite doutils MADS

LGPL (GNU Lesser General Public License)

30

Les outils3 comprennent : un diteur de schma un diteur de requte un outil daffichage de rsultat de requte

Lditeur de schma ainsi que lditeur de requte sont organiss en plusieurs couches. Une premire couche, de haut niveau, interagit avec lutilisateur final, en laidant dfinir un schma ou des requtes, selon les critres du modle, un niveau conceptuel. Cette couche est par consquent la seule couche visible par lutilisateur. Une deuxime couche, de plus bas niveau, transforme un schma conceptuel MADS en un schma intermdiaire plus adapt une plateforme cible (SIG, SGBD), afin que la requte soit facilement implantable dans celle-ci. Une troisime couche utilise un wrapper afin de traduire le schma intermdiaire dans le langage DDL4/ DML5 de la plateforme cible. XML et GML sont utiliss pour faciliter linteroprabilit entre les diffrents outils. XML est utilis pour le stockage du schma conceptuel cr par lutilisateur. Tous les outils utilisent donc XML pour lire ou crire dans ce schma. GML est utilis pour spcifier la structure des rponses : cest le format de transport des rponses.

3.1 La modlisation
Lditeur de schma permet de raliser un schma conceptuel dans une GUI. Lorsque lutilisateur choisit une plateforme cible (SIG ou SGBD), lditeur traduit le schma en un niveau logique intelligible par la plateforme de son choix. Les plateformes cible pour lesquels les outils de translation existent dj sont Oracle9i, ArcView et MapInfo [Souleymane 03]. Le processus de transformation utilise un modle logique intermdiaire appel MADSLog. Lditeur de schma est compos de trois types de modules : Le constructeur de schma qui donne lutilisateur la possibilit de crer des schmas MADS. Il gre tant la structure du schma que ses proprits graphiques. Une fois le schma cltur il est sauvegard dans son format graphique et structurel.

3 4

Les outils MADS sont disponibles ladresse http://cs.ulb.ac.be/mads_tools/ DDL : Data Definition Language 5 DML : Data Modeling Language

31

Le traducteur de schma transforme le schma conceptuel en schma MADSLog, faisant abstraction de toute notion absente du modle de donnes cible. Le wrapper de schma transforme son tour le schma MADSLog adapt un schma logique SIG ou SGBD.

Figure 3.2. Vue du fonctionnement interne de l'diteur de schma

32

33
Figure 3.3. GUI de l'diteur de schma

3.2 Linterrogation
Lditeur de requte propose lutilisateur de spcifier une requte sans la ncessit de connatre un langage de requte textuel (SQL par exemple). La requte se fait directement sur le schma conceptuel. Ce mode de fonctionnement permet lutilisateur de se concentrer sur la smantique de sa requte plutt que sur la syntaxe de celle-ci.

Figure 3.4. GUI du constructeur de requte

Lditeur de requte est compos de cinq types de modules : Le Framework de lditeur de requte est linterface qui permet lutilisateur de grer ses requtes, et dinteragir avec le constructeur de requte et loutil daffichage de rsultat de requte.

34

Le constructeur de requte (Figure 3.4), dcrit la requte dans une expression MADS. Le traducteur de requte effectue le premier pas de la traduction de la requte en MADS vers une requte adapte au systme cible. Le wrapper de requte se charge de la seconde tape de la traduction en transformant lexpression fournie par le traducteur de requte en une requte adapte la cible SIG ou SGBD. Le wrapper de rponse rorganise les rsultats du systme cible en instances MADS conformes la requte originale effectue en MADS. Ce rsultat est fourni dans le format GML loutil daffichage de rsultat de requte.

Intraction visuelle

Editeur de requte et outil daffichage de requte

Framework de lditeur de requte Constructeur de requte Outil daffichage de rsultat de requte

expression algbrique MADS en XML

rsultat MADS en GML

Traducteur de requtes MADS

expression algbrique en XML pour une base de donne Oracle Wrapper Oracle Wrapper pour une autre plateforme

Wrapper de requte

Wrapper de rponse

rqute SQL

rsultat SQL

Oracle

SGBD
Figure 3.5. Vue du fonctionnement interne de lditeur de requte et de loutil daffichage de rsultat de requte

35

3.3 La visualisation
Loutil daffichage de rsultat de requte permet de visualiser les rsultats dune requte de manire intuitive et de naviguer (zoom, dplacement, affichage des proprits des lments, ) au travers de ceux-ci. Un wrapper de rponse est ncessaire afin de traduire le rsultat dune requte SQL en format GML pour le rendre comprhensible par loutil daffichage.

Figure 3.6. GUI de loutil daffichage de rsultat de requte

3.4 Remarques
Bien que la suite doutils permette la modlisation, linterrogation ainsi que la visualisation des donnes, elle ne propose pas de solution la manipulation (cration, mise jour et suppression) des donnes lintrieur de la base de donnes. Ainsi aprs avoir modlis le schma et traduit celui-ci vers la plateforme cible choisie, on devra passer par dautres outils pour extraire des donnes dautres systmes dinformation gographique, les transformer et remplir les structures logiques de la plateforme cible choisie. Lutilisateur

36

doit donc connatre le schma logique afin dtablir les correspondances avec le schma conceptuel pour placer les donnes au bon endroit. Le projet MurMur vise rsoudre un des problmes de fdration des bases de donnes gographiques. Il suppose que les utilisateurs possdent dj des donnes gographiques. Il manque actuellement des outils de cration et de manipulation de donnes. Mais avec la mise disposition en Open Source sous licence LGPL des outils du projet, nous esprons que les dveloppeurs seront attirs par la modlisation conceptuelle grce notamment aux nombreuses plateformes quelle supporte, telles que MapInfo, ArcView et Oracle. Depuis la fin officielle du projet MurMur, le nombre de plateforme SGBD supportant les donnes spatiales a considrablement 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 ralise lors du travail pour la transformation pour Oracle. Le support dautres bases de donnes relationnelles avec support spatial ne devrait donc pas poser trop de problme. Ce mmoire porte sur la conversion du modle conceptuel MADS vers les concepts GML et la cration dun outil permettant cette transformation au sein de lditeur de schma (plus exactement au niveau du translateur de schma ainsi que du wrapper). Cet outil doit donc crer un schma applicatif GML qui sera utilis par une base de donnes XML native.

37

Chapitre 4. XML
4.1 Introduction
XML (eXtensible Markup Language) [W3C:XML] est un langage de description de donnes. Cest un standard du W3C6 qui a pour but de faciliter le partage dinformation sur internet. XML utilise des balises afin de dfinir la structure et le contenu d'un fichier. Il permet galement de dcrire dautres langages en dfinissant de nouvelles balises. Cest donc un mtalangage. 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 dfinie et valide par un schma. Mais SGML est trs 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

World Wide Web Consortium

38

Figure 4.2 : Arbre de l'exemple

ligne 1 : cette ligne prcise que le document contient du XML en version 1.0 et indique le jeu de caractres utiliser. ligne 2 : une balise ouvrante dbute un lment appel listePays. Cest llment racine du document XML. ligne 4 : llment 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 llment listePays.

4.3 Avantages du XML

XML est : Structur : les documents XML doivent suivre une syntaxe stricte. Flexible : il est possible de dfinir 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 dinformation et assure la prennit de celles-ci.

39

4.4 DTD et XML Schema

Il est possible de vrifier la syntaxe dun document XML par lutilisation dune DTD (Document Type Definition) [W3C:XML] ou dun schma XML (XSD7) [W3C:XSD]. Tous deux dcrivent la structure des documents. La notion de DTD fait partie de la spcification XML. Une DTD peut tre dfinie sous forme interne, c'est--dire en lincluant dans le document vrifier, ou sous forme externe dans un autre fichier. Bien quil soit facile dcrire une DTD, il manque certaines possibilits telles que le typage des donnes. XSD est la pour rpondre ces dfauts. De plus, un schma XML est lui-mme un document XML, ce qui n'est pas le cas d'une DTD.

1. 2. 3. 4. 5. 6. 7. 8. 9.

<?xml version='1.0' encoding='UTF-8' ?> <!-- fichier pays.dtd --> <!ELEMENT listePays (pays+) > <!ELEMENT pays (nom,superficie) > <!ELEMENT nom (#PCDATA) > <!ELEMENT superficie (#PCDATA) > <!ATTLIST pays continent (Europe|Asie|Afrique|Amrique|Ocanie) #REQUIRED >
Figure 4.3 : Exemple de DTD

ligne 3 : une listePays est compose d'au moins un pays. ligne 4 : un pays est compos dun nom et dune superficie. ligne 5 : un nom est une donne textuelle. ligne 6 : continent est un attribut obligatoire de pays, qui a comme valeur possibles Europe, Asie, Afrique, Amrique et Ocanie.

1. 2. 3.
7

<?xml version="1.0" encoding="UTF-8" ?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

XSD : XML Schema Definition

40

4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36.

<xsd:element name="nom" type="xsd:string" /> <xsd:element name="superficie" type="xsd:positiveInteger" /> <xsd:element name="pays"> <xsd:complexType> <xsd:sequence> <xsd:element ref="nom" /> <xsd:element ref="superficie" /> </xsd:sequence> <xsd:attribute name="continent" use="required"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="Europe" /> <xsd:enumeration value="Asie" /> <xsd:enumeration value="Afrique" /> <xsd:enumeration value="Amrique" /> <xsd:enumeration value="Ocanie" /> </xsd:restriction> </xsd:simpleType> </xsd:attribute> </xsd:complexType> </xsd:element> <xsd:element name="listePays"> <xsd:complexType> <xsd:sequence> <xsd:element ref="pays" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>
Figure 4.4 : Exemple de schma XML

ligne 1 : comme dans tout document XML, cette ligne prcise que le document contient du XML et indique le jeu de caractres utiliser. ligne 3 : une balise ouvrante dbute le schma XML. Elle peut contenir la dfinition de l'espace de nom cible. ligne 5 : un lment est dclar grce la balise <xsd:element>. nom est du type xsd:string (type simple prdfini). Un type de donnes est associ chaque lment dclar. Les

41

lments pouvant contenir des sous-lments ou des attributs sont de type complexe. Les lments n'en contenant pas sont de type simple. ligne 6 : superficie est du type xsd:positiveInteger (type simple prdfini) ligne 9 : pays est du type complexType. Cest une squence (ligne 10) dlments nom et superficie. ligne 11 : la balise fait rfrence un nom, dfini prcdemment. ligne 14 : un lment attribute peut avoir plusieurs attributs optionnels. Ceux-ci permettent de paramtrer ce qui est acceptable ou non dans le document XML valider (attribut obligatoire ou optionnel, valeur par dfaut...). Par exemple, la ligne 14 permet de rendre l'attribut continent obligatoire. ligne 16 : on peut appliquer une drivation un type simple ou un type complexe. La drivation 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 crer lattribut continent, de type simple, et le limiter aux valeurs de lnumration qui suit. ligne 17 21 : lnumration des valeurs possibles pour lattribut continent. ligne 31 : un schma XML permet de dfinir le nombre doccurrence dun lment en utilisant les attributs minOccurs et maxOccurs, qui indiquent le nombre minimum et maximum de fois quun lment peut apparatre. Pour dclarer qu'un lment peut tre prsent un nombre de fois illimit, on utilise la valeur unbounded. Ici on peut donc rpter llment pays un nombre de fois illimit. ligne 36 : Fin du schma XML

4.5 Validit dun document XML

Voici les rgles gnrales de syntaxe du XML :

lentte est obligatoire. un document XML ne peut contenir quun seul lment racine. chaque balise douverture doit tre suivie dune balise de fermeture. Leur nom doit correspondre. les noms des lments sont sensibles la casse.

Si ces rgles sont respectes, le document XML est bien form . Le document XML est valide lorsquen plus dtre bien form, il suit les rgles dune DTD ou dun schma XML.

42

4.6 Dcodage dun document XML

XML permet de dfinir un format d'change et possde des outils pour vrifier la validit des documents. Il faut aussi pouvoir extraire les donnes des documents XML. Cela est ralis grce un outil appel parseur (ou encore analyseur syntaxique). Les parseurs XML sont diviss en deux catgories :
Ceux qui construisent un arbre (Figure 4.2) partir du document XML, en utilisant le modle DOM (Document Object Model). Chaque balise XML, appele

lment, sera un nud de cet arbre. DOM implmente des fonctions permettant de naviguer dans celui-ci. Cette approche est dite hirarchique Ceux qui sont bass sur un modle orient vnement (comme le dbut d'un lment, la fin d'un lment) comme SAX (Simple API for XML). Cette approche est dite vnementielle.

DOM utilise SAX pour la construction de larbre dun document XML.

DOM
Objet

Objet

Objet

Objet

Objet

SAX

Fichier XML

Figure 4.5. DOM et SAX

43

4.7 Technologies associes

Encodage et modlisation de donnes Slection & Pointeur Transformation

DTD, XSD XPath et XPointer XSLT XLink SVG, VRML, X3D

Lien et Association

Rendu graphique

DTD et XSD (XML Schema) ont t abords au point 4.4 de ce chapitre. [W3C : DTD] et [W3C:XSD] langages document XML. XPath et XPointer sont des langage permettant d'adresser les parties d'un docu [W3C:XPath] et [W3C:XPointer] XSLT (eXtensible Stylesheet Language Transformations) est un langage permettant de heet transformer un document XML vers un autre type de document. [W3C:XSLT] ML Xlink (XML Linking Language) est un langage pour dcrire les liens entre les documents XML. [W3C:XLink] SVG (Scalable Vector Graphics est un format de fichier standard pour reprsenter des Scalable Graphics) images vectorielles. [W3C:SVG] l VRML (Virtual Reality Modeling Language) et X3D (Extensible 3D) sont des formats de fichier standards pour reprsenter des univers tridimensionnels sur le web web. [VRML] et [X3D]

44

Chapitre 5. GML
Dans ce chapitre, je prsente 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 gographie dfini par lOpen Geospatial Consortium (OGC). Bas sur XML, GML est utilis pour structurer linformation gographique de manire faciliter son partage sur Internet. GML n'est pas le premier mtalangage utilis pour dcrire l'information gographique, mais il est le premier tre largement accept au sein de la communaut SIG. Dautres formats ont t conus afin de stocker et d'changer des informations spatiales et temporelles, mais il leur manque souvent des outils de rfrence et de validation. L'un des avantages de l'utilisation de GML est qu'il permet de tirer profit des outils destins XML. GML utilise ainsi les schmas XML, XLink et XPointer. Enfin, les donnes GML peuvent tre mlanges avec des donnes non spatiales.

5.2 Motivations
Linteroprabilit est le but principal de GML. Il y a un besoin grandissant de pouvoir combiner des donnes de diffrents systmes SIG situs divers endroits du globe, en rponse des vnements tels que des catastrophes ou pour des besoins dvaluation et de prdiction. Voici un exemple o les donnes gographiques ne sont pas centralises sur un seul systme : Des dpartements locaux modlisent chacun des informations dans leur systme SIG. Ensuite, dautres dpartements utilisent les informations de chacun de ces systmes pour raliser des analyses ou des prdictions au niveau global. Il faut donc que tous les dpartements saccordent sur le format dchange des donnes.

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

45

Figure 5.1. Cas dutilisation possible

Comme spcifi par lOGC, GML est destin : tre un langage pour dfinir linformation gographique. tre lisible et comprhensible par des humains. En sachant comment les donnes sont dfinies, il est facile de les importer dans son systme. lier les donnes de diffrentes bases de donnes gographiques entre elles, autorisant ainsi une maintenance locale et un accs global. tre facilement transformable, parce que les donnes gographiques sont maintenues longtemps aprs leur cration. Ds lors, il faut permettre la conversion vers dautres formats. servir dentre et de sortie pour les services web gographiques. tre non-propritaire et ouvert. Tout le monde peut prendre part au consortium et aux discussions sur le futur de GML, et peut lutiliser.

46

5.3 Dfinition de linformation gographique

partir de la version 3, GML est dfini par un Schma de dfinition XML (XSD) 9. GML rajoute ses propres structures et types XSD. Lutilisateur ralise un modle avec les structures et types de son choix. Cette tape sappelle la cration dun schma GML applicatif. Elle consiste modliser les objets et les relations en crant des balises spcifiques en XSD. Il existe des schmas GML applicatifs dj dfinis pour certains domaines. Il est prfrable que lutilisateur se base sur ces schmas afin de faciliter les changes de donnes.

Types prdfinis de Schma XML

Types principaux du Coeur de GML

Schma GML applicatif A

Schma GML applicatif B

Schma GML applicatif C

Figure 5.2. Dfinition dun schma applicatif

Mon travail automatise la cration du schma GML applicatif, pour autant quil existe une correspondance entre les concepts MADS utiliss et des concepts GML. Il consiste donc reprsenter correctement les concepts MADS laide des concepts GML quivalents ou dans le cas contraire, les reprsenter de faon proche. Une fois le schma GML applicatif cr, les donnes sont encodes suivant la structure quil dfinit. Le rsultat est un document GML.

5.4 Le modle GML

Le modle GML est proche du modle Entit-Relation. Les entits sont des features qui reprsentent des objets ou phnomnes qui peuvent avoir des proprits gographiques. Les relations sont modlises par les featureMembers et les Xlinks. . Mais il est tout fait
9

Dans la version 2, GML est dfini par une DTD.

47

possible dutiliser GML pour des domaines autres que linformation gographique pour gographique, profiter des constructions que ce lan r langage a dfinies. La reprsentation en GML dun objet est un lment XML. Les proprits de cet objet sont les lments fils de celui-ci. Une proprit est dite spatiale si sa vale est un objet ci. valeur gomtrique (un point, une ligne, ). Dans lexemple ci ssous, Pays est une feature et ci-dessous, elle possde trois proprits : nom, superficie et BoundedBy. Cette dernir reprsente la dernire boite qui englobe le pays.

Pays
nom

supeficie

BoundedBy

1. 2. 3. 4. 5. 6. 7. 8.

<element name = Pays type = PaysType /> <complexType name = PaysType > <sequence> <element name = nom type=string /> <element name = superficie type=double /> <element ref = gml:BoundedBy /> </sequence> </complexType>

Figure 5.3. Dfinition de la balise pays avec trois proprits, dont une gographique .

La dfinition nest pas complte si on ne prcise pas que la structure du pays (PaysType) est drive dAbstractFeatureType. De mme, la balise Pays doit tre utilise partout o il y a eatureType. ys une balise _Feature plus gnral Cest le concept dhritage. gnrale.

1. <element name="Pays" type=" PaysType " substitutionGroup="gml:_Feature"/> 2. <complexType name = PaysType > 3. <complexContent> <extension base="gml:AbstractFeatureType"> 4. 5. <sequence> 6. 7. </sequence> 8. </extension> 9. </complexContent> 10. </complexType>

Figure 5.4. Pays est une feature

48

Les relations entre deux features sont reprsentes de trois manires possibles : Une relation lie directement une feature une autre en lincluant dans celle-ci. Dans le cas 1 de la Figure 5.5, la relation possede a directement comme fils un lment rgion. Une relation possde une rfrence une feature interne au document. Dans le cas 2, un attribut xlink :href donne ladresse de la feature rfrence. La feature region se trouve dans le mme document que pays. Son adresse locale est forme par le caractre # suivi son id. Une relation possde une rfrence une feature externe au document. Dans le cas 3, les features pour pays et region se trouvent sur des serveurs diffrents. Ladresse didentification uniforme de ressource (URI), est compose de ladresse du serveur, du chemin vers le document ainsi que de la situation locale de la ressource, reprsente par # suivi de son id.

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

cas 2 <Pays gml :id= p1> <nom>Belgique</nom> <possede xlink :href= #r1> </Pays> <region gml :id= r1> </region>

1. 2. 3. 4. 5. 6.

cas 3 <Pays gml :id= p1> <nom>Belgique</nom> <possede xlink:href=http://www.gov.be/sig/regions.xml#r1> </Pays>

Figure 5.5 Les relations en GML

49

Les relations entre les features en GML se basent sur les spcifications de XLink. Lattribut xlink :href dans un document GML signifie que la valeur de llment se trouve ladresse rfrence et quelle doit tre rcupre.

5.5 Les modules de GML

Pour aider caractriser et encoder les informations, GML propose cinq grands modules :

Coeur GML

Gomtrie

Topologie

Temps

Couverture

Projection

Figure 5.6 Les cinq modules principaux de GML

5.5.1 Le cur GML Cest le minimum requis pour quun parseur puisse comprendre le document. Il contient les dfinitions des objets GML, des features et des relations. Il contient galement tous les types abstraits des autres modules. Lorsque le parseur rencontre un lment Curve , il ne connait pas sa structure. Par contre, il sait quil a voir avec le module gomtrie. En remontant la hirarchie des lments du schma dfinissant Curve , il retombera sur AbstractGeometryType. Le cur GML est dfini par gmlBase.xsd, xlinks.xsd et basicTypes.xsd. 5.5.2 La gomtrie Cest lun des plus gros modules de GML. Il implmente tous les types gographiques dfinis par lISO 19107. Le module gomtrique 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 gomtriques supportes taient les points et les lignes: Point, LineString, LinearRing, Box et Polygon ; ainsi que les agrgats suivants : MultiPoint, MultiLineString, MultiPolygon. La version 3 supporte de nouveaux types comme Arc, Circle, CubicSpline, Ring, OrientableCurve, OrientableSurface, Solid ; et leurs agrgats correspondants comme MultiCurve, MultiSurface, etc Cette version supporte aussi les types composites suivants: CompositeCurve, CompositeSurface, et CompositeSolid. La diffrence entre un agrgat de Curve et un type

50

composite Curve dans GML est que les membres gomtriques dun type composite sont tous connects alors que les membres dun agrgat peuvent tre disjoints. Les types sont rpartis dans 5 schmas : geometryBasic0d1d.xsd, geometryBasic2d.xsd, geometryAggregates.xsd contiennent les gomtries linaires. Ces schmas sont compatibles avec GML2. geometryPrimitives.xsd, geometryComplex.xsd contiennent tous les types et lments de la gomtrie non linaire (par exemple les courbes).

La Figure 5.7 donne la hirarchie des types gomtriques utiliss dans MADS.

51

Figure 5.7 La hirarchie des types gomtriques de GML telle que dcrite par lOGC

52

5.5.3 La topologie La topologie dcrit les proprits spatiales qui restent inchanges lorsquon dforme des objets de faon continue (tirement par exemple). Dans GML, la topologie spatiale est base sur des nuds, des arrtes, des faces et des solides et la description de leur relations. Ce sont les primitives de la topologie. GML laisse lutilisateur choisir le type de relation. Il doit lui-mme dfinir la proprit topologique dun lien. Les primitives fournies ne servent que de conteneurs pour des lments gomtriques. Le fichier topology.xsd dfinit tout cela.

5.5.4 Le temps Ce module comprend la dfinition des primitives simples de temps comme Instant et Priode, et des primitives complexes. Ces dernires fournissent la base de la topologie temporelle. Tout comme la topologie spatiale, la topologie temporelle fournit des nuds et des arrtes. Ceux-ci permettent de modliser lhistorique dun objet variant dans le temps (ordre sur le temps). Les fichiers utiliss sont temporal.xsd et dynamicFeature.xsd.

Figure 5.8 La hirarchie du temps

53

5.5.5 La couverture Une couverture GML est une fonction de distribution, dfinie 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 : lensemble des domaines comprend soit une collection dlments

spatiaux (point, ligne et rgions) soit une grille (Grid) qui lon doit assigner une valeur Range Set : lensemble des valeurs assignes aux lments 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 dune couverture

54

5.5.6 La projection Un autre module important de GML est le systme de projection (CRS10). Il dcrit une fonction qui chaque point de la surfa (3d) de la Terre associe un point sur un plan (2d). surface GML contient un dictionnaire des projections existant s. Le systme de projection doit tre existantes. dfini une fois pour tous les documents ou tre dfinit petit petit pour chaque type gomtrique. Six fichiers forment le module CRS: referenceSystems.xsd, coordinateOperations.xsd, coordinateSystems.xsd, datums.xsd, dataQuality.xsd, coordinateReferenceSystems.xsd.

5.5.7 Normes ISO Tous les modules de GML suivent les norme ISO. 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
Figure 5.11 Les normes ISO sur lesquelles repose GML

5.6 Exemple
Voici lexemple donn par lOpen Geospatial Consortium (OGC) dun document GML reprsentant une ville et ses proprits gographiques. es

10

Coordinate Reference System

55

Figure 5.12 Reprsentation graphique de lexemple

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.

<?xml version=1.0 encoding=UTF-8?> <CityModel xmlns=http://www.opengis.net/examples > <gml:name>Bruxelles</gml:name> <gml:boundedBy> <gml:Box srsName=http://www.opengis.net/gml/srs/epsg.xml#4326> <gml:coord><gml:X>0.0</gml:X><gml:Y>0.0</gml:Y></gml:coord> <gml:coord><gml:X>100.0</gml:X><gml:Y>100.0</gml:Y></gml:coord> </gml:Box> </gml:boundedBy> <cityMember> <River> <gml :description>Elle passe par Bruxelles</gml :description> <gml:name>Senne</gml:name> <gml:centerLineOf> <gml:LineString srsName=http://www.opengis.net/gml/srs/epsg.xml#4326> <gml:coord><gml:X>0</gml:X><gml:Y>60</gml:Y></gml:coord> <gml:coord><gml:X>80</gml:X><gml:Y>70</gml:Y></gml:coord> <gml:coord><gml:X>100</gml:X><gml:Y>40</gml:Y></gml:coord> </gml:LineString> </gml:centerLineOf> </River> </cityMember> Code XML de lexemple

56

5.7 Les outils pour la cration de schma applicatif GML

Il existe plusieurs moyens pour crer le schma applicatif GML : Le premier moyen, le plus classique et dutiliser un diteur de texte ou un outil grant le format XML. Une autre faon dy parvenir est de modliser visuellement les concepts et de transformer le modle ainsi cr en schma applicatif GML correspondant. Mon travail porte sur cette deuxime manire de faire.

5.8 Les outils de manipulation

GML tant bas sur le standard W3C XML, il bnficie de facto des outils crs pour celuici. Ainsi, des outils de manipulation comme SAX ou JDOM, de base de donnes comme eXist-db, de transformation comme XSLT et encore beaucoup dautres, pourront tre utiliss avec GML. Un outil pour laffichage de donnes GML en passant par SVG est inclus dans la suite doutils MADS [Deb2003]. Pour la composante temporelle, linstant de la visualisation est choisi sur une ligne de temps. Faire dfiler le slider sur cette dernire permet de voir lvolution des donnes spatio-temporelles.

5.9 Les services Web

5.9.1 Web Map Service (WMS) Un service qui implmente la spcification Web Map Service permet de produire des cartes de donnes gographiques partir de diffrents serveurs de donnes. Cela permet de mettre en place un rseau 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'lments vectoriels comme le SVG.

57

5.9.2 Web Feature Service (WFS) Un service qui implmente la spcification Web Feature Service permet un client dobtenir et de modifier une feature sur le serveur. Les oprations suivantes sont dfinies dans les spcifications de WFS : GetCapabilities : cette opration permet au serveur WFS de dcrire les oprations possibles et dindiquer les features supportes. Certains WFS nimplmentent pas tous les spcifications optionnelles de WFS (Transaction et LockFeature). DescribeFeatureType : Pour chaque feature supportes, le serveur WFS envoie au client la structure de donnes (un schma dapplication GML) du feature demande. GetFeature : un serveur WFS envoie une liste de features lorsquil reoit une demande de features formule en Catalog Query Language (CQL). CQL est un langage de filtrage. Il permet de faire des slections spatiales et non-spatiales.

Si le support transactionnel est implment, le serveur WFS possde en plus ces oprations-ci Transaction : Un serveur WF sil implmente le support de la transaction possde ses oprations sont 'Create', 'Update' et 'Delete' sur les features. LockFeature : Le support de la transaction doit empcher lcriture concurrente sur une ou plusieurs instances pendant la dure d'une transaction. LockFeature permet de faire une demande de blocage.

Les serveurs WFS permettent de partager les features sur Internet, et de fdrer les bases de donnes.

58

Chapitre 6. Correspondance entre les concepts MADS et les concepts GML

Dans les chapitres prcdents, j'ai parl du modle MADS pour la modlisation de base de donnes spatio-temporelles ainsi que du modle dchange GML. Nous allons maintenant voir comment obtenir un schma GML applicatif partir du modle MADS.

6.1 Contexte
La spcification GML comprend environs 600 pages et plus de 1000 balises de noms dobjet. Elle dfinit un grand nombre de gomtries pour dcrire les features et offre galement la possibilit d'encoder des couvertures, des topologies, le temps et les features dynamiques. GML a t conu pour couvrir de nombreux besoins. Mais de par la taille de sa spcification, il est complexe utiliser. Il existe donc une forte barrire son adoption. Pour acclrer celle-ci, lOGC a cr des sous-ensembles simplifis de GML dont lun des plus connus est le profile GML Simple Feature . Des outils visuels existent pour la cration du code XML et des schmas XML. Une personne devra ds lors travailler au niveau des lments et des balises pour modliser les concepts thmatiques tels que les objets, les attributs et les relations comme vu dans lexemple cit au chapitre GML.

6.2 Etude de lart

Pour palier ce problme, le projet GeNorway [UML2GML 02] a utilis le langage UML (Unified Modeling Language) pour modliser le schma GML applicatif et pour gnrer automatiquement du code GML partir dun schma de classe UML. Une quivalence entre UML et GML a t ralise en formulant plusieurs contraintes de conception :

Le schma UML doit tre conforme aux rgles spcifies par le modle conceptuel UML. Cest la seule rgle propre UML. Le schma UML doit tre conceptuel et neutre de toute implmentation. Il ne doit rien savoir propos de GML.

59

Le schma GML applicatif gnr doit tre pleinement dtermin par le schma UML. Aucunes modifications ultrieures par lutilisateur ne doivent tre ncessaires sur le schma GML applicatif. Du ct positif, sil y a un accord entre 2 parties sur le schma UML, cela implique que les 2 parties seront aussi en accord sur le schma GML. Le schma GML applicatif gnr doit exploiter des constructions fournies par XML schma comme lhritage, les types de donnes et les liens XLink afin de faciliter la lecture de ce schma et sa comprhension. Le schma GML gnr, ainsi que les documents GML correspondants, doivent remplir les spcifications GML.

Voici les problmes que lquipe du projet GeNorway a rencontrs :

a) Hritage en GML : Daprs GML, tout type qui contient dautres types doit
ncessairement tre une featureCollection, ce qui veut dire quil contient des features. Ainsi une feature ferme peut avoir plusieurs champs. Ds lors elle doit tre de type featureCollection selon les rgles GML. Mais si cette ferme hrite dHabitation de type feature, il y aura un conflit.

b) Hritage multiple en UML : UML possde lhritage multiple alors quil nexiste pas en
Schma XML. Si lon veut suivre les contraintes de conceptions, on ne peut pas simplement copier les attributs des supertypes dans le fils.

c) Ordre des sous-lments en GML : Il nexiste pas de manire de dfinir lordre des
attributs et des associations dans UML alors quils suivent un ordre en GML. Il faut dfinir un ordre pour viter qu chaque gnration, le schma GML soit modifi alors que le schma UML reste identique. Cest ce que les responsables du projet on fait.

d) Dclaration globale en GML : Les associations sont reprsentes par une balise ayant le
nom du rle de lassociation. Les balises sont dfinies globalement. Les noms de tous les rles devront tre uniques alors quen UML les rles sont seulement uniques au sein dune classe. La solution propose est de combiner le nom de la classe aux rles.

e) Modlisation des restrictions de domaine de valeur en UML : GML permet de

restreindre des valeurs un domaine par le mcanisme de restriction.

f) Dfinition complique de lassociation en GML : GML modlise lassociation par une

balise qui contient ou rfre aux lments qui participent lassociation, alors quil suffirait dinclure directement un lment dans lautre lment de lassociation.

60

Le point a) est rsolu en crant une classe de type featureCollection pour chaque feature. Cette classe fait office de conteneur pour la feature. Lhritage se fait uniquement entre les features et non les conteneurs. Cest une modlisation explicite car elle viole le concept de la modlisation conceptuelle. Lutilisateur doit connaitre les spcificits de GML. [Galdos02] Je reviendrais sur certains de ces points plus tard lorsque le problme sera rencontr. Le projet GeNorway ne sintresse qu lutilisation des concepts de base de GML : les features, les relations et attributs combins la temporalit et la spatialit simple. En effet, les concepts comme la topologie, la couverture ou les lments dynamiques (voluant soit dans le temps, soit dans lespace) ne sont pas pris en compte.

6.3 MADS au lieu de lUML

MADS est un modle conceptuel, tout comme lUML mais spcifiquement conu pour la modlisation spatio-temporelle. Ses avantages par rapport lUML sont :

Lutilisation dicnes pour marquer un lment dun type temporel et/ou spatial. Avec lUML, on doit apprendre utiliser les types temporels et spatiaux dfini par la norme ISO. Lutilisation dicnes dans MADS permet une comprhension plus facile du schma entre les diffrents utilisateurs. Lorthogonalit des dimensions. Avec lUML, pour marquer les objets dune classe comme tant spatiaux, il faut crer un attribut avec le type spatial. Pour reconnatre cet attribut comme tant lemprise de lobjet, il faut saccorder sur un nom et lutiliser partout. Le support des prdicats topologiques et de synchronisation sur les relations. Le support de nombreux langages cibles (SQL, GML, ) avec un mme schma conceptuel. La multi-reprsentation. LUML ne propose pas de mcanisme pour combiner deux reprsentations diffrentes.

61

6.4 Traduction
Comme expliqu dans [ParZimMinAis2002], tous les concepts que propose le modle conceptuel MADS nexistent pas forcment dans les modles logiques cibles. Le concept de spatialit dun objet nexiste pas tel quel dans les modles tels que MySQL ou encore Oracle. Pour les implmenter sur ces modles, il faut transformer le modle conceptuel. Cette transformation consiste remplacer un concept C du modle MADS par une construction similaire. Elle remplace le concept C par des concepts C1, C2, , Cn qui eux, existent sur le modle logique cible. Le modle conceptuel intermdiaire sappelle MADS minus. Le schma bas sur le modle intermdiaire est ensuite retranscrit vers le modle logique cible. La production du modle logique cible consiste rcrire le schma MADS minus avec la syntaxe du modle logique cible.

6.5 Rgle de transformation

Une rgle de transformation est une classe hritant de TransformRule et implmentant la fonction applyTransformRule qui prend comme paramtres le document XML, le nud actuel traiter et le nud grand pre du nud actuel. Chaque rgle de transformation peut possder une condition dapplication sur le nud courant servant filtrer les nuds sur lesquels elle doit tre applique. Voici un exemple de rgle de transformation de concept. Le type interval est remplac par le concept dinstants. Il y en a deux : un instant de dbut 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

Limplmentation de cette rgle de transformation ne se fait pas tout fait comme expliqu ci-dessus. Bien que lide gnrale soit correcte, limplmentation dpend de la structure XML de la reprsentation du schma MADS (voir la Figure 6.2).

62

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 schma MADS

6.6 Architecture du traducteur de schma MADS

Le module de traduction est constitu de deux parties : une partie visuelle (GUI) et une partie ralisant lapplication des rgles pour la traduction. La partie visuelle VisualTranslator prend un fichier MURMUR en input et demande le driver utiliser. Un driver est un fichier XML dfinissant la liste de rgles appliquer pour traduire un schma MADS vers un schma cible. Il existe dj des drivers pour Oracle8 et Oracle9 [MUR 02] ainsi que Arcview [COB 02].

63

Figure 6.3 Capture d'cran du traducteur de schma

Une fois le driver slectionn et le processus de traduction dclench, loutil va appli appliquer les diffrentes rgles sur le fichier input pour produire le fichier output. Algorithme :
Ouvrir le fichier driver qui est un fichier XML dfinissant une liste de rgle appliquer. Ouvrir le fichier MURMUR spcifi en input, le transformer en fort de nuds au moyen de DOM. Chaque rgle liste correspond une classe, elle sera charge dynamiquement puis sera insre dans un vecteur en fonction de son prfixe (GD, MR, R, ST, C). Chaque vecteur reprsente une famille de rgles. Il a cinq grandes familles de rgles : les rgles de grandes transformation de type gnrales (GD), les rgles de transformation pour la multi multireprsentation (MR), les rgles de suppressions (R), les rgles de transformations des types spatio-temporelles et les rgles de transformation nappartenant aucune des autres temporelles transformation familles de rgles et qui dpendent de la cibles(C). Chaque famille de rgles est applique suivant un ordre particulier : dabord les rgles de suppression R, puis les rgles MR, les rgles ST, les rgles GD et enfin les rgles C. Pour chacune des ces familles, un parcours en profondeur de type pos parcours post-ordre est effectu. Cela signifie quon parcourt les nuds fils de gauche droite avant de traiter le nud on courant. Toutes les rgles dune famille seront testes au moment du traitement du nud courant. A chaque fois quune rgle de transformation est applique avec succs (le nud haque

64

courant rpond la condition de la rgle), le processus reprend depuis la racine du document XML pour la famille de rgles en cours. Une fois quil nest plus possible dappliquer une rgle avec succs, la traduction passe la prochaine famille de rgles.

6.7 Conversion dun schma MADS vers un schma GML

La conversion du schma MADS est ralise par partie :

La partie thmatique est proche du travail effectu par [UML2GML]. La partie spatiale fait la correspondance entre les modles pour les types spatiaux et dfinit la variation dans lespace. La partie temporelle fait la correspondance entre les modles pour les types temporels et dfinit la variation dans le temps. La partie multi-reprsentation introduit le concept dans GML.

6.8 Reprsentation de la dimension thmatique

Les concepts de GML sont trs proches des concepts thmatiques de MADS. Voici les rgles de transformation appliquer pour chaque concept MADS. 6.8.1 Type dobjet Soit un objet T avec des attributs quelconques, il sera reprsent par une classe T-Type (la balise complexType) hritant structurellement de la classe AbstractFeatureType de GML. Cet objet sera reprsent par une balise T qui pourra tre utilise 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 Reprsentation dun type dobjet T en GML

Bien quun objet ait t dfini, si nous voulons pouvoir avoir plusieurs instances de cet objet, nous devons dfinir un conteneur dobjets. GML fournit une FeatureCollection. Pour chaque objet T, un ensemble T-set ayant des objets T est cr.

65

<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>

Lutilisation de FeatureCollection impose dencadrer chaque instance de T par une balise featureMember (comme dans lexemple) ou dencadrer tous les T en une fois laide de la balise featureMembers. Dans la dfinition ci-dessus de T-Set, celui-ci peut contenir nimporte quelle feature. Pour se restreindre aux objets T, remplacer la balise restriction par la balise extension naura aucun effet. T-Set est dfini comme contenant des featuresMember ou un featureMembers. Ds lors nous devons crer un complexType Tmember(s)-type avec comme balise T-member(s) pouvant remplacer featureMember(s). Tmember-(s)-type sera une restriction sur featurePropertyType ou featureArrayPropertyType contenant soit une fois T-type en limportant pour featureMember soit plusieurs fois en limportant pour featureMembers.

6.8.2 Attributs Les attributs supports par MADS sont aussi supports par GML. Ce sont les proprits dune feature.
Attribut Monovalu et Multivalu

Pour un attribut monovalu, il nest pas ncessaire de prciser la cardinalit cest--dire le minOccurs ainsi que le maxOccurs de la balise, tant donn quils sont mis 1 par dfaut. Pour un attribut multivalu, il faut mettre le maxOccurs unbounded.

66

Attribut Simple et Complexe

Un attribut simple (comme lattribut B de lexemple ci-dessous) ne pose pas de problme. GML supporte les types dfinis par MADS. Un attribut complexe A compos dattributs simples ou complexes A1, A2, , Am est dfini par une classe A-Type reprenant les attributs A1, A2, , Am. Nous appliquons la rgle tant quil 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 Enumr

Un attribut numr (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 crer une numration de chiffres en restreignant le range dinteger 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 Gnralisation Soit un objet T et un objet TE hritant de T, ce cas est similaire au cas pour un type dobjet une exception prs. Le groupe de substitution doit tre modifi pour reflter le fait que la

67

balise TE peut tre utilise en lieu et place de la balise T. Nous pouvons spcifier la substitution car le type de T est T-Type et TE-Type drive 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 Reprsentation dun hritage en GML

Lhritage multiple est plus compliqu reproduire avec les concepts de XML. En effet, la balise complexContent ne peut contenir quune seule fois la balise extension. Soit un objet T qui hrite des classes T1, T2, , Tn , seul un des parents pourra tre choisi comme base pour lextension, les attributs des autres parents restants seront ajouts dans sequence par des <element ref= > . Le concept de substitution permet dutiliser TE en lieu et place de T, ainsi un conteneur de T peut contenir des T et des TE. Mais il est aussi intressant de sparer TE du conteneur de T, cela signifie que TE possde son propre conteneur. Pour pouvoir encore maintenir que TE appartient T, un xlink peut tre introduit dans le conteneur de T. Cette ide est intressante dans le cas de lhritage multiple, au lieu de spcifier un des pres comme base de lextension nous incorporons dans TE chaque type des pres (cela donne une squence de <element ref= lment pre i >) et dans le conteneur de chacun des objets pres nous incluons comme membres le xlink vers la partie importe du pre correspondant dans llment TE.

6.9 Types de relation

Une association est une reprsentation dun lien existant entre 2 objets dans le monde rel. Par exemple, plusieurs personnes peuvent suivre un cours tout comme une personne peut suivre plusieurs cours diffrents au cours de lanne. Nous allons analyser le cas des associations binaires ainsi que les n-aires. Pour celles-ci nous verrons le cas o lassociation ne comprenant pas dattributs, ainsi que le cas contraire.

68

6.9.1 Associations non porteuse dinformations

Binaire

La Figure 6.6 prsente deux objets relis par une relation Rel avec des rles de cardinalits (1 :n). Ces rles ne sont pas nomms. Cest un cas gnral.

Figure 6.6 Relation binaire non porteuse dinformation

Un rle sans nom de lobjet A lobjet B est nomm A-Rel. Sil a un nom, le rle sera nomm A-nomDuRole. Pour chaque objet, nous allons inclure dans ses attributs, le nom du rle sil existe ou dans le cas contraire, le nom de lassociation plus le nom de lobjet lier. Ainsi pour ce cas, lattribut reprsentant le rle de A vers B est A-Rel. Ce rle doit rfrencer un ou plusieurs objets B. Mais nous ne pouvons pas inclure <element ref= "app:B"> dans lobjet A tant donn quil ne fait que reprendre/inclure/rimporter la dfinition de B cest dire <element name="B" type="b-Type">. Donc nous allons dupliquer linformation. Or seule la rfrence est vers la bonne instance. Pour rsoudre ce problme, GML introduit le FeaturePropertyType qui consiste lier des features dautres features. Deux manires sont proposes. On peut soit inclure directement llment rfrenc dans lobjet, soit utiliser lAssociationAttributeGroup qui ajoute au rle lattribut xlink :href pour rfrencer lobjet. Bien quinclure lobjet li directement est autoris, seul les rfrences avec lattribut xlink :href seront utilises. Une des principales raisons est que lattribut xlink :href permet de rfrencer 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 mme si les cardinalits des deux rles permettent dinclure lun des objets dans lautre, la dcision prise au-dessus ne rend ce choix pas important. En effet, un moteur XLink doit savoir rcuprer lobjet pointer et le rinclure comme sil tait local selon la dfinition 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>

69

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

Pour la relation binaire, chaque objet possde un lien (le nom du rle) avec la rfrence vers les objets lis.
Relation n-aire

Figure 6.7 Relation ternaire non porteuse dinformation

Pour une relation n-aire non porteuse dinformation, la relation Rel est transforme en type dobjet Rel. Il sera compos dattributs de type Role de cardinalits (1,1) vers A1, A2, ,An. Chaque objet A1, A2, ,An auront un lien vers lobjet Rel de cardinalit du rle vers Rel.

6.9.1 Associations porteuse dinformations Une relation peut tre porteuse dinformations. Par exemple, une association qui lie un lve un examen peut contenir une information sur les points que llve a obtenu. Dans le cas dune relation porteuse dinformations binaire ou n-aire, la situation est identique lassociation n-aire non porteuse dinformations. La relation est transforme en objet et contient en plus des liens vers les objets participants, linformation quelle porte.

6.10 Reprsentation 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 prsent de ne discuter pas discuter des types temporels complexes. GML possde 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">

70

<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 dfini 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 proprits qui changent dans le temps (le niveau deau dun lac). Les cycles de vie sont modliss laide de la topologie temporelle de MADS. Les transitions entre les divers tats des cycles de vie seront correctement modlises.

6.11 Reprsentation de la dimension spatiale

Toute comme pour la temporalit, il faut traduire les types spatiaux dans leurs quivalents en GML. Point : Il est reprsent par <Point> qui est de type gml :PointType. Line : Les lignes peuvent tre reprsentes sous GML par plusieurs types ; ds lors un lment abstrait les reprsentent tous : <_Curve> de type gml :AbstractCurveType. Parmi les types qui drivent de ce type abstrait, il y a <LineString> de type gml :LineStringType. Surface : De la mme manire, tous les types de surfaces hritent sous GML de <_Surface> de type gml :AbstractSurfaceType. Parmi les surfaces, il y a <Polygon> de type gml :PolygonType. Un polygone est compos dune limite extrieure et 0 ou plusieurs limites intrieures reprsentant les ventuels trous possibles.

71

OrientedLine : il est reprsent par <OrientableCurve> de type gml :OrientableCurveType. Ce type comprend un lment dcoulant de <_Curve> et une orientation reprsente par un signe soit +, soit -. Par dfaut, lorientation est +, ce qui indique que lorientableCurve est identique la _Curve inclus. Par contre, - indique que lorientation est donn par linverse de la _Curve. SimpleSurface : Une surface ne possdant pas de trou peut tre dfini partir du type gml :Polygon mais sans les limites intrieures.
<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 crer ce type, nous partons de MultiCurve et le drivons pour obtenir MultiOrientedLineBag mais avec comme contrainte quil 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>

72

<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 faon similaire, simple surface sera reprsent par un MultiSimpleSurface dfini 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 rutilisons SimpleSurface dfini 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">

73

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

Rcapitulatif : MADS Geo SimpleGeo ComplexGeo Point Line Surface OrientedLine SimpleSurface PointBag LineBag SurfaceBag OrientedLineBag SimpleSurfaceBag GML AbstractGeometryType AbstractGeometryPrimitiveType MultiGeometryType PointType AbstractCurveType AbstractSurfaceType OrientableCurveType Restriction sur PolygonType MultiPointType MultiCurveType MultiSurfaceType Cration de MultiOrientableCurveType Cration de MultiSimpleSurfaceType
Figure 6.8 Tableau de correspondance

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

6.12 Reprsentation de la dimension multi-reprsentation

Nous avons vu dans le chapitre MADS que la multi-reprsentation se sert de cachets pour associer une reprsentation une perception. Pour rsoudre le problme du passage au GML, je pars du but du projet MurMur ainsi que du problme de lIGN. IGN a plusieurs bases de donnes gographiques des rsolutions diffrentes couvrant la France. Pour lIGN, un des problmes tait la gestion des mises jour car celles-ci doivent tre rpercutes sur toutes les cartes. Les bases de donnes ont t rassembles en un schma avec les cachets correspondants chacune delles. MurMur a permis de pouvoir faire des interrogations au niveau conceptuel (langage dinterrogation de haut niveau) sur la nouvelle base. Pour crer la base, un processus dextraction, de transformation et de chargement (ETL) a lieu. Un service WFS rsoudrait en partie le problme parce quil supporte de nombreuses bases de donnes et parce quil supporte les transactions (ajout, suppression, mise jour). Ds

74

lors, LIGN ne doit pas rassembler ses bases de donnes en une seule. Seul un service WFS doit tre rajout. Le WFS utilise GML comme format de rsultat et de transaction et CQL (Catalog Query Language) pour le filtrage des features envoyer. Lide propose est dutiliser MADS comme systme fdrateur. Au niveau des schmas conceptuels, chaque cachet est associ une base de donnes. Au niveau des requtes, les cachets sont dj supports par lditeur de requte. Un travail est ncessaire par le traducteur de requte pour scinder la requte en sous-requtes pour les services WFS. La scission se fera sur base du cachet. Lorsque les cots dune jointure sont rpartis sur deux services, les sous-requtes rcuprent les lments et cest linterrogateur de faire le travail. Le problme montre tout lintrt de devoir scinder un schma GML applicatif en de nombreux autres schmas GML : Il faut un schma par reprsentation ou encore une par serveur WFS. Chaque systme reste indpendant des autres. Et chaque systme peut toujours connaitre lvolution des schmas en demandant linformation au WFS. Lautre ide est de garder toutes les reprsentations en un endroit. Dans le modle conceptuel, un utilisateur met des cachets sur des objets, des attributs, des relations etc. De la mme manire, lide serait dajouter un attribut jouant le rle du cachet pour chaque balise dobjets, dattributs et de relations. Mais un lourd travail ETL11 doit tre fait pour runir toutes les donnes identiques dans un mme document XML. La maintenance pose aussi problme car le systme dinsertion doit prendre en compte les cachets et bien associer les donnes. Avec la fdration au travers de WFS, les schmas sont rcuprs et peut tre retransforms vers lditeur de schma. Une personne peut utiliser nimporte quel systme WFS disponible, importer les schmas, faire correspondre les features voulus et commencer faire des requtes. La personne ne doit plus se proccuper de scinder ellemme ces requtes vers le bon service WFS.

11

Extract-Transform-Load : Data dumping

75

Chapitre 7. Conclusion
Lobjectif de ce mmoire tait de concevoir une extension au traducteur de la chaine doutils MADS. En plus des traductions vers les modles relationnels dj existants (Oracle8i et Oracle9i), une traduction vers GML a t envisage. Pour arriver raliser cette traduction, il a dabord fallu comprendre les concepts du modle MADS expliqus au Chapitre 2. Ce modle trs puissant et complet est destin faciliter le travail de conception de lutilisateur notamment par lorthogonalit des diffrentes dimensions. MADS permet de ne plus se proccuper de la cration des schmas au niveau logique cible, par exemple pour Oracle8i, Oracle9i ou ArcView. Ce modle cache limplmentation au niveau logique. Pour cela, il propose en plus dun diteur visuel de schma, un diteur visuel de requte. Ce dernier se charge de transformer une requte au niveau conceptuel en une requte qui peut tre comprise par la cible au niveau logique. Ces outils jouent un rle important et font partie intgrale du modle. GML est devenu le standard pour lchange dinformation gographique notamment grce aux services web WMS et WFS. Il est en pleine expansion grce leffort de lOpen Geospatial Consortium (OGC) mais aussi grce son adoption massive par de nombreuses socits spcialises. GML couvre tous les besoins pour la modlisation de linformation gographique. Mais sa complexit est lun des ces points faibles. Pour y remdier, lOGC a introduit un profil simplifi de GML. Cest 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 modle GML a t effectue. Certains concepts de MADS sont cependant absents du modle GML. Notamment au niveau temporel. Outre cela, certaines limitations proviennent de XML Schma. La solution fut de remplacer les concepts manquants par plusieurs sous-concepts existants dans GML. A la fin de la traduction, un schma applicatif GML est produit. Plusieurs tudes pour la cration visuelle de ce type de schma ont dj t ralises comme vue la section 6.2. Dans le cas de ltude UML-to-GML , il faut que lutilisateur connaisse les types ISO pour linformation gographique, ce qui est fort contraignant. Aucune des tudes raliss jusque l ne fournit la puissance et lexpressivit de MADS. Mon mmoire a port sur la cration dun outil de traduction de MADS vers GML. La disponibilit dun tel outil devra permettre daugmenter la visibilit de MADS auprs de la communaut SIG.

76

7.1 Travaux futurs

Une fois le schma applicatif GML obtenu, il pourra tre utilis diverses tapes de la vie de linformation gographique. De sa cration son stockage en passant par les requtes et lanalyse de celles-ci. La grande force du modle GML est de pouvoir profiter des nombreux outils disponibles pour son cousin XML.

7.1.1 GML et la cration et visualisation de donnes partir du schma applicatif GML, il est envisageable de crer un formulaire dentre coupl avec le logiciel open source JUMP Unified Mapping Plateform Workbench [JUMP], un framework pour la cration, la manipulation ainsi que le visionnage dinformation gographique. 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 donne GML permet de modliser les concepts spatio-temporels de MADS. Reste quil ne gre pas la prservation smantique de bon nombre de concepts. Or les bases de donnes XML natives implmentant et utilisant XQuery [W3C:XQuery] comme langage dinterrogation permettent dutiliser ses propres fonctions dans la requte. XQuery permet par exemple

77

dinvoquer des fonctions crites en Java. Ainsi titre de test, jai ralis lintgration de la libraire open source JTS Topology suite12 de Vivid solutions dans eXist-db13, qui est une base de donnes XML utilisant XQuery. EXist-db supporte grce cela les oprations sur les types gomtriques et les types temporels. Limplmentation de ces fonctions ne veut pas dire pour autant que la base de donnes est spatio-temporelle. Toute la structure logique interne du schma conceptuel de lutilisateur est expose. En effet, lutilisateur doit connatre le schma applicatif GML quivalent pour faire ses requtes. Une faon de ne pas exposer la structure est de crer des fonctions additionnelles dans XQuery qui vont maintenir automatiquement les structures internes en GML reprsentant des concepts MADS. De la mme faon que les requtes en algbre MADS ont t traduites vers le modle relationnel ou encore le modle OO [ZimMin2006], lalgbre MADS doit tre traduite vers le langage dinterrogation de XQuery.

7.1.3 Fdration WFS au travers de MADS La fdration WFS au travers de MADS a t propose au chapitre prcdent pour rsoudre le choix de la gestion de la multi-reprsentation. Lide est qu partir de lditeur de schma, un utilisateur puisse importer les schmas des features servis par un ou plusieurs serveurs WFS. Pour cela, un traducteur du modle GML vers le modle MADS devra tre cre. Une fois le schma GML synthtis vers le modle MADS, lutilisateur pourra effectuer une requte sur des features de provenances diverses. Loutil scindera la requte en plusieurs sous-requtes 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 13

http://www.vividsolutions.com/jts/jtshome.htm http://exist.sourceforge.net/

78

Bibliographique
[Balley 02] Vers la reprsentation multiple : le projet MurMur, BI n73 Bilan de la Recherche 2001, pp. 61-74, France, IGN 2002 [Berron07] Julien Berron, Dveloppement d'une application de MapServer/PostGIS, Universit d'Avignon et des Pays de Vaucluse, 2007. webmapping

[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 Donnes Localises Temporelles, Rapport final INTEREG II, Laboratoire THEMA, Universit de Franche-Comt,Besanon et EPFL-LBD, Lausanne, Mars 2002. [Deb2003] E. Debois. Interrogation de bases de donnes spatio-temporelles : Conception d'un outil de visualisation des rponses aux requtes. Mmoire d'Ingnieur 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. Zimnyi. 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, rpertoire contenant toutes les documentations produites au cours du projet MurMur. [ParSpaZim2006] C. Parent, S. Spaccapietra, and E. Zimnyi. Conceptual Modeling for Traditional and Spatio-Temporal Applications: The MADS Approach. Springer-Verlag, 2006. ISBN : 978-3-540-30153-0.

79

[ParZimMinAis2002] C. Parent, E. Zimnyi, M. Minout, and A. Aissaoui. Implantation d'un modle conceptuel avec multi-reprsentation. In A. Ruas, editor, Trait IGAT sur la reprsentation multiple et la gnralisation, chapter 7, pages 131-147. Herms, 2002. [REPRESENTATION] http://www.ifremer.fr/drogm/Realisation/Vulgar/SIG/SIG.htm [Souleymane 03] T. Souleymane, M.H. De Sde-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 Grnmo, 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-reprsentation dans les bases de donnes gographiques, thse de doctorat de lcole polytechnique fdrale de Lausanne, 2001. [VRML] http://www.web3d.org/x3d/vrml/ [W3C:DTD] Extensible Markup http://www.w3.org/TR/xml/ Language (XML) 1.0 (Fourth Edition),

[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 http://www.w3.org/TR/xml/ Language (XML) 1.0 (Fourth Edition),

[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. Zimnyi and M. Minout. Implementing Conceptual Spatio-Temporal Schemas in Object-Relational DBMSs. In Proc. of the On the Move to Meaningful Internet

80

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

81

Liste des figures

Figure 1.1 Les concepts spatio-temporels ............................................................................... 2 Figure 1.2. Les fonctionnalits dun SIG................................................................................... 3 Figure 1.3. Principe de larchitecture client-serveur ............................................................... 4 Figure 2.1 Les diffrentes couches de modlisation ............................................................... 9 Figure 2.2 Module de traduction dun schma conceptuel vers un schma logique ........... 10 Figure 2.3 Diffrentes reprsentations du mme rond-point dans des bases de donnes [Balley 02] ...................................................................................................................... 11 Figure 2.4 Exemple dorthogonalit ...................................................................................... 12 Figure 2.5 Exemple de type dobjet et dattributs ................................................................. 13 Figure 2.6 Personne (super-type) et ses sous-types ............................................................. 14 Figure 2.7 Rles possibles ...................................................................................................... 15 Figure 2.8 Exemple dassociation avec attribut .................................................................... 16 Figure 2.9 Une relation cyclique ............................................................................................ 16 Figure 2.10 Exemple de multi-association ............................................................................. 17 Figure 2.11 Exemple dagrgation ......................................................................................... 17 Figure 2.12 Exemple de transition ........................................................................................ 18 Figure 2.13 Exemple de gnration ...................................................................................... 18 Figure 2.14 Plusieurs terrains peuvent devenir plusieurs autres terrains ............................ 19 Figure 2.15 Vue continue et vue discrte du monde rel [REPRESENTATION] ..................... 20 Figure 2.16. Type de donne spatiale de MADS .................................................................... 21 Figure 2.17. Types de relation topologique dans MADS ....................................................... 22 Figure 2.18. Domaines pour lesquels les oprateurs sont dfinis......................................... 23 Figure 2.19. Type de donne temporel de MADS ................................................................. 24 Figure 2.20. Transitions possibles entre les tats dun objet ................................................ 25 Figure 2.21. Types de relation de synchronisation dans MADS ............................................ 26 Figure 2.22 Multi-reprsentation dun mme type dobjet .................................................. 27 Figure 2.23 Utilisation des cachets (Stamps) ......................................................................... 27 Figure 2.24 Fusion de deux reprsentations de routes en un type dobjet avec des cachets ........................................................................................................................................ 28 Figure 2.25 La relation de correspondance entre deux routes ............................................. 29 Figure 3.1. La suite doutils MADS ......................................................................................... 30 Figure 3.2. GUI de l'diteur de schma.................................................................................. 33 Figure 3.3. Vue du fonctionnement interne de l'diteur de schma .................................... 32 Figure 3.4. GUI du constructeur de requte .......................................................................... 34 Figure 3.5. Vue du fonctionnement interne de lditeur de requte et de loutil daffichage de rsultat de requte ................................................................................................... 35 Figure 3.6. GUI de loutil daffichage de rsultat de requte ................................................ 36 Figure 4.1 : Code XML ............................................................................................................ 38 Figure 4.2 : Arbre de l'exemple .............................................................................................. 39 Figure 4.3 : Exemple de DTD .................................................................................................. 40

82

Figure 4.4 : Exemple de schma XML .................................................................................... 41 Figure 4.5. DOM et SAX.......................................................................................................... 43 Figure 5.1. Cas dutilisation possible...................................................................................... 46 Figure 5.2. Dfinition dun schma applicatif ........................................................................ 47 Figure 5.3. Dfinition de la balise pays avec trois proprits, dont une gographique........ 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 hirarchie des types gomtriques de GML telle que dcrite par lOGC ........ 52 Figure 5.8 La hirarchie du temps ......................................................................................... 53 Figure 5.9 La fonction de distribution ................................................................................... 54 Figure 5.10 Les composants dune couverture...................................................................... 54 Figure 5.11 Les normes ISO sur lesquelles repose GML ........................................................ 55 Figure 5.12 Reprsentation graphique de lexemple ............................................................ 56 Figure 6.1 Transformation du type Interval en un type groupant deux instants .................. 62 Figure 6.2 Transformation de la structure XML du schma MADS ....................................... 63 Figure 6.3 Capture d'cran du traducteur de schma ........................................................... 64 Figure 6.4 Reprsentation dun type dobjet T en GML ........................................................ 65 Figure 6.5 Reprsentation dun hritage en GML ................................................................. 68 Figure 6.6 Relation binaire non porteuse dinformation ....................................................... 69 Figure 6.7 Relation ternaire non porteuse dinformation ..................................................... 70 Figure 6.8 Tableau de correspondance ................................................................................. 74 Figure 7.1 Design de l'interface proche des outils commerciaux. ......................................... 77

83