Navigation – Plan du site
2001
198

Couches fonctionnelles et Rôles : nouveaux concepts pour une modélisation cohérente et intégrale des informations géographiques

Functional Layers and Roles: New concepts for an integrated and coherent modelling of geographical informations
Mohamed El Adnani, Hassan El Abdelwahed, Djamal Benslimane et Kokou Yetongnon

Résumés

Les nouvelles applications spatiales telles que la cartographie électronique, la navigation multi-représentation ou les systèmes d’aide à la décision nécessitent des modèles de données puissants pour assurer le maintien de plusieurs représentations des mêmes données et la gestion d'objets spatiaux dynamiques. Dans cet article, nous présentons un modèle de données à base de couches fonctionnelles multiples. Chaque couche fonctionnelle permettant de modéliser une modélisation des données géographiques en deux niveaux : le niveau générique et le niveau domaine. Le niveau générique décrit d’une manière abstraite des fonctionnalités spatiales communes à plusieurs applications et le niveau domaine les spécialise selon les particularités de chaque application. Nous utilisons la notion de rôle pour définir des liens sémantiques et structurels qui peuvent exister entre différentes représentations des données géographiques. Afin de montrer son intérêt, nous illustrons le modèle proposé sur une application urbaine.

Haut de page

Texte intégral

1 Introduction

1.1 Contexte

1Les besoins des utilisateurs et les spécificités des applications ont une forte influence sur la modélisation des entités spatiales. Avec le développement de l'Internet, les données spatiales et géographiques sont de plus en plus accessibles et de nouveaux besoins liés au partage et à l'échange des données apparaissent. Etant donné la complexité des entités spatiales, plusieurs interprétations ou représentations d'une entité peuvent être définies et maintenues par diverses applications. Il est donc nécessaire de définir des modèles de données spatiales puissants pour permettre une gestion cohérente de plusieurs représentations des mêmes entités spatiales. Ces modèles sont appelés des modèles multi-représentations.

2La multi-représentation occupe dans les systèmes d’information géographique (SIGs) une place particulière en raison des facteurs suivants :

  • L’augmentation considérable du volume des données géographiques disponibles représentées sous diverses formes et générées à partir de sources très variées,

  • Le partage et l'échange de données entre applications qui traitent des éléments d'un espace géographique commun,

  • La complexité des données géographiques qui reflète l’extrême complexité du monde réel,

  • La résolution ou l’échelle qui agit sur le contenu et la caractérisation des données géographiques,

  • Les facettes multiples des données géographiques qui traduisent la diversité des besoins des utilisateurs,

  • L’évolution et l’aspect dynamique des données géographiques.

1.2 Problématique abordée

3Les systèmes d’information géographique, en particulier ceux dédiés aux applications urbaines, organisent les données relatives à un même territoire sous forme de couches fonctionnelles. Chaque couche traite d’un ou de plusieurs thèmes et elle est définie par un ensemble d’objets géographiques homogènes ayant le même type spatial de base (point, ligne ou zone) [SCHO96]. Par exemple les thèmes ‘cadastre’, ‘patrimoine municipal’ ou ‘réseaux d’adduction d’eau, d’assainissement, de lignes téléphoniques’, partagent le même territoire qui est celui d’une commune. Par conséquent, une même entité réelle pourra avoir des représentations différentes selon chaque thème choisi. Pour une gestion cohérente et intégrale, la base de données doit maintenir pour une même entité plusieurs représentations. C’est une base de données dite multi-représentation [SPAC00, JONE96, VANG98, TIMP95].

4La multi-représentation des données spatiales pose plusieurs problèmes liés à la modélisation et à la gestion de données. Parmi ces problèmes nous pouvons citer :

  • La redondance des données : une même information est présente en plusieurs exemplaires sous une forme qui varie en fonction de la représentation. Les problèmes classiquement soulevés par la redondance apparaissent, notamment les risques d’incohérence et la difficulté d’effectuer des mises à jour [SCHO96],

  • L’optimisation des coûts d’accès aux données : ceci nécessite l’organisation des données multi-représentation et la coordination des opérations les manipulant [DEVO98, BRUG89]. Il s’agit de spécifier les conditions d’application des processus d’interrogation, d’analyse et de visualisation de données spatiales dans un contexte de multi-représentation [CLAR98],

  • Liens entre représentations : ceci est basé sur la définition et la gestion des consistances associées aux liens sémantiques qui existent entre les différents niveaux de la multi-représentation [BUTT93, BEAR91, DEVO98],

  • La cohérence globale des données : ceci nécessite l’intégration d’une base de connaissances pour produire des règles d’expertise garantissant la cohérence globale de la base de données [MARK91].

1.3 Quelques solutions existantes

5Dans cette section, nous décrivons très brièvement quelques solutions proposées pour la gestion de la multi-représentation dans les bases de données spatiales.

1.3.1 Solution à base de vue

6La notion de vue est initialement conçue pour décrire des schémas externes qui permettent la définition de sous-schémas personnalisés du schéma de la base de données d’origine [ANSI75]. Les opérateurs algébriques tels que la sélection, la projection ou la jointure, permettent la construction de vues différentes pour répondre aux besoins des utilisateurs.

7Dans les systèmes d'information géographique, la notion de vue est étendue à la notion de vue spatiale pour permettre la représentation des données géographiques selon différents points de vue et en fonction d’objectifs spécifiques à diverses applications [CLAR98]. Les opérateurs de construction des vues spatiales sont aussi étendus pour intégrer la composante spatiale des données géographiques.

8Les vues spatiales apportent la flexibilité nécessaire pour avoir des schémas de bases de données spatiales évolutifs et facilement extensibles. Toutefois, la composante spatiale des éléments des vues spatiales doit être la même que celle des éléments de base dont la vue est dérivée. Par conséquent, le mécanisme de vue spatiale n’est pas approprié si la nouvelle représentation spatiale souhaitée n’est pas ‘copiable’ d’une représentation déjà connue [VANG98]. Dans ce cas, la nouvelle représentation ne peut que s’ajouter à l’existante pour constituer une représentation de base.

9D’autre part, les opérations de mise à jour ne sont pas toutes applicables sur les vues. En effet, les vues qui sont définies par des opérations de jointure ne peuvent être utilisées que pour la consultation. Les opérations d’insertion et de modification ne sont pas permises et la propagation des mises à jour ne peut donc être assurée.

1.3.2 Solution à base d'ontologie

10D’après Gruber [GRUB95], une ontologie est une spécification explicite d’une conceptualisation d’un domaine d’application. Elle permet d’identifier par un processus d’abstraction les concepts ou les termes essentiels du domaine et rend explicite la sémantique ou le sens associé aux termes [LECL00].

11Cette définition est étendue aux ontologies spatiales qui sont utilisées pour représenter à un niveau d’abstraction élevé des concepts spatiaux en termes génériques. Ces termes sont ensuite spécialisés par différents acteurs pour représenter leur vision spécifique des concepts spatiaux de base [BENS00, FONS99].

12La solution à base d’ontologies est efficace en particulier pour assurer l’interopérabilité ou la coopération sémantique entre des SIG. Dans le cas où ces derniers sont tous relatifs à un même espace géographique, le système dans sa globalité devient un système qui gère plusieurs représentations différentes des mêmes objets géographiques. Chaque représentation reflète les besoins spécifiques d’un groupe d’utilisateurs.

13Comme pour la solution à base de vue, cette solution ne garantit pas la gestion efficace de la propagation efficace des mises à jour. En effet, les liens entre les différentes représentations ne sont pas définis explicitement. Ceci ne facilite pas l’identification de toutes les représentations d’une entité réelle.

1.3.3 Solution à base d'intégration

14L’intégration de plusieurs bases de données géographiques décrivant un même espace géographique consiste à produire [DEVO98] :

  • une description unifiée des schémas des bases de données d’origines (le schéma fédéré),

  • des règles de traduction pour la migration des données,

  • des liens entre différentes représentations d’objets qui modélisent les mêmes entités réelles (appariement géométrique).

15L’objectif est de rendre interopérable des bases de données initialement indépendantes pour permettre une réutilisation des données mémorisées dans chacune de ces bases de données.

16La base de données ainsi construite par intégration peut être considéré comme une base de données multi-représentation. Le schéma fédéré décrit pour chaque entité réelle une représentation unifiée de toutes ses représentations possibles. L’appariement géométrique assure le lien entre les différents objets représentant cette même entité. Ceci facilite la propagation automatique des mises à jour et par conséquent la résolution des requêtes multi-thèmes.

17La seule limite de cette solution est liée à la complexité ou l’impossibilité de construction d’un schéma fédéré unifiant toutes les représentations possibles des entités réelles.

1.3.4 Solution à base de rôle

18Le concept de rôle a été utilisé dans les bases de données classiques pour modéliser les différents rôles, facettes ou aspects d’une entité [LI98, RICH91, WIER94, PAPA97]. L’exemple classique d’une entité avec plusieurs rôles est celui d’une personne qui passe de l’état d’étudiant à l’état de fonctionnaire puis à celui de directeur. Chaque rôle (étudiant, fonctionnaire ou directeur) correspond à une facette de l’entité réelle (la personne). L'entité est alors représentée par une structure commune qui est complétée par des informations relatives à ses différentes facettes [GENT96].

19La notion de rôle offre donc une solution pour le support de la multi-représentation en permettant à chaque entité réelle d’être représentée par un ensemble d’objets ou instances appartenant à différentes classes qui correspondent au rôle de l’entité. Toutefois, cette notion est très peu utilisée par la communauté des SIG parce que jusqu’à maintenant il n’existe pas une normalisation de ce concept permettant la définition exacte des structures de données offertes et des opérations les manipulant.

1.4 Travail proposé

20D’après [JONE96], les objectifs majeurs qu’il faut garantir lors de la conception d’une base de données multi-représentation incluent :

  • Le maintien de l’intégrité de la base de données dans sa globalité,

  • La réduction du coût des opérations de mise à jour en garantissant leur propagation automatique de manière efficace,

  • L’automatisation des accès aux données spatiales sous leurs différentes représentations.

21Dans cet article, nous proposons un modèle qui permet l’intégration des différentes représentations que peut avoir un espace géographique dans une seule base de données.

22Notre approche est basée sur l'hypothèse que pour tout espace géographique (un domaine urbain par exemple) il existe une abstraction spatiale basée sur un ensemble de fonctionnalités prédéterminées permettant la classification des différentes applications qui agissent sur cet espace géographique. Cette classification est réalisée à base d’intérêts et de besoins communs selon les fonctionnalités des SIGs. Par exemple, les applications de gestion des réseaux routiers, des réseaux téléphoniques ou des réseaux électriques sont toutes des applications basées sur la gestion de flux dans un réseau.

23Ces applications partagent les mêmes fonctionnalités et peuvent s’articuler sur un nombre limité de concepts spatiaux et d’opérations globales sur les réseaux. Ces concepts spatiaux peuvent être spécialisés et détaillés par chaque application suivant ses intérêts spécifiques pour construire une interprétation précise de l’espace géographique commun.

24En se basant sur ce constat, nous proposons un modèle de données à couches fonctionnelles multiples. Chaque couche fonctionnelle est définie en deux niveaux : le niveau générique et le niveau domaine.

25Dans la section suivante, nous présenterons en détail ces différents niveaux en commençant d’abord par l’explication du principe de base (section 2) puis nous donnerons les définitions respectives (section 3).Le reste de l’article est organisé comme suit : la section 2 présente les principes de base de la modélisation à couches fonctionnelles multiples. La description détaillée des concepts du modèle fait l’objet de la section 3. La section 4 décrit les relations qui peuvent exister entre les différentes couches fonctionnelles. Une mise en œuvre dans le domaine urbain du modèle proposé est présentée en section 5. Enfin, nous concluons cet article et présentons quelques perspectives de recherche en section 6.

2 Principe du modèle à couches fonctionnelles multiples

26Dans notre modèle, nous faisons la distinction entre objet spatial et objet géographique. Un objet spatial décrit seulement les propriétés géométriques telles que la forme ou la position spatiale (Point ou Ligne par exemple), alors qu’un objet géographique décrit en plus des propriétés géométriques d’autres propriétés spécifiques à une application donnée. Par exemple pour une route, les propriétés spécifiques (non géométriques) peuvent être le type de la route (nationale, départementale, …), son état, sa largeur et sa date de construction.

27Toutes les applications géographiques se basent sur un nombre limité d’objets spatiaux de bases : les primitives géométriques. La description des propriétés de ces primitives ainsi que les associations les reliant sont réalisées au niveau de la couche géométrique de base (section 3.2).

28En plus des primitives géométriques, le modèle permet la définition de plusieurs couches fonctionnelles (figure 1). La définition de la géométrie des éléments composant les couches fonctionnelles s'appuie sur les primitives géométriques. Chaque couche fonctionnelle est composée de deux niveaux : un niveau générique et un niveau application. Le niveau générique décrit :

  • des fonctionnalités qui sont communes à un groupe d’applications (gestion des réseaux par exemple),

  • des concepts et des opérations qui représentent à un niveau d'abstraction élevé un consensus global entre les différentes applications du même groupe.

29Le niveau application est composé de couches domaines correspondant aux différentes applications ayant les mêmes fonctionnalités du niveau générique.

Figure 1 : Schéma des couches fonctionnelles

Figure 1 : Schéma des couches fonctionnelles

30Les couches domaines sont dérivées des couches génériques par un processus de dérivation. Une couche domaine est relative à une seule application et traite un seul thème. Elle découle tout simplement du niveau générique par un processus de dérivation.

31Dans notre modèle, nous avons adopté la notion de dérivation à base de rôle pour établir le lien entre les différentes couches. Cette notion étend l’association Est_un du modèle objet pour permettre essentiellement l’héritage sélectif et l’instanciation multiple des objets.

3. Présentation du modèle

3.1 Les couches fonctionnelles

32Une couche fonctionnelle décrit un ensemble d'applications ou de domaines d'applications qui partagent des fonctionnalités abstraites communes. Elle est composée d'une couche générique et des couches domaines qui en dérivent.

3.1.1 Définition d'une couche générique

33Une couche générique définit un ensemble de concepts permettant la spécification d’un groupe d’applications ayant les mêmes fonctionnalités. Elle comprend deux catégories de types : les types géométriques et les types génériques. Les types géométriques sont un ensemble de types sélectionnés parmi les types du modèle géométrique de base (section 3.2). Ces types permettent la définition de la géométrie des éléments de la couche générique. Pour la couche réseau générique (CRG) par exemple, les types géométriques sélectionnés sont : le type Point et le type Segment. Les types génériques sont définis par spécialisation de types géométriques sélectionnés. Ce qui permet à un type générique d'hériter les propriétés géométriques à partir d’un type géométrique de base. Pour compléter la définition des types génériques, d'autres propriétés ou informations spécifiques à un ensemble d'applications sont ajoutées. Par exemple, dans la couche CRG nous définissons les types génériques PointRés et SegmentRés par spécialisation des types géométriques Point et Segment.

34Plusieurs opérations génériques sont définies pour spécifier les fonctionnalités de base relatives à la couche générique. Pour la couche CRG par exemple, les opérations permettant la recherche de chemins entre deux points, le calcul du plus court chemin ou l'évaluation des coûts de parcours sont des opérations attachées au type Réseau générique.

35Des axiomes fonctionnels génériques sont définis pour établir des règles de cohérence sémantique agissant sur les types et les opérations génériques pour spécifier leurs propriétés. Pour la couche CRG, les axiomes suivants peuvent être définis : 'la distance entre deux points équivalents est nulle', 'le chemin entre deux points différents et connexes contient au moins un segment',... etc.

36Dans la suite de cette section, nous décrirons les composants d’une couche générique que sont : les types génériques et les classes génériques.

3.1.1.1. Types Génériques 

37Un type générique Tg est défini par le tuple <Nom, Op, Ax> avec :

  • Nom : le nom du type générique,

  • Op : l’ensemble des opérations définissant le comportement du type. Ces opérations sont soit des opérations géométriques (héritées des types de la couche géométrique de base), soit des opérations génériques relatives aux fonctionnalités de la couche générique,

  • Ax : l’ensemble des règles pour maintenir la cohérence au niveau de la structure et des opérations définies sur le type Tg.

38Exemple : Pour la couche CRG, nous définissons le type générique Réseaux par :

3.1.1.2. Classe Générique

39Une classe générique est une classe abstraite (sans instances explicites) associée à un type générique. Elle constitue le réceptacle d’un ensemble de classes domaines qui lui sont liées par dérivation (le lien Est_rôle_de). Ce lien permet essentiellement le maintien d’une association sémantique et structurelle entre les différentes représentations que peut avoir une entité réelle.

40Une classe générique Cg est définie par le tuple <Nom, Att, Méth, Axiomes> avec :

  • Nom : le nom de la classe,

  • Att : les attributs de la classe (attributs géométriques hérités ou attributs spécifiques),

  • Méth : l’ensemble des méthodes définies sur cette classe (méthodes géométriques héritées ou méthodes spécifiques),

  • Axiomes : contraintes à vérifier sur la définition en extension de la classe générique.

41Les associations que peut avoir une classe générique sont de deux types :

  • les associations avec les autres classes génériques : une classe générique peut être liée à plusieurs classes génériques qui appartiennent à des couches fonctionnelles différentes,

  • les associations avec les classes domaines : Une classe générique est liée à un ensemble de classes domaines par un lien de dérivation (voir la section 3.3.).

Exemple : Définition de la classe générique SegmentRés.

Exemple : Définition de la classe générique SegmentRés.

3.1.2 Définition des couches domaines

42Les couches domaines sont dérivées à partir des couches génériques pour définir des applications spécifiques. Ces applications doivent partager les concepts et les fonctionnalités décrites par la couche générique de base.

43Les éléments définissant une couche domaine sont des éléments spécifiques à l’application correspondante. Par exemple, les descriptions des éléments définissant les applications de réseau (routier, d'eau potable, d’assainissement), du cadastre, de l’occupation du sol, ... etc, sont dérivées de celles des éléments génériques PointRés, SegmentRés, Réseaux … etc de la couche générique correspondante.

44Les éléments des couches domaines représentent des interprétations différentes des éléments des couches génériques. Par exemple l'entité générique PointRés sera interprétée au niveau de la couche domaine Réseaux Routiers par des entités spécifiques : Place, Carrefour, Croisement, Vanne, Jonction, ... etc. De même l'entité générique SegmentRés sera interprétée par les entités : Tronçon, Avenue, Boulevard, Canalisation, ... etc.

45Formellement une couche domaine est définie par : Cdom = ( < C, ≤ > , Ax ) avec :

  • < C, ≤ > : un ensemble de classes ordonnées selon la relation d’héritage ≤ . Ces classes sont appelées classes domaines.

  • Ax : un ensemble d'axiomes qui permettent d’affecter une sémantique aux attributs des classes de C.

46Une classe domaine c de l’ensemble C est définie par : < Nom, Attr, Meth> avec :

  • Nom : nom de la classe,

  • Attr : ensembleliste des attributs de la classe domaine c,

  • Meth : ensemble des méthodes définies sur la classe c.

47Les classes domaines représentant les différentes interprétations d’un type générique sont regroupées par le lien de dérivation (section 3.4).

Figure 2 : Modèle géométrique simplifié

Figure 2 : Modèle géométrique simplifié

3.2 Définition géométrique de base

48Les modèles géométriques conçus pour les applications géographiques se basent sur trois primitives géométriques : le Point, la Ligne et la Surface. Plusieurs modèles sont proposés dans la littérature [PEUQ84, SAME90, LAUR93, ELAD94]. Ils se distinguent par le détail apporté au niveau des propriétés de ces trois primitives et par les relations topologiques qui leurs sont attachées.

49Pour définir les éléments de la couche fonctionnelle, nous proposons un modèle géométrique simplifié qui permet la définition des types géométriques selon les deux représentations les plus utilisées : la représentation Vecteur ou Spaghetti et la représentation Topologique (figure 2). Les différents types géométriques sont organisés en une hiérarchie ou graphe d’héritage qui permet de définir de nouveaux types à partir de types existants (généralisation/spécialisation).

50Au niveau de cette couche, ne sont décrites que les propriétés géométriques sans aucune indication des propriétés géographiques. Ces dernières seront ajoutées d’une manière progressive d’abord au niveau de la couche générique (des propriétés communes à un groupe d’applications) puis au niveau des couches domaines (des propriétés géographiques et non géométriques spécifiques aux domaines).

3.3 La dérivation à base de Rôle

51Le lien de dérivation Est_Rôle_de établit une association entre une classe générique et un ensemble de classes domaines appartenant à des couches domaines différentes. Ce lien se base sur la notion de rôle qui étend la notion classique d’objet afin de :

  • permettre à un objet d’avoir simultanément plusieurs instances de classes différentes (rôles),

  • gérer dynamiquement la création, la suppression et la manipulation des rôles.

52Dans la suite de cette section, nous présentons d’abord la notion de rôle dans les bases de données (section 3.3.1), puis nous décrivons comment le lien de dérivation est modélisé par cette notion (section 3.3.2).

3.3.1 Présentation informelle de la notion de rôles dans les bases de données objet

53Dans le modèle orienté objet, chaque objet est lié à une seule classe de manière exclusive et permanente. C’est cette classe qui détermine sa structure et son comportement et définit ainsi son rôle unique. Or, dans la réalité, un même objet peut acquérir ou perdre divers aspects structurels ou comportementaux au cours de son existence. L’évolution de tels objets doit donc obligatoirement être prise en compte par le modèle de données. Malheureusement, le modèle objet standard ne tient pas compte de cet aspect.

54L’objectif des modèles objet à rôles [RICH91, GOTT96, ALBA93, GHEL99, PAPA97, COUL00] est d’étendre le modèle objet pour permettre à tout objet :

  • de suivre son évolution en acquérant ou en perdant des rôles et par conséquent de changer de structure et de comportement pendant son cycle de vie,

  • de posséder plusieurs rôles en même temps,

  • d’avoir un comportement variable selon le rôle joué.

55La gestion de la notion de rôle constitue un sujet de recherche actuel comme en témoigne les nombreuses publications tant en conception, modélisation des systèmes à objets, qu’en représentation des connaissances, langages de programmation et bases de données [COUL00].

56Dans notre modèle, nous avons intégré la notion de rôle tout en restant dans le contexte des modèles objets standards de l’ODMG (Object Database Management Group) [CATT93]. La présentation détaillée des différentes notions adoptées sort du cadre de cet article. Néanmoins, nous présentons ci-dessous, les principales caractéristiques de notre approche.

Figure 3 : Modélisation d’une route, a) au niveau classes, b) au niveau instances

Figure 3 : Modélisation d’une route, a) au niveau classes, b) au niveau instances

Les entités réelles et les rôles

57Une entité réelle peut être représentée par un objet (ayant un identificateur unique) et par l’ensemble des objets rôles qu’elle peut jouer durant sa vie. L’objet modélise de façon unique l’entité réelle avec les propriétés invariables quel que soit le rôle joué. Prenons l’exemple cité dans [SCHO96] d’une route vue selon trois utilisateurs différents : un cartographe, un ingénieur des Ponts et Chaussées et un régulateur de circulation. Chaque utilisateur a une vision particulière de la même entité réelle. Dans notre modèle, cette entité sera modélisée par un objet de la classe Route. Cet objet a trois rôles qui sont des instances des classes rôles CartoRoute, IngRoute et GrapheRoute (figure3). La classe Route modélise les propriétés (attributs et méthodes) invariables des routes, alors que les classes rôles modélisent les particularités relatives à chaque utilisateur.

La hiérarchie des rôles de classes

58La hiérarchie des classes est étendue par une hiérarchie de classes rôles HCR (figure 3 (a)). La racine d’une HCR est une classe et les sous classes représentent ses différents rôles (les classes rôles). La figure 3 montre une hiérarchie de classes rôles HCR dont la racine est la classe Route et les classes rôles sont CartoRoute, IngRoute et GrapheRoute.

La hiérarchie des objets rôles

59Une hiérarchie d’objets rôles HOR est induite de la HCR (figure 3 (b)). La racine de cette HOR est un objet instance d’une classe et tous les sous-objets représentent des rôles de l’objet racine. Une HOR peut être définie comme une instanciation d’une HCR.

Les opérations sur les rôles

60Plusieurs opérations sont définies sur les rôles pour faciliter leur gestion de manière dynamique [RICH91, GOTT96]. Parmi ces opérations nous pouvons citer : la création/suppression de rôles, la recherche des différents rôles d’un objet, le changement de rôle et le test sur les rôles (équivalence de rôles, existence).

3.3.2 Le lien de dérivation Est_rôle_de

61Dans notre modèle, le lien de dérivation Est_rôle_de est d’une importance primordiale. C’est une association qui permet d’établir le lien entre une classe générique et l’ensemble des classes domaines qui en dérivent. Ce lien est matérialisé par une HCR dont la racine est une classe générique et les sous-classes sont les classes domaines.

62Les caractéristiques principales du lien Est_rôle_de entre une classe générique Cgén et une classe domaine Cdom sont :

  • l’héritage sélectif des attributs et des méthodes entre la classe Cdom et la classe Cgén. Autrement dit, il est possible d’avoir :
    liste_att(Cgén) ⊄ liste_att(Cdom ) et liste_mét(Cgén ) ⊄ liste_mét(Cdom),

  • la population de la classe Cdom est incluse d’une manière indirecte dans celle de la classe Cgén. En effet, pop(Cgén) = {Oidi} avec les Oidi sont les identifiantscateurs d’objets, et sur chaque objet Oidi la fonction popRole(Oidi) retourne les identificateurs Oidrj des rôles d’objets (instances des classes domaines) liés à l’objet Oid (éléments de la HOR(Oidi)).

4 Relations inter-couches fonctionnelles

63Des relations inter et intra-couches fonctionnelles sont définies pour établir les associations spatiales entre les objets. Ces relations sont définies soit entre des objets différents appartenant à la même couche générique ou à différentes couches génériques, soit entre les différentes représentations d’un même objet dans différentes couches. Par exemple, une instance de la classe Route (figure 3) peut être représentée par plusieurs instances de classes rôles. Ces dernières sont des classes domaines qui appartiennent à des couches domaines différentes ou même à des couches génériques différentes.

64Deux types de relations sont à distinguer : la relation d’équivalence et la relation d’agrégation.

Figure 4 : Les différentes relations inter-couches

Figure 4 : Les différentes relations inter-couches

4.1 La relation d’équivalence

65Une relation d’équivalence établit une association entre les instances des classes domaines qui décrivent chacune une interprétation spécifique d’une même entité géographique. Cette relation peut être définie par le tuple r = <C1, C2, …, Cn> où les Ci sont des classes domaines. Nous distinguons deux cas de figures : le cas où toutes les classes domaines Ci sont de la même couche générique et le cas où elles appartiennent à des couches génériques différentes.

Relation d’équivalence intra-couche générique

66Toutes les classes domaines Ci opérandes de la relation d’équivalence dérivent d’une même classe générique Cgén. Elles constituent une partie de la hiérarchie HCR(Cgén). Les instances des classes domaines qui représentent des interprétations différentes d’une même entité réelle, sont des éléments de la hiérarchie HOR de cet objet. Par exemple, deux objets Iv1 et Icr1 respectivement instances des classes Vanne et Croisement_Route (figure 4) peuvent représenter deux interprétations possibles d’un même objet spatial Opgén (instance de la classe générique PointRés). La relation d’équivalence entre les objets Iv1 et Icr1 est déduite de la HOR(Opgén).

Relation d’équivalence inter-couches génériques

67Dans le cas où une entité réelle (représentée par l’objet Opgén par exemple) a comme interprétation un objet domaine (Oplace1) instance d’une classe domaine (Place) n’appartenant pas à la même couche générique, la relation d’équivalence est étendue pour associer des classes appartenant à deux couches fonctionnelles différentes. Dans ce cas, la classe Place par exemple, sera définie par une dérivation multiple de deux classes génériques : la classe PointRés et la classe Couverture. L’objet Oplace1 sera donc élément de la HOR(Opgén) et de la HOR(Ocouv) avec Ocouv l’objet instance de la classe générique Couverture (figure 5).

Figure 5 : Relation d’équivalence inter-couches

Figure 5 : Relation d’équivalence inter-couches

4.2 La relation d’agrégation

68La relation d’agrégation est un cas particulier de la relation d’équivalence puisqu’elle permet d’étendre l’association 1-1 définie par cette dernière à une association 1-n entre les instances domaines de différentes classes. Elle représente le cas où une entité réelle est décrite globalement par une instance d’une classe domaine et de façon fragmentée par un ensemble d’instances d’une (ou plusieurs) autre(s) classe(s). Par exemple (figure 4), une instance Ih de la classe Hôpital peut correspondre à un ensemble d’instances de la classe Bâtiment <Ib1, Ib2, …, Ibn>. La relation d’agrégation est modélisée dans ce cas, par l’association Est-composé-de qui relie l’objet rôle Ih de la classe Couverture à l’ensemble des objets rôles <Ib1, Ib2, …,Ibn> de la classe Bâtiment. La géométrie de l’objet Ih peut être déduite directement de celle de l’objet Icouv (instance de la classe Couverture d’où est dérivée l’objet Ih) ou calculée comme agrégat des géométries des objets <Ib1, Ib2, …, Ibn>.

5 Application aux systèmes d’information urbains

69La complexité des systèmes d’information urbains (SIU) réside dans le fait qu’ils traitent, pour un même domaine géographique, des thèmes différents. Une même donnée peut être représentée et gérée différemment selon le thème choisi. Pour une modélisation cohérente et intégrale des SIU, nous proposons la modélisation en trois couches fonctionnelles : Point, Réseaux et Couverture (figure 6). Chaque couche fonctionnelle est définie au niveau générique et au niveau domaine.

Définition de la couche fonctionnelle point

70La couche fonctionnelle point est constituée d’une couche générique point (CGP) et de l’ensemble des couches domaines point (CDP) qui en dérivent. Pour l’espace urbain, les couches domaines CDPs représentent chacune un thème dont les éléments sont tous de type Point.

71Un point générique peut avoir plusieurs interprétations selon différentes applications. Par exemple, un point peut représenter en même temps la position d’un panneau d’affichage, d’un détecteur de niveau de pollution et/ou d’une toilette publique. Chaque interprétation est représentée par une instance dérivée du point générique et appartenant à une CDP. Un lien est donc maintenu à travers la classe générique entre les différentes interprétations possibles d’un même point. Ces différentes applications peuvent utiliser les mêmes concepts ou opérations génériques qui sont décrits au niveau de la couche CGP tels que le calcul de la distance entre les points, le calcul du taux de recouvrement ou la conversion des coordonnées de positionnement d’un point en un autre système de référence.

Figure 6 : Les couches fonctionnelles relatives à un espace urbain

Figure 6 : Les couches fonctionnelles relatives à un espace urbain

Définition de la couche fonctionnelle réseau

72La couche fonctionnelle réseau permet la description d’applications réseaux d’un espace urbain telles que la gestion du réseau d’adduction d’eau, du réseau d’assainissement, du réseau téléphonique ou du réseau routier.

73Comme pour la couche fonctionnelle Point, une couche générique réseaux (CGR) est définie pour décrire les concepts communs à toutes les applications réseaux.

74Les éléments permettant la définition de la couche générique CGR sont le PointRés et le SegmentRés. Les opérations globales définies au niveau de cette couche sont les opérations de gestion des graphes telles que la recherche de chemins, le calcul du coût d’un parcourt …etc.

75Les couches domaines réseaux qui dérivent de la couche réseau générique décrivent chacune une application réseau bien précise.

76Dans le contexte de la multi-représentation, plusieurs objets appartenant à différentes couches domaines peuvent représenter des interprétations différentes d’une même entité réelle. Par exemple, un croisement de routes dans la couche domaine réseaux routiers peut correspondre à l’emplacement d’une vanne dans la couche domaine réseaux d’eau ou un multiplexeur téléphonique dans une couche domaine réseaux téléphoniques.

Définition de la couche fonctionnelle couverture

77La couche fonctionnelle couverture permet la description des applications sur un espace urbain dont les éléments sont de type Surface. Parmi les exemples de telles applications nous pouvons citer : la gestion des parcelles, la gestion des zones vertes ou la gestion des zones commerciales.

78La couche générique couverture définit des objets surfaciques d’une manière abstraite en précisant les différentes opérations qui leurs sont applicables. Les méthodes attachées à ces objets surfaciques sont des méthodes globales relatives aux opérations effectuées sur les surfaces telles que le calcul du périmètre ou le calcul de la surface.

79Les couches domaines attachées à la couche couverture générique définissent les différentes interprétations que peut avoir un objet surfacique de la couche surface générique. Dans l’espace urbain par exemple, un objet surfacique générique peut être lié aux objets des couches domaines bâtiments administratifs, parcs publiques ou domaine des hôpitaux.

6 Conclusion

80Nous avons présenté dans cet article un modèle de données à base de couches fonctionnelles multiples pour la gestion cohérente des bases de données géographiques multi-représentations. Les couches fonctionnelles sont définies en deux niveaux : le niveau générique et le niveau domaine. Le niveau générique décrit les concepts globaux nécessaires pour la définition d’un ensemble de domaines qui ont des fonctionnalités spatiales communes. La définition de ces concepts globaux s'appuie sur un ensemble de types géométriques qui permettent une description de la géométrie des objets des deux niveaux. Les particularités de chaque domaine sont décrites au niveau domaine.

81Nous avons intégré la notion de rôle dans notre modèle pour définir explicitement les liens entre les différentes représentations possibles des mêmes entités réelles. Pour montrer comment ces liens sont maintenus, nous avons étudié le cas de la relation d’équivalence et le cas de la relation d’agrégation. Ceci garantit une gestion cohérente de l’ensemble de la base de données en permettant, entre autres, la propagation automatique des mises à jours et l’interrogation multi-thématiques de la base de données.

82L’intérêt de l’approche proposée pour la gestion des données multi-représentations repose sur deux plans. :

83Sur le plan conceptuel : la conception des applications spatiales acquière une souplesse remarquable principalement grâce à :

  • la démarche conceptuelle en deux niveaux, : générique puis domaine, facilitant la conception des nouvelles applications en se basant sur la réutilisation des concepts de base déjà définis,

  • l’intégration de la notion de rôle qui rend la conception plus ‘naturelle’ en permettant de modéliser aisément des objets multi-représentations et/ou évolutifs.

84Ces deux caractéristiques permettent à notre modèle de s’adapter à divers domaines d’applications, en particuliers les SIGs temporels et évolutifs, l’interopérabilité des SIGs et la multi-représentation dans les SIGs qui est mieux détaillée dans de ce papier.

85Sur le plan gestion de données : les deux principaux avantages qu’assure notre modèle sont : la cohérence globale de la base de données et la gestion intégrale des données. Ces deux avantages sont la conséquence immédiate du maintien d’un lien structurel et sémantique permettant de regrouper un objet avec toutes ses représentations possibles (ses rôles). Ce qui facilite le contrôle de la cohérence, la propagation des mises à jours et la gestion des requêtes à thèmes multiples.

86L’exemple de la gestion urbaine que nous avons décrit à la fin de cet article, montre comment les concepts du modèle s'appliquent à la réalisation d'applications à caractère multi-représentation. Nous avons proposé trois couches fonctionnelles : la couche Point, la couche Réseaux et la couche Couverture, puis nous avons présenté quelques exemples de couches domaines applicatives.

87Les perspectives de notre travail sont nombreuses. D’une part, nous cherchons à définir formellement le modèle de données à travers une algèbre pour aborder le volet de l’interrogation simple ou multi-thèmes de la base de données. D’autre part, le modèle peut être étendu pour supporter l’interopérabilité entre des SIGs distants en intégrant des concepts de représentation sémantique tel que les ontologies spatiales.

Haut de page

Bibliographie

[ALBA93] A. Albano, R. Bergamini, G. Ghelli, R. Orsini, An object data model with roles, Proc. Of the 19th VLDB Conference Dublin, Irland, 1993, Rakesh Agrawal, Sean Baker, david Bell editors, Morgan Kofmann Publishers, San Mateo, CA, USA. pp. 39-51.

[ANSI75] ANSI-X3/SPARC Stady Group on Data Base Manafement System, Technical Report, ACM SIGMOD, 7(2), 1975.

[BEAR91] K. Beard, Constraints on Rule Formation. In : B. Buttenfield and R. McMaster (Ed.), Map Generalization : Making Rules for Knowledge Representation, pp. 121-135, Wiley, New York, NY, 1991.

[BENS00] D. Benslimane, E. Leclercq, M. Savonnet, M.N. Terrasse, K. Yétongnon, On the definition of generic multi-layered ontologies for urban applications, International Journal of Computers, Environment and Urban Systems, Volume 24, Elsevier Science Ltd, England, pp. 191-214, 2000.

[BRUG89] B. P. Bruegger , A. U. Frank, Hierarchies over Topological Data Structures, ASPRS/ACSM Annual Convention, Baltimore, MD, pp. 137-145, 1989.

[BUTT93] B. P. Buttenfield, Multiple Representations – Closing Report, National Center for Geographic Information and Analysis- NCGIA, UCSB Santa Barbara, CA, Technical Report, 1993.

[CATT93] R. Cattell (Ed.), Object Databases : The ODMG-93 Standard, Morgan Kaufman, San Matéo, CA, 1993.

[CLAR98] C. Claramunt, Un modèle de vues spatiales pour une représentation flexible de données géographiques, Thèse de doctorat de l’Université de Bourgogne, 1998

[COUL00] S. Coulondre, SAMOVAR : un modèle pour les objets persistants avec les rôles, rapport de Thèse d’Université, Université Montpellier II, France, Décembre 2000,

[DEVO98] T. Devogele, C. Parent, S. Spaccapietra, On Spatial databe integration, International Journal of Geographic Information Systems, V. 12, N° 4, pp. 335-352, 1998

[ELAD94] M. EL Adnani , Spatio2 : un modèle orienté objet généralisé pour les systèmes d’informations spatiales, Thèse d’Université, Université Blaise Pascal, Clermont Ferrand, France , Décembre 1994.

[FONS99] F. T. Fonseca, M.J. Egenhofer, Ontology-Driven Geographic Information Systems, 7th. ACM Symposium on Advances in Geographic information Systems, Kansas City, MO. C. Banzer Medeiros (ed.), pp. 14-19, November 1999

[GENT96] M. Gentile, An object-oriented approach to manage themultiple representations of real entities, Thèse N° 1490, Lausanne, EPFL, 1996,

[GHELL99] G. Ghelli, D. Palmerini, Foundation for Extensible Objects with Roles Extended Abstract, Proceeding of the 6th Workshop on Foundation of Object Oriented Langages (FOOL), san Antonio, Texas 1999,

[GOTT96] G. Gottlob, M. Schrefl, B. Röck, Extending Object-Oriented Systems with Roles, ACM Transaction on Information Systems, Vol. 14, No. 3, pp. 268-296, July 1996,

[GRUB95] T. Gruber: Towards principles for the design of ontologies used for knowledge sharing. International Journal of Human and computer studies, Vol 43, n°5, pp. 907-928, 1995.

[JONE96] C. B. Jones, D.B. Kidner, L.Q. Luo, G.L. Bundy, J.M. Ware, Database design for a multi-scale spatial information system, International Journal of Geographical Information Systems, 10(8),pp901-920, 1996,

[LAUR93] R. Laurini, F. Milleret-Raffort, Les bases de données en géomatique. Traités des nouvelles technologies, série Géomatique, Edition HERMES, 1993

[LECL00] E. Leclerq, Interopérabilité sémantique des systèmes d'information géographique : une approche basée sur la médiation de contexte, Thèse de Doctorat, Université de Bourgogne, Dijon, 2000.

[LI98] Qing Li, Frederick H. Lochovski, ADOME : An Advanced Object Modeling Environment, IEEE Transaction on knowledge and data engineering, vol. 10, NO. 2, pp.255-276, 1998

[MARK91] D. Mark, Object Modelling and Phenomenon-Based Generalization, in : B. Buttenfield and R. McMaster (Ed.), Map Generalization : Making Rules for Knowledge Representation, pp. 103-118, Wiley, New York, NY, 1991.

[PAPA97] M.P. Papazoglou, B.J. Krämer, A Database Model for Object Dynamics, VLDB Journal, Vol. 6, 1997.

[PEUQ84] Peuquet, D. J., A conceptual framework and comparison of spatial data models, Cartographica, 21 (4), pp. 66-113, 1984,

[RICH91] J. Richardson, P. Schwartz, Aspects : extending objects to support Multiple, Independent roles, Proc. ACM SIGMOD Int’l Conf. Management of Data, pp. 298-307, 1991.

[SAME90] Samet, H., The Design and Analysis of Spatial Data Structures, Addison Wesley, New York, 1990,

[SCHO96] M ; Scholl, A. Voisard, J. P. Peloux, L. Raynal, P. Rigaux, SGBD géographiques, Spécificités, International Thomson Publishing France, Paris 1996

[SPAC00] S. Spaccapietra, C. Parent, C. Vangenot, GIS Databases : Frome Multiscale to MultiRepresentation, Proceeding of the International Workshop on Emerging technologies for Geo-Based Applications, May 22-25 2000, Ascona, Switzerland, EPFL-DI-LBD Publisher,

[TIMP95] S. Timpf, A. Frank, A multi-scale DAG for cartographic objects, Proceeding of Auto Carto 12, Charlotte, North Caroline, USA, pp. 157-163, 1995,

[VANG98] C. Vangenot, Représentation multi-résolution, Concepts pour la description de bases de données avec multi-représentation, Les nouveaux usages de l’information géographique, Actes des Journées Cassini 1998, Revue Internationale de Géomatique, Vol. 8, N° 1-2/1998, pp. 121-147

[WIER94] R. J. Wieringa, W. de Jonge, P. A. Spruit, Roles and DynamicClasses : A model Logic Approach, Proc. 8th European Conference on Object-Oriented Programming (ECOOP), pp. 32-59, 1994.

Haut de page

Table des illustrations

Titre Figure 1 : Schéma des couches fonctionnelles
URL http://cybergeo.revues.org/docannexe/image/4289/img-1.png
Fichier image/png, 30k
URL http://cybergeo.revues.org/docannexe/image/4289/img-2.jpg
Fichier image/jpeg, 52k
Titre Exemple : Définition de la classe générique SegmentRés.
URL http://cybergeo.revues.org/docannexe/image/4289/img-3.jpg
Fichier image/jpeg, 60k
Titre Figure 2 : Modèle géométrique simplifié
URL http://cybergeo.revues.org/docannexe/image/4289/img-4.png
Fichier image/png, 4,1k
Titre Figure 3 : Modélisation d’une route, a) au niveau classes, b) au niveau instances
URL http://cybergeo.revues.org/docannexe/image/4289/img-5.png
Fichier image/png, 7,7k
Titre Figure 4 : Les différentes relations inter-couches
URL http://cybergeo.revues.org/docannexe/image/4289/img-6.png
Fichier image/png, 5,6k
Titre Figure 5 : Relation d’équivalence inter-couches
URL http://cybergeo.revues.org/docannexe/image/4289/img-7.png
Fichier image/png, 4,6k
Titre Figure 6 : Les couches fonctionnelles relatives à un espace urbain
URL http://cybergeo.revues.org/docannexe/image/4289/img-8.png
Fichier image/png, 29k
Haut de page

Pour citer cet article

Référence électronique

Mohamed El Adnani, Hassan El Abdelwahed, Djamal Benslimane et Kokou Yetongnon, « Couches fonctionnelles et Rôles : nouveaux concepts pour une modélisation cohérente et intégrale des informations géographiques », Cybergeo : European Journal of Geography [En ligne], Cartographie, Imagerie, SIG, document 198, mis en ligne le 30 octobre 2001, consulté le 28 mars 2017. URL : http://cybergeo.revues.org/4289 ; DOI : 10.4000/cybergeo.4289

Haut de page

Auteurs

Mohamed El Adnani

Département d’Informatique, Faculté des Sciences Semlalia Marrakech, Maroc
md-eladnani@ucam.ac.ma

Hassan El Abdelwahed

Département d’Informatique, Faculté des Sciences Semlalia Marrakech, Maroc

Djamal Benslimane

LISI, Université Claude Bernard, Lyon1, Villeurbanne, France
djamal.benslimane@lisi.insa-lyon.fr

Kokou Yetongnon

LE2I, Equipe Ingénierie Informatique, Dijon France
kokou@u-bourgogne.fr

Haut de page

Droits d’auteur

© CNRS-UMR Géographie-cités 8504

Haut de page