Modélisation d’objets mobiles pour les systèmes d’information géolocalisés itinérants en temps réel Azedine Boulmakoul — Adil El Bouziri Laboratoire LIM./IST Faculté des Sciences et Techniques de Mohammedia (FSTM) B.P. 146 Mohammedia, Maroc {[email protected], [email protected]} RÉSUMÉ.

La convergence du développement dans le domaine de la communication sans fil, l’évolution des systèmes de positionnement et des systèmes d’information géographiques (SIG) ont favorisé l’émergence d’un nouveau type de services et d’applications liés à la mobilité et à la localisation. En revanche, les systèmes d’information actuels ne permettent pas la gestion d’informations concernant des objets mobiles. Cet article propose en premier lieu un modèle de données d’objets mobiles qui constitue un ‘framework’ pour le développement des applications et services géolocalisés. Ce modèle est extensible et orienté objet. Nous définissons dans ce modèle un ensemble de types et d’opérations capables de traiter des objets mobiles et qui seront nécessaires pour définir un nouveau langage d’interrogation des données mobiles basé sur le langage SQL 3. De plus, une architecture et une modélisation orientée objet avec UML 2 sont élaborées pour les systèmes d’information géolocalisés itinérants en temps réel. ABSTRACT. Convergence of development in the wireless communication field, evolution of positioning systems and geographic information systems (GIS) have given rise to a new type of applications and services related to mobility and localization. However, the current information systems do not deal with the management of information concerning the mobile objects. This article initially proposes a mobile object data model, which constitutes a framework for the development of location based applications and services. We define, in this extended object model, a powerful set of data types and operations able to handle mobile objects; and which will be necessary to define a new query language of mobile data based on SQL 3. Furthermore, architecture and object oriented modeling with UML 2 are developed for real time location based mobile information systems. MOTS-CLÉS : Objets mobiles, Location Based Services, requêtes spatio-temporelles, modélisation basée sur les composants.

Mobile objects, Location Based Services, spatio-temporal queries, component based modeling.

KEYWORDS:

Revue. Volume 14 – n° 5/2009, pages 1 à X

2

Revue. Volume 14 – n° 5/2009

1. Introduction La convergence du développement dans le domaine de la communication sans fil, l’évolution des systèmes de positionnement et des systèmes d’information géographiques (SIG) ont favorisé l’émergence d’un nouveau type de services et d’applications liés à la mobilité et à la localisation. Différents usages de ces nouvelles technologies apparaissent dans les secteurs cités ci-après : – Gestion de flottes de véhicules, – Gestion de transport urbain à la demande, – Aide à la navigation embarquée dans les véhicules personnels, – Nouveaux services liés à la mobilité : informations touristiques, routières, commerciales, etc. La convergence des différentes disciplines liées aux systèmes d’information géographiques et à la mobilité est à l’origine de la naissance des systèmes de services géolocalisés LBS (Location Based Services) (Schiller et al., 2004 ; Küpper, 2005), qui permettent de fournir des services et des données spatiales dépendant du contexte du client mobile notamment de sa localisation. Ce type de système fait partie des systèmes télégéomatiques qui représentent une nouvelle discipline caractérisée par l’usage des systèmes modernes de positionnement de type GPS et de la technologie SIG. La composante relative aux télécommunications est de grand intérêt et elle représente le maillon essentiel. De plus, ces systèmes sont caractérisés par la prise de décision en temps réel et ils ont souvent besoin de collecter en temps réel des données des différentes sources d’information (capteurs de congestion…) (Boulmakoul, 2006 ; Laurini, 2000). En revanche, la mobilité des utilisateurs et les contraintes imposées par l’utilisation des équipements embarqués et nomades génèrent de multiples problèmes de recherche difficiles. En particulier, les systèmes d’information actuels et notamment les systèmes d’information géographiques ne permettent pas la gestion d’informations concernant les objets mobiles. Ainsi, les conceptions et les approches classiques doivent être reconsidérées. Ce papier propose un modèle de données d’objets mobiles qui constitue un ‘framework’ pour le développement des applications et services géolocalisés. Ce modèle est extensible et exploite le formalisme UML 2. Notre modélisation est fondée sur plusieurs approches qui concernent le modèle spatio-temporel d’une part, ainsi que le modèle TRANSMODEL (TRANSMODEL, 2003) pour les réseaux de transport d’autre part. Ce modèle se base sur un ensemble de travaux de recherche portant sur les données spatio-temporelles notamment les objets mobiles ‘moving objects’, et les requêtes spatio-temporelles. Les travaux de Güting et Erwig (Güting et al., 2005 ; Erwig et al., 2002) seront spécialement de grand intérêt dans notre modèle pour l’élaboration des opérations traitant les objets mobiles. Ils introduisent de nouveaux types abstraits ainsi qu’une algèbre riche d’objets mobiles. Ce travail définit aussi des éléments pour un nouveau langage d’interrogation des données mobiles. Ce

Modélisation d’objets mobiles pour les systèmes d’information géolocalisés

3

langage est une extension du langage SQL3. Il est basé sur les types abstraits spatiotemporels. Il définit un ensemble de types et d’opérations traitant des objets mobiles et non mobiles, permettant ainsi de formuler des requêtes spatio-temporelles et l’interrogation des données mobiles au sein d’une base de données objetrelationnelle. En suite, une architecture et une modélisation orientée objet temps réel avec UML 2 (OMG, 2005) est élaborée pour les systèmes d’information géolocalisés itinérants en temps réel afin de fournir des services géolocalisés. De plus, une approche basée sur les composants de UML 2 est entamée et elle incorpore la composante développée pour les objets mobiles. Cet article est organisé de la manière suivante : la section 2 décrit l’architecture globale du système d’information géolocalisé itinérant en temps réel. Les sections 3 et 4 proposent un modèle orienté objet relatif aux objets mobiles et définissent un ensemble de types et d’opérations capables de traiter des objets mobiles qui seront nécessaires pour définir un nouveau langage d’interrogation des données mobiles. Ce langage est basé sur SQL 3. La section 5 propose un modèle orienté objet en utilisant le formalisme UML 2 pour le système d’information géolocalisé itinérant en temps réel et entame une approche basée sur les composants logiciels. La section 6 illustre le prototype développé qui intègre les différents concepts étudiés. Ce prototype concerne le système d’information touristique mobile de la ville de Mohammedia.

2. Architecture du système d’information géolocalisé Pour pouvoir fournir des services géolocalisés, nous proposons une architecture du système d’information géolocalisé itinérant en temps réel. Ce système est complexe et exige l’intégration de plusieurs technologies et composants. Il est schématisé dans la figure 1. Les applications mobiles ont un grand intérêt pour cette catégorie de système afin de présenter l’information temps réel requise qui témoigne d’un grand impact sur la satisfaction du client abonné. Le système global de positionnement GPS est nécessaire afin de déterminer la position actuelle de l’utilisateur mobile et d’envoyer également la mise à jour périodique de sa position au serveur de localisation. La figure 1 montre les principaux composants de l’architecture considérée : a) Mobile Object (MO) : représente l’objet mobile comme les véhicules ou des voyageurs, avec le mécanisme de détection de la position tel que le GPS. Cette entité peut être modélisée avec le framework proposé dans cet article pour la modélisation d’objets mobiles, b) Service Provider (SP) : joue un rôle primordial dans le système. Il coordonne les différents composants de ce système pour fournir un service n’importe où, n’importe quand et en temps réel sous forme de carte ou autre format supporté par le client abonné ; ce service sera lié à la position spatiale du client. Le SP

4

Revue. Volume 14 – n° 5/2009

peut utiliser la technologie émergente “services web” pour interagir avec n’importe quel dispositif mobile afin de fournir les services désirés. La communication et la coordination entre différents services web peuvent se réaliser même si elles sont développées avec des technologies hétérogènes (OGC, 2003a), c) Location Server : détermine les positions d’objets mobiles (personne, taxis…). Les serveurs de bases de données qui enregistrent la position de l’utilisateur mobile sont généralement distribués au sein d’un réseau cellulaire. Les bases de données utilisées dans ce réseau devaient traiter des données d’objets mobiles et tous types de requêtes spatio-temporelles. Ces bases de données spatio-temporelles sont nommées ‘moving object databases’ (Güting et al. 2000), d) GIS Server : ce serveur possède un ensemble d’outils nécessaire pour réaliser des analyses spatiales. Ce serveur doit accéder à la base de données spatiales pour réaliser ses fonctions. Par ailleurs, il peut accéder via le réseau internet aux différents serveurs GIS pour acquérir d’autres données nécessaires, e) Risk Data : cette entité fournit des informations de risque selon l’impact considéré (impact sur l'environnement, impact sur l'infrastructure et impact sur l'économie),

Figure 1. Architecture du système

Modélisation d’objets mobiles pour les systèmes d’information géolocalisés

5

f) Emergency Data : en cas d'urgence, ce composant permet de prendre en compte un certain nombre de décisions. Il calcule le rayon de la zone affectée et estime les conséquences. Ainsi, il suggère le déploiement optimum des unités de secours et réduit au minimum le temps d'évacuation. Il détourne le trafic de la zone affectée en conseillant d’autres directions, g) Real Time Data : représente une entité importante qui est consultée d’une façon concurrente et sporadique par le Service Provider pour obtenir les données temps réel requises. Cette entité reçoit d’une manière concurrente des données temps réel des différentes sources de données telles que les capteurs de congestion qui donnent des informations sur l’état de congestion des routes principales. Nous pouvons également recevoir des données des points d’intérêt (Points of Interest) (données intéressantes pour un touriste ou un voyageur) : restaurants locaux annonçant leurs menus, hôtels annonçant leurs disponibilités (room availability), théâtre offrant des billets de la dernière minute, disponibilité de stationnement (availability of parking), etc. l’entité Real-Time Data analyse les informations temps réel et enregistre les données traitées et validées dans des bases de données. En outre, notre fournisseur de service est constitué d’un ensemble de composants et de serveurs particuliers. Pour offrir les services désirés aux différents utilisateurs mobiles, une architecture basée sur les services web et le modèle n-tiers a été préconisée. Tous les dispositifs mobiles qui peuvent supporter le protocole SOAP (Simple Object Access Protocol) peuvent ainsi communiquer et demander les services souhaités à travers le Service Provider. Le client mobile peut accéder à la même information indépendamment de son dispositif mobile et de sa plate-forme. La figure 2 montre cette architecture qui permet une meilleure interopérabilité avec d’autres systèmes distribués et hétérogènes. Au niveau présentation, différents types d’appareils mobiles hétérogènes interagissent avec les services web comme des clients SMS, WAP, J2ME ou Windows CE. Le niveau logique est responsable des traitements et de la coordination entre les différents composants distribués constituant le système d'information. Par ailleurs, nous avons pris en considération les objets mobiles transportant des matières dangereuses qui présentent en cas d’accident, des risques majeurs pour la population et l’environnement. Face à la vulnérabilité des matières dangereuses, nous avons incorporé dans l’architecture proposée un système d’information spatial d’aide à la décision (SSAD) pour le transport des matières dangereuses. Le système SSAD est le fruit des travaux menés par Boulmakoul et ses collègues (Boulmakoul, 2006 ; Boulmakoul et al. 2008, 2001,1999). Il permet en particulier le routage au moindre risque et l'analyse des risques par itinéraire. Le concept de risque a été formulé dans la théorie des ensembles flous. Cette formalisation induit l’utilisation des algorithmes de routage adaptés aux graphes flous. De plus, la construction des structures de dioïdes adéquates et originales a été proposée pour la résolution du problème du kième plus court chemin flou (Boulmakoul, 2004).

6

Revue. Volume 14 – n° 5/2009

Figure 2. Architecture basée sur les services web 3. Modèle de données d’objets mobiles Nous proposons ici et dans la section suivante le modèle de données d’objets mobiles qui va constituer un ‘framework’ pour le développement des applications et des services géolocalisés. Ce modèle est extensible et il est orienté objet avec l’utilisation du langage UML 2. Notre modélisation repose sur plusieurs spécifications (OGC, 1999 ; ISO, 2000 ; TRANSMODEL 2003) qui concernent le modèle spatial, le modèle temporel et celui du réseau de transport. De même, ce modèle se base sur un ensemble de travaux de recherche portant sur les données spatio-temporelles, spécialement ceux liés aux objets mobiles ‘moving objects’, et aux requêtes spatio-temporelles (Koubarakis et al., 2000 ; Vazirgiannis et al., 2001 ; Erwig et al., 2002 ; Güting et al. 2000, 2005). Nous définissons dans ce modèle un ensemble de types et d’opérations capables de traiter des objets mobiles ou nonmobiles et qui seront nécessaires pour définir un nouveau langage d’interrogation des données mobiles. Ce langage est une extension du SQL 3 ; il permet de formuler des requêtes spatio-temporelles et ainsi l’interrogation des données mobiles au sein d’une base de données objet-relationnelle.

Modélisation d’objets mobiles pour les systèmes d’information géolocalisés

7

3.1. Le modèle global Le modèle global de la modélisation d’objets mobiles est présenté dans la figure 3. Nous commençons par ce diagramme de packages puisque le modèle proposé contient plusieurs composants permettant de définir un ensemble de classes et d’associations nécessaires pour représenter les différents aspects indispensables pour la modélisation d’objets mobiles. Ce diagramme est composé de plusieurs packages nommés respectivement : pk_MobileObject, pk_SpatialData, pk_TransportModel et pk_TimingData. Le package pk_MobileObject que nous pouvons considérer comme le noyau du modèle de données d’objets mobiles contient des classes représentant des données sur la mobilité, et des opérations indispensables pour l’interrogation des données mobiles. Le package pk_TransportModel représente la modélisation du réseau de transport. Il est constitué de deux sous-packages : pk_GenericModel et pk_PhysicalNetworkModel ; le premier sous-package décrit un modèle abstrait du réseau de transport ; il peut être instancié par toute structure concrète. Le deuxième sous-package donne le modèle du réseau physique de transport en explicitant les principales classes qui décrivent les entités nécessaires pour représenter la structure du réseau physique de transport.

Figure 3. Diagramme de packages du modèle de données proposé La classe MobileObject (cf. figure 4) du package pk_MobileObject représente la structure de l’objet mobile et les caractéristiques de la mobilité. Cette classe représente tous les attributs et toutes les opérations qui permettent de manipuler et d’interroger les objets mobiles. Puisque dans notre contexte, les objets mobiles vont poursuivre des chemins prédéfinis dans le réseau de transport, il est donc nécessaire

8

Revue. Volume 14 – n° 5/2009

de représenter les associations qui vont relier la classe MobileObject représentant l’objet mobile avec les entités constituant le réseau de transport (voir plus de détails sur la modélisation du réseau de transport dans la section 3.2). Ainsi, la classe TransportLink qui peut représenter par exemple au niveau fonctionnel un tronçon d’une route est ajoutée dans le modèle. La classe TransportNode qui a été également ajoutée peut représenter des points d’intersection tels que les carrefours. Une autre entité importante est explicitée dans ce package. Elle est représentée par la classe route. Cette dernière dépend de l’infrastructure physique et représente le cheminement emprunté par un objet mobile dans un réseau de transport. En revanche, la classe Route du sous-package pk_GenericModel est un concept abstrait indépendant de tout type d’infrastructure. De plus, la classe MobileObject hérite les propriétés de la classe abstraite Geometry définie dans la spécification simple feature de OGC (OGC, 1999). D’autre part, la classe contenant des données sur le mouvement d’objets mobiles est nommée MotionSilce. L’expression du temps, représentant le temps valide, est effectuée via les classes TM_Instant et TM_Period définies dans la norme « temporal schema ISO 19108 » (ISO, 2000).

Figure 4. Modèle de données d’objets mobiles

Modélisation d’objets mobiles pour les systèmes d’information géolocalisés

9

3.2. Modèle de réseau de transport Nous présentons la modélisation générique du réseau multimodal de transport en respectant les recommandations de la norme européenne TRANSMODEL « version 5.1 » (TRANSMODEL, 2003). Cette modélisation est représentée par le souspackage pk_GenericModel. Nous utilisons le formalisme orienté objet avec UML 2. Le modèle générique est représenté par un graphe orienté, dont les éléments fondamentaux sont des nœuds “Node” et des arcs “Link”, auxquels des rôles spécifiques sont assignés en fonction de l’objectif fonctionnel de la description. Pour l'aspect topologique, nous préférons utiliser le concept de noeud au lieu du point. Un noeud (pour la topologie générique) est le plus petit emplacement identifié dans l'espace. Il peut jouer différents rôles dans le réseau de transport (le noeud n'est pas simplement un emplacement dans l'espace). Il peut être situé par sa localisation selon un système de localisation. Un arc est un lien orienté unidimensionnel qui connecte deux noeuds. Il ne doit pas y avoir d’arc sans un noeud limite à chaque extrémité. Plusieurs types de nœuds ou d’arcs peuvent être définis selon leurs rôles fonctionnels.

Figure 5. Modèle générique du réseau de transport

10

Revue. Volume 14 – n° 5/2009

D’autres nœuds intermédiaires situés sur un arc peuvent être définis. Ils seront très utiles au niveau fonctionnel pour les utilisateurs mobiles. Ils sont définis dans le modèle par la classe “NodeOnLink” et caractérisés par un numéro d’ordre. Nous pouvons également introduire des entités nommées hypernode et hyperlink dans ce modèle. Un hypernode est un noeud composé d'un ou plusieurs nœuds ; par exemple, un noeud est une station pour un mode simple de transport et un hypernode est une station intermodale, qui est une place où les gens peuvent entrer, quitter le réseau de transport ou changer leur mode de transport. Un hyperlink est un lien connectant deux hypernodes. Il se compose d'un ou de plusieurs liens (Boulmakoul, 2006). La figure 5 donne une vue logique du réseau spatial de transport. Le noeud, l’arc et les relations entre eux sont considérés comme une structure générique “pattern”, qui peut spécifier beaucoup de structures plus concrètes dans un réseau de transport. En plus, la classe LinkSequence décrit une suite d’arcs. Elle est indispensable pour représenter un cheminement à travers le réseau. Nous avons deux alternatives pour sa description : cette entité peut être décrite à travers des points consécutifs “NodeInLinkSequence”, ou définie de façon univoque à travers un ensemble ordonné d’arcs “LinkInLinkSequence”. En particulier, la classe Route, qui est une spécialisation de la classe LinkSequence, est représentée d’une façon explicite dans le modèle. Elle représente une liste ordonnée de nœuds définissant un seul chemin à travers le réseau routier (ou ferré). Ce cheminement peut être emprunté par des services du transport. C’est un concept abstrait et distinct de tout cheminement physique.

Figure 6. Principales classes du modèle du réseau physique de transport

Modélisation d’objets mobiles pour les systèmes d’information géolocalisés

11

Par ailleurs, nous présentons aussi une modélisation du réseau physique qui décrit l’infrastructure du réseau de transport ; il est représenté par le sous-package pk_PhysicalTransportModel. Le modèle physique est composé de deux types de réseaux (cf. figure 6) : le réseau routier (RoadNetwork) et le réseau ferré (RailwayNetwork). Tous les nœuds du réseau physique sont des sous-types du nœud de transport “TransportNode”et tous les arcs sont également des sous-types de l’arc de transport “TransportLink”. Les extrémités d’un arc de transport sont des nœuds de transport reliés à l’arc par une relation un à plusieurs. Comme pour un arc quelconque, l’orientation du nœud initial vers le nœud final est arbitraire. Un attribut optionnel “sens de conduite” peut être utilisé pour préciser une telle orientation si c’est nécessaire. Des contraintes pourraient être soumises pour les noeuds et les arcs d’infrastructure. De plus, la classe route dépendante de l’infrastructure physique est ajoutée pour représenter le cheminement emprunté par un objet mobile dans un réseau de transport (cf. figure 4). Le modèle du réseau routier décrit aussi les éléments qui permettent de représenter les voies de circulation ouvertes aux véhicules. Deux classes sont introduites : RoadNode et RoadLink. La classe RoadNode peut représenter l’intersection d’au moins deux lignes centrales de routes, le bout d’une impasse ou l’intersection d’un élément de route et d’une zone fermée de circulation, etc. Le réseau ferré modélise l’ensemble des voies ferrées, où des trains (ou des métros) peuvent circuler. La modélisation du réseau ferré fait appel à deux classes : RailwayNode et RailwayLink. Un arc du réseau ferré (arc ferré) est une portion sans chevauchement ou croisement du réseau ferré. Les endroits où les arcs du réseau ferré se rencontrent sont représentés par des nœuds ferrés. Un arc ferré est borné par deux nœuds ferrés qui sont ses extrémités, indiquées par l’association correspondante.

3.3. Les objets spatiaux 3.3.1. Les relations spatiales La recherche sur les relations topologiques entre les différents objets spatiaux (points, lineString, polygone,…) est l’un des sujets les plus importants pour la modélisation des données spatiales (Schneider et al., 2006). Une des importantes approches est le modèle des 9-intersections considéré comme une extension et une généralisation du modèle original nommé le modèle 4-intersections (Egenhofer et al., 1990). En se basant sur le modèle 9-intersections, une collection complète de relations topologiques mutuellement exclusives a été déterminée. Le modèle est basé sur les intersections possibles entre la frontière ( ∂A ), l’intérieur ( Ao ) et l’extérieur ( A − ) d’un objet spatial A avec les parties correspondantes d’un autre objet spatial B. Pour chaque intersection, le résultat sera l’ensemble vide ou non (cf. tableau 1). Pour cette matrice, 2 9 = 512 configurations sont possibles. Mais, seulement quelquesunes ayant un sens et un intérêt sont prises en considération. Les relations spatiales

12

Revue. Volume 14 – n° 5/2009

topologiques qui en découlent ont été expliquées dans les travaux d’Egenhofer (Egenhofer, 1989, 1991). Par exemple, pour deux régions, huit configurations ont été identifiées et elles sont actuellement les prédicats spatiaux les plus connus.

 Ao ∩ Bo ≠ φ   ∂A ∩ B o ≠ φ  −  A ∩ Bo ≠ φ 

Ao ∩ ∂B ≠ φ ∂A ∩ ∂B ≠ φ A− ∩ ∂B ≠ φ

Ao ∩ B − ≠ φ  ∂A ∩ B − ≠ φ   A− ∩ B − ≠ φ  

Tableau 1. Matrice du modèle 9-intersections Dans le contexte des applications mobiles et services géolocalisés, nous nous intéressons à la relation d’objets mobiles (en effet des points mobiles) avec quelques objets spatiaux. Quelques configurations sont utiles et qui nous amènent à préconiser un ensemble de prédicats spatiaux : – Entre deux points, seulement deux configurations sont possibles traduites par les deux relations topologiques disjoint et equal. – Entre un point et une région, nous disposons seulement de trois prédicats : disjoint, meet et inside ; nous pouvons donc supposer que pour notre modèle l’objet mobile ne peut être qu’à l’intérieur, à l’extérieur ou sur la frontière d’une région donnée. – Entre un point et une ligne (qui peut représenter une route), le point peut être placé dans les extrémités, à l’intérieur de la ligne ou à l’extérieur. Nous disposons également dans ce cas de trois prédicats. Dans plusieurs travaux, les points mobiles et les régions mobiles portent plus d’intérêt1. Pour notre modèle, tous les objets mobiles seront considérés comme des points mobiles (voir la section 4 qui présente les types de données abstraits spatiotemporels) qui se déplacent dans les chemins (paths) connus (route, séquence de routes, chemin ferré, …) qui font partie d’un réseau de transport. Ce que nous trouvons pratiquement dans les systèmes d’information offrant des services géolocalisés ; où le mouvement de l’objet mobile, dont le déplacement n’est pas tout à fait libre, suit des itinéraires faisant partie du réseau de transport urbain (Teixeira, 2006). 3.3.2. Les données spatiales d’Open Geospatial Consortium (OGC) : Le modèle Simple Features de l’OGC L’OGC (Open Geospatial Consortium, ex-Open GIS Consortium) a défini des recommandations pour la représentation des données spatiales (OGC, 1999). La 1. La ligne mobile présente peu d’intérêt pour les applications actuelles

Modélisation d’objets mobiles pour les systèmes d’information géolocalisés

13

figure 7 montre les classes proposées par le standard pour représenter les objets spatiaux. La classe de base est représentée par la classe abstraite Geometry qui est associée au système de référence spatial “SRID”. Quatre types de base sont définis par OGC. Ils sont représentés par les sous-classes suivantes : – Point : est un objet géométrique de dimension 0 qui représente un emplacement dans le plan (x,y), – Curve : cette classe représente un objet géométrique de dimension 1 qui est stocké comme une séquence de points. Il existe une seule classe qui hérite la classe Curve ; c’est la classe LineString, – Surface : cette classe représente un objet de dimension 2. Elle est héritée par la classe polygon, – GeometryCollection : chacun des objets géométriques cités peut être rassemblé pour former une collection qui définit un objet géométrique représenté par cette classe. Les attributs et les méthodes de ces différentes classes ont également été déterminés dans la spécification (OGC, 1999). Les méthodes contenues dans la classe Geometry peuvent être regroupées de la manière suivante : – Les méthodes basiques (Dimension (), GeometryType, SRID()…) permettant d’obtenir des informations générales sur l’objet en question comme sa dimension, son type, son système de référence…, – Les relations topologiques : equals(), intersects(), contains()…, – Les autres relations : distance ()….

Geometry

+SpatialRS

ReferenceSystems:: SpatialReferenceSystem

1 +measureRS

ReferenceSystems:: MeasureReferenceSystem

0..1

Point

Curve

Surface

LineString

Polygon

2..*

Line

Figure 7. Classes spatiales de OGC (OGC, 1999)

GeometryCollection

14

Revue. Volume 14 – n° 5/2009

4. Le langage d’interrogation des données mobiles Nous présentons dans cette section notre travail sur le langage d’interrogation de données d’objets mobiles. Nous avons proposé une extension de SQL3 en y intégrant des opérations spécifiques à la mobilité. Nous proposons des éléments d’un langage riche par des prédicats et d’opérations spécifiques nécessaires à la manipulation des données mobiles. Un ensemble de ces opérations est défini dans les travaux de Güting et de ses collaborateurs (Güting et al. 2000) dont l’approche est basée sur les types de données abstraits afin de définir de nouveaux types temporels. Ce langage prend en compte, dans sa formulation, les critères liés à la position du requérant (par exemple, position fournie par GPS) et aux caractéristiques de son mouvement. L’architecture proposée d’une implémentation au sein d’un SGBD objet-relationnel est montrée dans la figure 8.

Interpréteur de requêtes mobiles Couche spatial SGBD objet-relationnel Figure 8. Architecture proposée 4.1. Les types de données abstraits spatio-temporels Nous allons définir dans cette partie, les opérations utilisées dans notre modèle notamment, celles de la classe MobileObject utilisant la notion de types de données abstraits spatio-temporels introduite dans les travaux suivants (Erwig et al., 1999 ; Erwig et al., 2002). Ces auteurs ont introduit la notion de l'objet temporel en observant que toute entité qui évolue au cours du temps peut être exprimée en fonction du temps. Les objets spatio-temporels sont vus comme des instances particulières d’objets temporels. En effet, ce système est basé sur un ensemble de types comprenant les types de données de base (int, real, string, bool). Les instances de ces types sont des valeurs statiques qui ne dépendent pas du temps. Un constructeur de type moving est introduit pour pouvoir instancier des types dont les valeurs sont dynamiques : moving (α ) , α est un type de donnée spatial comme point et region ou un type de base. Ainsi, le nouveau type moving (α ) a des valeurs en fonction du temps. Le temps considéré ici est le temps valide. Par exemple, la distance entre deux avions pourrait être exprimée par le type moving (real ) . En plus, le point changeant de localisation dans le plan euclidien au cours du temps est nommé moving point et il sera noté mpoint. La figure 9 représente moving point dans un espace à trois dimensions ( x, y, t ) . De même, une région qui évolue au cours

Modélisation d’objets mobiles pour les systèmes d’information géolocalisés

15

du temps (par exemple une surface de feu) est une région qui peut se déplacer "move". Elle est nommée evolving region ou moving region. Elle sera notée mregion.

t

y

x Figure 9. Représentation du point mobile Un objet mobile se déplaçant dans un réseau de transport est considéré comme un point mobile "moving point". En se basant sur le modèle 9-intersections d’Egenhofer et sur la définition des nouveaux types de données spatio-temporels modélisant les objets spatio-temporels, de nouvelles relations topologiques dépendant du temps pourraient être définies. Par exemple, deux objets peuvent être "disjoints" dans un certain intervalle de temps comme ils peuvent être en intersection dans un autre. Donc, avec les types de données abstraits spatiotemporels, un ensemble de nouvelles relations a été défini comme une version temporelle de prédicats spatiaux. Ce mécanisme est appelé temporal lifting. Par exemple, le prédicat spatial inside est appliqué aux types spatiaux {point, region} et il donne comme argument de retour une valeur de type booléen (bool). En appliquant la transformation de ‘temporal lifting’, ce prédicat sera applicable aux types abstraits spatio-temporels mpoint et mregion et l’argument de retour sera un booléen dont la valeur dépend du temps ‘temporal boolean’, nommé booléen mobile (mbool). La nouvelle opération correspondant au prédicat inside sera notée Inside dont la signature est donnée ci-dessous : mpoint × point → mbool mpoint × mpoint → mbool mpoint × region → mbool

16

Revue. Volume 14 – n° 5/2009

Ce sont quelques cas qui seront utiles pour notre modèle. Nous pouvons appliquer la même transformation pour obtenir d’autres opérations qui vont traiter des objets mobiles. Nous présentons quelques exemples de ces opérations : – Trajectory : mpoint → line ; cette opération donne la trajectoire de l’objet mobile. – Distance : mpoint × mpoint → mreal ; cette opération donne la distance entre deux objets mobiles.

4.2. Les opérations proposées du modèle de données Nous pouvons maintenant compléter notre modèle en ajoutant les opérations spatio-temporelles nécessaires pour manipuler les objets mobiles. Le tableau 2 montre les types abstraits de données qui sont indispensables pour le modèle de données. Type de données Moving ADT

mreal, mbool

Moving ADT (spatial)

mpoint

Tableau 2. Types de données spatio-temporels Le modèle présente des opérations intéressantes qui donnent pour un temps spécifié une donnée sur la position. L’opération MPoint() permet de retourner un objet point à un instant donné. De même, la valeur de retour pour l’opération MpointPeriod() sera un mpoint qui représente la séquence de l’objet mobile correspondant à un intervalle de temps donné: MPointAt : mpoint → point MPointPeri od : mpoint → mpoint

Le tableau 3 présente une classification de quelques opérations utilisées dans le modèle de données. En fait, ce modèle redéfinit les opérations proposées dans la spécification simple feature d’OGC en utilisant le formalisme présenté dans la section précédente. Par exemple, l’opération distance définie dans la spécification n’a que des arguments non temporels. Donc, nous définissons dans le modèle de données d’objets mobiles une nouvelle fonction Distance correspondant à la fonction distance, mais cette fois les arguments peuvent être des types de données représentant des objets mobiles. L’argument de retour sera évidemment une valeur dépendante du temps (mreal). En utilisant l’opération atInstant(), la valeur à un instant donné peut être déterminée.

Modélisation d’objets mobiles pour les systèmes d’information géolocalisés

opérations

17

atInstant() : real Lifespan() : Timestamp GetRoute() : LineString Distance() : mnumber

Opérations spatiales

disjoint() : bool touch() : bool within() : bool

Opérations spatio-temporelles

Disjoint(OtherGeo : Geometry) : mbool Touch(OtherGeo : Geometry) : mbool Within(OtherGeo : Geometry) :mbool

Prédicats spatio-temporels

DISJOINT(OtherGeo : Geometry) : bool TOUCH(OtherGeo : Geometry) : bool WITHIN(OtherGeo : Geometry) :bool

Prédicats spatio-temporels

Enter(OtherGeo : Geometry) : bool

spécifiques

Leave(OtherGeo : Geometry) : bool Cross(OtherGeo : Geometry) : bool

Tableau 3. Opérations de la classe MobileObject Nous allons également définir de la même façon les relations spatio-temporelles correspondant aux relations spatiales connues. Ces nouvelles relations traitent des types de données spatio-temporels dont la valeur de retour est un booléen mobile (mbool). Dans le contexte des applications géolocalisées, nous disposons de trois relations spatiales pour l’objet mobile modélisé par un point mobile. Donc, trois relations spatio-temporelles seront définies. En outre, des prédicats spatio-temporels seront ajoutés selon la définition d’Erwig (Erwig et al., 2002) : Définition — Prédicat spatio-temporel : Un prédicat spatio-temporel est une fonction de signature suivante : τ ( α ) × α (β ) → bool α,β ∈ (point, region) Les prédicats spatio-temporels ont comme valeur de retour un booléen. Ces relations sont nécessaires pour savoir si un objet mobile était tout le temps (lifespan) dans une région bien définie. Les prédicats spatio-temporels simples sont notés ici avec des lettres majuscules (INSIDE…). De plus, la trajectoire de l’objet mobile peut avoir des relations avec d’autres objets spatiaux (Tryfona et al., 2005). Ces objets spatiaux font partie de l’infrastructure urbaine. D’autres relations spécifiques peuvent être ajoutées au modèle (cf. figure 10) : – Enter : lorsque la trajectoire d’un objet mobile passe dans une zone d’intérêt, – Cross : lorsque la trajectoire d’un objet mobile traverse une zone d’intérêt, – Leave : lorsque la trajectoire d’un objet mobile quitte une zone d’intérêt, –Bypass : lorsque la trajectoire d’un objet mobile contourne une zone d’intérêt.

18

Revue. Volume 14 – n° 5/2009

En fait, ce sont des prédicats spatio-temporels plus complexes. Dans les travaux de Erwig et ses collègues (Erwig et al., 2002), elles correspondent aux séquences de prédicats spatio-temporels simples. Par exemple, le prédicat Enter est une séquence de prédicats : DISJOINT, TOUCH et INSIDE. Ces relations spatio-temporelles complexes sont très utiles dans le modèle de données et elles permettent de formuler des requêtes mobiles plus complexes. Ainsi, il sera possible de déterminer si des objets mobiles ont traversé une région spécifique. La figure 10 donne une représentation visuelle des prédicats spatio-temporels spécifiques.

Leave Bypass

Enter

Cross

Figure 10. Représentation des prédicats spatio-temporels spécifiques 4.3. Eléments pour implémenter le modèle au sein d’un SGBD objet-relationnel L’implémentation du modèle de données dans une base de données objetrelationnelle est basée sur l’utilisation des types de données abstraits et des relations au sein du SGBD. Nous pouvons décrire les types de données spatio-temporels en utilisant CREATE TYPE (Soutou, 1999). Le langage SQL3 introduit des extensions objet au standard SQL. Ces extensions sont apportées par quelques SGBD actuels comme Oracle et PostgreSQL. CREATE TYPE MotionSlice_type AS OBJECT (MS_ID number, position Point, instant DATE); CREATE TYPE Motion_type AS OBJECT OF MotionSlice_type; CREATE TYPE MobilePoint_type AS OBJECT (MP_ID number, motion Motion_type MEMBER FUNCTION MpointAt(inst TimeInstant) RETURN POINT …);

Maintenant, nous pouvons définir des instances de types de données représentant un objet mobile ‘Taxicab’, un objet spatial ‘Street’ ainsi que leurs tables correspondantes de la façon suivante : CREATE TYPE Taxicab_type AS OBJECT (id number, name varchar2(35), color varchar2(10), location MobilePoint_type); CREATE TYPE Street_type AS OBJECT

Modélisation d’objets mobiles pour les systèmes d’information géolocalisés

19

(id number, name varchar2(30), type_geo LineString); CREATE TABLE Taxicab of Taxicab_type; CREATE TABLE Street of Street_type;

4.4. Les requêtes spatio-temporelles d’objets mobiles Des requêtes spatio-temporelles peuvent maintenant être décrites. En plus des tables précédemment définies, d’autres tables sont nécessaires pour toutes les requêtes présentées dans cette section : CelluarPhoneUser (id number, name varchar2(35), location MobilePoint_type ) People (id number, name varchar2(35), location MobilePoint_type ) Ambulance (id number, name varchar2(35), location MobilePoint_type) Region (id number, name varchar2(35), type_geo Polygon)

Les requêtes ‘snapshot’ Les requêtes snapshot (instantanées) sont utilisées pour chercher des positions à des instants bien spécifiques. Now marque l’instant actuel. Exemple 1 : Trouver tous les taxis qui sont maintenant dans la rue “Peace”. Select t.id, t.location.MPointAt(Now) From Taxicab t, Street s Where s.name= “Peace” and (t.location.MPointAt(now).within(s.type_geo)) Exemple 2 : Trouver les ambulances à moins de 1 Km de ma position. Select a.id, a.location.MPointAt(Now) From ambulance a Where (a.location.MPointAt(now).distance(Point(x,y)) < 1000 Les requêtes ‘slice’ Les exemples suivants présentent des requêtes ‘slice’ qui seront utilisées pour le développement des applications et services géolocalisés. Ces requêtes nécessitent un argument temporel de type TimePeriod (un intervalle de temps): Exemple 3 : Trouver la position du client mobile 201 entre t1 et t2 AM. select c.location.MPointPeriod(TimePeriod(t1,t2)) from celluarphoneuser c where c.id = 201

20

Revue. Volume 14 – n° 5/2009

Les requêtes sur la trajectoire Les requêtes sur les trajectoires inclurent des opérations comme Enter(), Leave(), . .. Exemple 4 : Trouver les personnes qui sont entrées dans la région “iris” entre t1 et t2 AM. Select p.id, p.name, p.location.MPointAt(Now) From People p, Region r Where r.name= “iris” and (p.location.MPointPeriod(TimePeriod(t1,t2)).Enters( r.type_geo)) 5. Le modèle orienté objet du système proposé Dans cette section, nous allons présenter le modèle orienté objet du système d’information géolocalisé itinérant en temps réel en respectant autant que possible les recommandations citées dans la spécification de OGC (OGC, 2003b) et en utilisant le formalisme orienté objet avec UML 2 (OMG, 2005). La figure 11 montre le diagramme de collaboration qui expose l’aspect structurel du système où les objets échangent des messages. Les étapes suivantes décrivent l’interaction entre les objets dans le système. Ces séquences d’opérations auront lieu pour fournir le service désiré : 1. L’objet mobile, représenté par une instance de la classe MobileObject, demande, via le réseau sans fil, du fournisseur de service SP des services géolocalisés temps réel. 2. Après l’identification du client abonné et du service demandé, le SP analyse et interprète ces requêtes et fait appel aux différents services des autres composants afin de fournir des services géolocalisés au client mobile. Le SP formule une requête pour le serveur de localisation (Location Server) dans l’objectif de recevoir les positions de tous les objets mobiles mentionnés dans la requête du client. 3. Le serveur de localisation valide l’identité du fournisseur de service et le format de la requête. Puis, il cherche les données de positionnement appropriées des bases de données d’objets mobiles (moving objects databases). Il construit un message qui comprend en plus des données de positionnement d’autres données utiles telles que les données sur GMT et le temps local. Ce message sera envoyé à la destination du fournisseur des services. 4. Le SP analyse le message reçu du serveur de la localisation pour obtenir les données requises. Ensuite, il entame une connexion avec le serveur SIG (GIS Server) pour demander une carte ou rechercher les objets spatiaux ‘comme les parkings’ près desquels se situe l’abonné mobile. 5. Le serveur SIG envoie sa réponse au SP.

Modélisation d’objets mobiles pour les systèmes d’information géolocalisés

21

Figure 11. Diagramme de Communication du système proposé 6. Puisque le SP possède maintenant les informations nécessaires concernant le client, les objets mobiles et les objets spatiaux, il peut interagir avec l’entité RealTimeData pour rechercher les données temps réel qui la concerne. Comme exemple, cette information peut être la disponibilité d’un Parking, la disponibilité du service d’urgence d’un hôpital ou l’état d’un boulevard. Le SP pourrait aussi interagir avec le composant de cheminement flou multicritère au sein du système d’information spatial d’aide à la décision (SSAD) pour avoir le plus court chemin flou. 7. En conclusion, le SP envoie sa réponse décrivant le service à l’objet mobile. 8. Les applications mobiles au sein des terminaux mobiles permettent de ‘parser’ la réponse reçue du fournisseur de service. Ces applications permettent encore à l’abonné de visualiser une carte avec les services demandés et sa position sur cette carte. L’abonnée peut interagir avec l’application pour réaliser quelques fonctions supplémentaires.

22

Revue. Volume 14 – n° 5/2009

Dans la suite de cette section, nous présentons la modélisation du système en utilisant le concept de composants selon la notation UML 2 (OMG, 2005 ; Björkander et al., 2003). Au contraire de l’UML 1.x, ce concept a été modifié en adressant maintenant des structures du système. Cette modification est parmi les améliorations principales introduites dans UML 2 qui va supporter le développement basé sur les composants «component based development» via des structures composées. Un composant est une unité modulaire avec des interfaces bien définies. Les interfaces d’un composant sont classifiées en deux catégories : les interfaces requises (required) et les interfaces fournies (provided). Les interfaces fournies spécifient un contrat formel d’utiliser des services que le composant fournit à d’autres composants, tandis que les interfaces requises définissent les services qu’il requiert pour fonctionner correctement.

Figure 12. Structure composée des composants du système

Modélisation d’objets mobiles pour les systèmes d’information géolocalisés

23

Dans UML 2, un composant peut avoir deux vues différentes : une vue externe et une vue interne. Celle qui est externe est vue comme "black box". Elle montre seulement les propriétés et les opérations publiques qui sont encapsulées dans les interfaces fournies et requises. En revanche, la vue interne est présentée comme une sorte de "white box", elle montre les composants internes qui collaborent et réalisent le fonctionnement du composant. Le diagramme de la figure 12 décrit la structure composée des composants constituant le système d’information géolocalisé itinérant en temps réel. Chaque composant sera individuellement traité en perspective, en disposant des interfaces de services. En outre, chaque composant du système peut être réutilisé dans d’autres contextes. Dans l’approche de développement basé sur les composants, deux types de composants sont construits en se basant sur le modèle de données d’objets mobiles : – un module coté serveur : il représente un composant qui fait partie du Service Provider, – un module coté client : ce composant possède d’autres « classifiers » (classes ou composants) et d’autres interfaces qui sont plus spécifiques, dans le but de traiter les données concernant la localisation et de calculer les incertitudes du positionnement. Ces sujets sont discutés dans les travaux de Pfoser et ses collaborateurs (Pfoser et al., 1998).

6. Prototype : Système d’information touristique mobile En se basant sur l’architecture proposée du système d’information géolocalisé itinérant en temps réel et sur le faramework développé d’objets mobiles, des composants du système d’information touristique mobile ont été développés. Au niveau serveur, le langage de programmation utilisé est Java 2. En outre, un service web a été mis en place pour fournir à l’utilisateur mobile les services demandés et les informations mises à jour et en temps réel. Il offre des informations concernant des points d’intérêt (hôtels, parkings…). En particulier, l’utilisateur mobile peut recevoir des informations sur les points d’intérêt les plus proches et aussi des données temps réel concernant un point d’intérêt particulier (comme la disponibilité des parkings). Le serveur d’application supportant les services web est un Sun Java System Application Server (édition 8.2). Comme serveur de base de données spatial, la version 8.1.3 de PostgreSQL est utilisée avec la composante spatiale PostGIS. Des types et des fonctions spatio-temporels ont été ajoutés d’une part pour supporter les requêtes mobiles proposées dans cet article. D’autres part, de différentes fonctions sont développées dans le composant objet mobile. Comme exemple du client mobile, une application mobile a été développée. Elle est constituée d’un midlet qui permet de se connecter au service web pour obtenir le service désiré. L’unité mobile ou l’émulateur devraient supporter la spécification

24

Revue. Volume 14 – n° 5/2009

JSR-172 (Java specification request) (JSR, 2004). JSR172 est la spécification ‘J2ME web services’ qui définit un ensemble d’API pour le traitement du format XML et des services web avec SOAP. Dans notre exemple, le pack ‘Netbeans 5.0 mobility pack’ est utilisé avec ‘wireless toolkit v 2.3’ qui supporte JSR172 et JSR179 (JSR, 2006). La spécification JSR179 est un package optionnel qui permet d’améliorer le développement des applications mobiles de type LBS (Location Based Services). La figure 13 présente le guide touristique mobile de la ville de Mohammedia sur un émulateur du dispositif mobile. Cet exemple illustre comment développer une application mobile avec JSR172 et JSR179 qui permet de ‘consommer’ le service du fournisseur de services.

Figure 13. Exemples de Screenshots de l’application mobile côté client 7. Conclusion L’objectif principal de cet article est de proposer un modèle de données relatif aux objets mobiles. Ce modèle constitue un ‘framework’ pour le développement des applications et des services géolocalisés. Cette modélisation repose sur plusieurs spécifications qui concernent le modèle spatio-temporel, et le modèle du réseau de transport. Nous définissons dans cette représentation un ensemble de types et d’opérations capables de traiter des objets mobiles, qui sont nécessaires pour définir un nouveau langage d’interrogation des données mobiles. Ce langage, basé sur SQL 3, permet de formuler des requêtes spatio-temporelles et ainsi l’interrogation des données mobiles au sein d’une base de données objet-relationnelle. En plus, une architecture et une modélisation objet ont été élaborées pour le système d’information géolocalisé itinérant en temps réel et ce afin de fournir des services géolocalisés. De plus, une approche basée sur les composants est proposée en incorporant le ‘framework’ développé pour les objets mobiles. L’instanciation des concepts proposés a permis de construire un système d’information touristique mobile pour la ville de Mohammedia. Enfin, comme il est illustré dans ce travail, ce

Modélisation d’objets mobiles pour les systèmes d’information géolocalisés

25

type de système par sa complexité implique des développements différents et spécifiques. Le prototype actuel a soulevé un certain nombre de remarques liées à la qualité des services fournis, à savoir la nécessité de développements et d’optimisation des prédicats spatio-temporels, l’amélioration de l’aspect communication du système globale, la validation d’ordonnancement temps réel, etc. 8. Bibliographie Björkander M., Kobryn C., « Architecting systems with UML 2.0 », IEEE Software, 2003, p. 57-61. Boulmakoul A., Chala M., Bouziri A. E., Laurini R., « Modeling a real time mobile information system for HazMat telegeomonitoring », Advanced Technologies and Methodologies for Risk Management in the Global Transport of Dangerous Goods, Vol. 45, NATO Science for Peace and Security Series: Human and Societal Dynamics Edited by: C. Bersani, A. Boulmakoul, et al., September 2008, IOPress, 346 pages, p. 169-193. Boulmakoul A., « Fuzzy graphs modelling for HazMat telegeomonitoring », European journal of operational research, (175) 2006, p. 1514-1525. Boulmakoul A., « Generalized path-finding algorithms on semirings and the fuzzy shortest path problem », Journal of Computational and Applied Mathematics, Vol. 162, Issue 1, 1 January 2004, p. 263-272. Boulmakoul A., Laurini R., Zeitouni K., « Spatial monitoring and routing system for the transportation of hazardous materials », In Environmental Information Systems in Industry and Public Administration, Claus Rautenstrauch and Susanne Patig Editors, IDEA Group Publishing, 2001, p. 227-236. Boulmakoul A., Laurini R., Servigne S., Janati M.A., « First specifications of a telegeomonitoring system for the transportation of hazardous materials », In Computers, Environment and Urban Systems, 23 (1999), p. 259-270. Egenhofer M. J., « Point-Set topological spatial relations », Int. journal of Geographical Information Systems, 5(2), 1991, p.161-174. Egenhofer M. J., Herring J., Categorizing binary topological relations between regions, lines and points in geographic databases, Technical Report 90-12, National Center for Geographic Information and Analysis, University of California, 1990. Egenhofer M. J., « A formal definition of binary topological relationships », 3rd Int. Conf. on Foundations of Data Organisation and Algorithms, LNCS 367, Spring Verlag, 1989, p. 457-472. Erwig M., Schneider M., « Spatio-temporal predicates », IEEE Transactions on Knowledge and Data Engineering, 14(4), 2002, p. 881–901. Erwig M., Güting R. H., Schneider M., Vazirgiannis M., « Spatio-temporal data types: an approach to modeling and querying moving objects in databases », GeoInformatica 3, 1999, p. 265–291.

26

Revue. Volume 14 – n° 5/2009

Güting R. H., Schneider M., Moving Objects Databases, Morgan Kaufmann Publishers, 2005. Güting R. H., Böhlen M. H., Erwig M., Jensen C. S., Lorentzos N. A., Schneider M., Vazirgiannis M., « A foundation for representing and querying moving objects in databases », ACM Transactions on Database Systems, 25, 2000, p. 1-42. ISO/ TC211., Geographic Information / Geomatics: ISO 19108- Temporal Schema, 2000. JSR 172., J2ME web services specification, Final Release, 2004. JSR 179., Location API for J2ME specification, Final Release 2, 2006. Koubarakis M., Sellis T., editors, Spatiotemporal Databases: The Chorochronos approach, Springer Verlag, 2000. Küpper A., Location Based Services, John Wiley & Sons, 2005. Laurini R., « An introduction to TeleGeoMonitoring: Problems and potentialities », In Atkinson, P. and Martin, D. (eds) Innovations in GIS 7: GIS and GeoComputation. London, Taylor and Francis, 2000, p. 11-26. OGC., Open GIS Web Services Architecture (WSA), OGC 03-025, version 0.3, 2003. OGC., OpenGIS Location Services (OpenLSTM): Part 1-5 core services, OGC 03-006r1, 19 April 2003. OGC., OpenGIS Simple Feature Specification for SQL, OpenGIS Project document 99-049, May 5, 1999. OMG., Unified Modeling Language Specification: Superstructure, formal/05-07-04, v 2.0, 2005. Pfoser D., Tryfona N., « Requirements, definitions, and notations for spatiotemporal application environments », ACM-GIS, 1998, p. 124-130. Schiller J., Voisard A., Location Based Services, Morgan Kaufmann, Elsevier, 2004. Schneider M., Behr Th., « Topological relationships between complex spatial objects », ACM Transactions on Database Systems (TODS), 31(1), 2006, p. 39-81. Soutou C., Objet-Relationnel sous Oracle8, Editions Eyrolles, 1999. Teixeira de Almeida V., « Moving Objects in networks databases », EDBT Workshops 2006, p. 75-85. TRANSMODEL., Reference data model for public transport (in UML): version 5.1, 2003. Tryfona N., Pfoser D., « Data semantics in location-based services », Journal on Data Semantics, April 2005. Vazirgiannis M., Wolfson O., « A spatiotemporal model and language for moving objects on road networks », In the Proceedings of the Seventh International Symposium on Spatial and Temporal Databases (SSTD), 2001.