Architecture d`un système d`information géographique mobile

Transcription

Architecture d’un système d’information
géographique mobile
Un modèle d’architecture client-serveur pour les systèmes
d’information géographique mobiles
Alain Bouju — Arunas Stockus — Frédéric Bertrand
Patrice Boursier
Laboratoire Informatique, Image, Interaction
Université de La Rochelle
Avenue Michel Crépeau
17042 La Rochelle cedex 01
{alain.bouju,arunas.stockus,frederic.bertrand,patrice.boursier}@univ-lr.fr
RÉSUMÉ. Nous présentons les concepts d’un système d’information géographique mobile destiné
à la navigation, ainsi que sa mise en œuvre via une architecture logicielle reposant sur l’utilisation du web. Une des caractéristiques essentielles de notre travail réside dans le développement
d’une architecture client-serveur flexible pouvant s’adapter à des clients fixes ou mobiles, munis ou non de moyens de géolocalisation. Le développement de cette architecture s’appuie sur
une bibliothèque de classes permettant d’unifier les concepts de source de données géographiques et de visualisation de ces données. Notre architecture permet au client d’exprimer des
requêtes dont l’exécution utilise l’historique des requêtes précédentes. Nous présentons également un état de l’art sur les différents développements réalisés dans le domaine des systèmes
d’information géographique mobiles.
We present the concepts of a mobile geographical information system and their implementation via a software architecture relying on the use of the Web. One of the essential
characteristics of our work resides in the development of a flexible client-server architecture
which can adapt to fixed or mobile customers, provided or not with means of geolocalisation.
The development of this architecture relies on a library of classes unifying the concepts of geographical data source and visualization of these data. Our architecture makes it possible to the
customer to express requests whose execution uses the history of the previous requests. We also
present a state of the art on the various developments existing in the area of mobile geographical
information systems.
ABSTRACT.
MOTS-CLÉS :
SIG mobiles, architecture, client-serveur, bibliothèque.
KEYWORDS:
mobile GIS, architecture, client-server, library.
Géomatique – 13/2003. SIG transport, pages 225 à 251
226
Géomatique – 13/2003. SIG transport
1. Introduction
De nos jours, les utilisateurs de systèmes informatiques possèdent un accès permanent à des sources d’informations remises régulièrement à jour. Ils disposent de
moyens en évolution rapide permettant de rechercher et d’accéder, à tout moment,
à des informations via des réseaux informatiques. Cette possibilité est maintenant offerte aux utilisateurs de systèmes embarqués et de systèmes mobiles. L’évolution technologique permet actuellement l’utilisation de nouveaux outils intégrant les capacités
d’un ordinateur, d’un téléphone mobile et de moyens de localisation. Ces avancées
technologiques sont à l’origine de ce travail, qui a pour objectif la réalisation d’un
système permettant à un utilisateur mobile d’interroger des sources de données, d’en
extraire les informations de son choix et de les visualiser. Il s’agit là des fonctionnalités minimales d’un système d’aide à la navigation pour un utilisateur mobile.
Les moyens de communication mobiles présentent un certain nombre de limitations dont les plus importantes sont le faible débit du transfert d’informations et la
perte momentanée de connexion. L’architecture que nous avons développée prend en
compte ces aspects via un système de cache d’objets.
Les données interrogées sont vues comme des collections de données spatiales
géoréférencées. La position de l’utilisateur mobile aide au choix des données traitées
en plus des critères exprimés par l’utilisateur. Elle permet de sélectionner les données
liées à la position courante de l’utilisateur.
L’architecture proposée peut être qualifiée d’architecture web. En effet, elle propose la visualisation des informations via un navigateur web, elle utilise le protocole
de communication HTTP et repose sur une architecture de type client-serveur.
La conception et le développement d’une plate-forme expérimentale figuraient
parmi les objectifs initiaux de ce travail. La communication avec des serveurs de données distants, la gestion de la cartographie embarquée et le positionnement de clients
mobiles en sont les caractéristiques les plus importantes. La réalisation d’une plateforme expérimentale a permis une validation pratique des solutions proposées. La
mise en œuvre a soulevé certaines questions de nature plus pratique. Les données traitées au sein du système peuvent varier en termes de structure, de localisation et de
mode d’accès. Nous souhaitons assurer à un utilisateur un accès transparent à n’importe quelle donnée, quelque soit le contexte de l’application (application web, application classique). La conception du système répond à cette problématique en séparant
la présentation des données de leur accès et en uniformisant ainsi la représentation des
données pour le reste du système.
Deux types d’utilisation peuvent être envisagés pour la plate-forme logicielle réalisée. D’une part, c’est une bibliothèque logicielle proposant certaines fonctionnalités
de manipulation des données spatiales : lecture de données géoréférencées, application d’opérations spatiales, gestion du GPS, etc. Ainsi, elle peut être utilisée pour le
développement d’applications nécessitant une partie seulement des fonctionnalités.
D’autre part, la plate-forme est considérée comme une suite de modules mettant en
Architecture d’un SIG mobile
227
œuvre un enchaînement de traitements cohérents selon un assemblage lié à la logique
de l’application.
Bien qu’il puisse subir des modifications afin de répondre aux besoins spécifiques
d’une application, le traitement des données prévu dans chaque module répond à une
spécification cohérente vis-à-vis des autres modules.
La section 2 introduit les caractéristiques principales des systèmes mobiles, et plus
particulièrement celles liées aux sources de données et à l’accès aux données. La section 3 présente les principes de l’architecture du système développé. Les principaux
composants du système sont décrits dans la section 4. La mise en œuvre et quelques
expérimentations sont présentées dans la section 5. Enfin, la section 6 propose un bilan
du travail réalisé et décrit certaines perspectives de développement.
2. Caractéristiques des SIG mobiles
L’accès à des collections de données est un des aspects important pour un système
d’information. Cet accès doit prendre en compte la variété des sources de données,
mais aussi les techniques utilisées pour le transfert et le traitement effectif des données.
2.1. Les sources de données
Nous différencions les sources de données selon différentes caractéristiques.
Le type des données visualisables correspond généralement à deux formes de représentation : vectorielle et rasteure. La première est plus expressive mais n’est pas
toujours disponible. La seconde est un format souvent disponible en imagerie satellitaire ou aérienne.
Le format des données décrivant un même phénomène peut avoir une structure
différente. Par exemple, deux cartes vectorielles peuvent représenter la même ville
mais être codées dans deux formats différents. Cette différence est souvent liée aux
moyens de création et de traitement des données. Ces moyens peuvent être logiciels,
i.e. des SIG avec leur propre format de données. Cette différence de format peut aussi
provenir du matériel. Par exemple, les outils GPS permettent de sauvegarder les trajets
GPS selon différents formats.
Le mode d’accès varie suivant les sources de données : la lecture d’un fichier local
diffère de l’accès à une base de données locale.
La localisation des données peut être différente selon qu’elles sont stockées localement (sur le disque ou dans la mémoire du client) ou bien sur un serveur distant.
Dans certains cas, ceci complique la mise en place d’un accès uniforme aux données,
même si elles ont un format unique. Une applet 1 exécutée par un navigateur web
. Application Java téléchargée et s’exécutant au sein d’un navigateur web.
228
illustre cette problématique. Elle ne peut pas accéder à la fois à des données locales et
à des données distantes en raison des restrictions de sécurité imposées par la machine
virtuelle Java2 . Notons que c’est le cas pour le développement de notre application
de navigation, car une partie des données provient de serveurs distants (données cartographiques), et une autre partie est disponible localement (la position établie par le
GPS, correspondant à la localisation du mobile).
La fréquence de mise à jour précise l’aspect dynamique ou statique des données.
Dans une application de navigation, les intervalles de modification des données GPS
(généralement 1 ou 2 secondes) sont très courts par rapport à la durée d’une session
de travail (une ou plusieurs heures). Ce sont des données dynamiques. En revanche,
certaines cartes vectorielles subissent des changements peu fréquents (hydrographie,
relief...). Ces cartes peuvent alors être considérées comme statiques, et les modifications peuvent être ignorées lors d’une même session de travail.
2.2. L’accès aux données géoréférencées
Le traitement numérique des données géoréférencées a longtemps été réservé aux
utilisateurs professionnels. La création de bases de données géoréférencées, l’analyse, l’interrogation et la présentation de ces données nécessite une bonne compréhension des principes de leur organisation et la maîtrise des systèmes d’information géographique (SIG). Il existe des SIG dits professionnels proposant un ensemble
complet de fonctionnalités pour la gestion de collections complexes de données. Tels
sont les outils de la famille ArcGIS proposé par ESRI (comportant ArcView et ArcInfo) (ESRI, 2001), ou encore le SIG orienté objet Smallworld (Smallworld, 1997).
Les systèmes de gestion des bases de données (SGBD) actuels intègrent un support
pour la gestion de données spatiales. Par exemple, le SGBD Oracle avec une extension
OracleSpatial (Oracle Corporation, 2001), le SGBD PostgreSQL avec son extension
PostGIS (Blasby, 2001). Le déploiement de tels outils nécessite la formation des utilisateurs, ainsi que des investissements matériels et logiciels parfois importants, ce qui
limite la disponibilité de la technologie SIG aux utilisateurs non avertis.
Le partage des informations spatiales entre des institutions et l’organisation de leur
travail collaboratif est à l’origine des études sur la coopération entre bases de données
spatiales et SIG (Laurini, 1994). Le développement actuel des moyens de communication et d’internet permet aux utilisateurs d’accéder aux informations en tout moment
et en tout lieu. Ainsi, de larges collections de données spatiales deviennent accessibles à un grand nombre d’utilisateurs. Ces collections de données peuvent être créées
et maintenues avec des outils différents, utiliser des formats hétérogènes de qualité
variable et être accessibles via des modes d’accès différents. Ces différences compliquent leur utilisation commune, l’échange d’informations entre SIG, ainsi qu’avec
d’autres systèmes. Ces tendances ont fait émerger récemment un nouveau domaine de
recherche et de développement dans le domaine des SIG, appelée interopérabilité des
. Ces restrictions peuvent être changées pour les applets dites signées (certifiées).
229
SIG (Sondheim et al., 1999). Son but est de supprimer ces différences en normalisant
les formats de données, en leur associant une sémantique précise, et en uniformisant
les interfaces des services (des fonctionnalités) que les SIG actuels peuvent proposer à d’autres systèmes et aux utilisateurs. Les solutions sont disponibles à plusieurs
niveaux.
Il existe des bibliothèques logicielles implémentant des fonctionnalités de gestion
et de visualisation des données spatiales. Elles permettent de cacher les différences de
représentations des données en proposant à l’utilisateur une interface unique indépendante de la source de données. On peut citer dans ce contexte des bibliothèques telles
que GeoToolKit ou OpenMap. La bibliothèque GeoToolKit (Balovnev et al., 1997) est
un ensemble de classes C++ développées par INT 3 . Elles prennent en charge l’accès,
la visualisation et la manipulation des données spatiales.
L’ensemble de composants OpenMap est développé par BBN Technologies avec
des objectifs similaires (OpenMap, 1998). Il s’agit d’un ensemble de composants Java
(de type JavaBeans) permettant d’accéder à une information géographique provenant
de sources variées et de la visualiser. Les composants peuvent être assemblés pour bâtir des applications Java dans différents contextes : des applications de bureau « classiques », des applications distribuées, des applets, etc.
L’interopérabilité des SIG peut être obtenue en définissant des standards permettant d’uniformiser les structures de données échangées ainsi que leur mode d’accès.
Telle est l’interface OGDI (Open Geographical Datastore Interface) ou encore la spécification OpenGIS.
OGDI (Morin et al., 1997), (Clement et al., 1997) est une interface de programmation (API pour Application Programming Interface) développée par l’Institut pour
l’Interopérabilité de l’Information4. Cette interface a pour but de standardiser l’accès
à différentes sources de données spatiales. Elle définit une architecture client/serveur
basée sur l’utilisation de pilotes (drivers). Chaque pilote se charge de l’accès aux données et de leur conversion dans un format uniforme. OGDI représente également une
bibliothèque logicielle, à l’origine implémentée en C (et dernièrement en Java). Elle
fournit aux applications la possibilité d’intégrer des fonctionnalités de gestion et de
visualisation de données spatiales. Beaucoup de SIG et de SGBD actuels proposent le
support de OGDI dans leur dernières versions. Le SIG GRASS a été un des premiers
à mettre en œuvre OGDI (Byars, Clamons, 1998).
La spécification OpenGIS (Buehler et al., 1998) représente un effort encore plus
important dans l’interopérabilité des SIG. Développée par le consortium OpenGIS,
cette spécification a pour but de proposer des outils pour une représentation mathématique et conceptuelle commune des phénomènes spatiaux. Elle définit aussi un modèle commun pour l’implémentation de services permettant d’accéder, de gérer, de
. Il existe également une version Java appelée J/GeoToolKit.
. Depuis septembre 2001, son développement est aussi supporté par la communauté Open
Source sous la forme d’un de ses projets (http://ogdi.sourceforge.net).
230
représenter et de partager des données spatiales entre les membres de la communauté
informatique. Il existe actuellement des prototypes d’applications avec un support de
la spécification OpenGIS (Behrens et al., 1997), (Fonseca et al., 1997), ainsi que des
applications et des bases de données « professionnelles » (leur liste est disponible sur
le site web de OpenGIS (OpenGIS, 1994)).
L’intégration de données spatiales hétérogènes est obtenue en développant des services qui regroupent un ensemble de sources de données très variées. Ils proposent
aussi une interface d’accès (Wang et al., 1999) aux informations disponibles dans
ces sources. La bibliothèque électronique Alexandria (ADL pour Alexandria Digital
Library) développée à l’Université de Californie est un des exemples les plus marquants. Le but du projet ADL est de concevoir un système permettant d’accéder, d’interroger et de modifier des collections d’informations géoréférencées (pas seulement
des cartes numériques). L’architecture d’ADL est de type client-serveur, l’accès aux
données reposant sur des communication TCP/IP via les couches des applications intermédiaires (Wu et al., 1996), (Frew et al., 2000). L’interface web est un des moyens
utilisés pour la visualisation et l’interrogation des données.
L’utilisation d’internet, et en particulier de navigateurs web, pour le transfert,
le traitement et la visualisation d’informations géographiques est actuellement d’un
grand intérêt pour le développement des SIG. Du point vue de l’architecture, les techniques peuvent être regroupées en deux catégories en fonction du lieu de traitement
des données : sur le serveur ou sur le client.
Les scripts CGI sont un exemple classique de traitements exécutés du côté serveur (Gundavaram, 1996). D’autres méthodes, comme les scripts ASP (Active Server
Page), PHP, ou encore les servlets5 Java peuvent être considérées comme des méthodes dérivées, car elles suivent le même schéma d’exécution.
PSfrag replacements
Requête HTTP
Navigateur
1
Internet
web
4
Document
Système de fichiers
(Exécution CGI)
Web
Serveur
HTTP
2
Systeme de fichiers
(Execution CGI)
Document
Web
3
Figure 1. Architecture web classique
Ces techniques utilisent le schéma « classique » d’interaction entre un navigateur et un serveur web (figure 1). Typiquement, un formulaire HTML est utilisé pour
collecter les informations d’un utilisateur (une requête) et pour les envoyer au ser-
. Application Java traitant des requêtes HTTP et fonctionnant sur le serveur.
231
veur. Ensuite, elles sont traitées par un programme particulier (script CGI, PHP),
et le résultat du traitement est renvoyé au navigateur sous la forme d’un document
HTML. Dans le cas du traitement de données spatiales, on collecte les paramètres
d’une requête spatiale, et après l’avoir exécutée sur le serveur, on reçoit une page
HTML avec une image de la carte générée. Le serveur de planification de voyages
MapQuest (MapQuest.com, 2000), ou encore l’interface permettant d’interroger la bibliothèque Alexandria illustrent cette approche.
Ces techniques présentent quelques inconvénients. Le traitement est principalement effectué sur le serveur, et le client ne permet que la visualisation des résultats.
Ceci implique une charge élevée sur le serveur et des communications intensives avec
le client. Elle ne permet pas d’établir une connexion permanente entre le client et le
serveur pour une session de travail. Par conséquent, la réutilisation du résultat des requêtes précédemment exécutées demeure difficile. Ce type d’inconvénient peut être
évité en utilisant des moyens permettant de tracer l’exécution des requêtes d’un client.
Les « traces » sont stockées sur le serveur, ou bien sur le client. Un exemple de la dernière approche est décrit dans (Szmurlo et al., 1998) où est présenté un Antéserveur
géographique. Les scripts CGI sont utilisés pour effectuer le traitement des données,
et les résultats intermédiaires sont stockés sur le serveur. Les cookies (petits paquets
d’information mémorisés par le navigateur) sont utilisés afin de simuler une connexion
permanente au serveur durant la session de travail.
Les techniques de traitements destinés au client se basent sur le principe qu’une
partie ou la totalité du traitement des données est effectuée sur le client, indépendamment du serveur. On obtient ceci à l’aide de code exécuté dans l’environnement d’un
navigateur web. Les plug-ins, les applets Java et les modules ActiveX sont les composants logiciels les plus souvent utilisés.
Un plug-in est un composant qui traite un type particulier de données. Un navigateur l’exécute chaque fois qu’il accède à une page web contenant des références sur un
type particulier de donnée. L’utilisation d’un plug-in offre plus de flexibilité que les
scripts exécutés sur le serveur. Étant des modules de code exécutable, les plug-ins permettent d’effectuer des calculs locaux et d’utiliser des modes plus avancés d’échange
de données avec un serveur (connexions permanentes, chargement progressif des données, etc.). Autodesk MapGuide (Autodesk, 1997) est un exemple de plug-in permettant de visualiser des données spatiales via l’interface d’un navigateur web.
L’utilisation de plug-ins a un inconvénient : le composant doit être installé sur un
navigateur avant d’être utilisé. Il dépend donc du navigateur et du système d’exploitation, et il doit être développé pour chaque cas particulier.
Comme dans le cas précédent, les applets Java et les modules ActiveX sont des
composants logiciels exécutés par un navigateur ou par un système d’exploitation. La
différence réside dans le fait que le code correspondant est chargé à partir d’un serveur
(code mobile), de la même manière que des pages HTML, des images et d’autres
données. Il peut être exécuté par un navigateur web et sur n’importe quelle plate-
232
forme, à condition que le navigateur puisse exécuter les applets Java ou les modules
ActiveX.
Actuellement, plusieurs SIG professionnels possèdent des modules pour la visualisation de données en utilisant l’interface des navigateurs web. Il existe aussi un grand
nombre de prototypes permettant de traiter différents types de données spatiales.
Un prototype de système baptisé GeoLens est présenté dans (Behrens et al., 1997),
dont la partie visible pour un utilisateur est une applet Java. Le prototype lui-même
est basé sur la spécification OpenGIS et supporte plusieurs formats d’échange pour
accéder aux données. Une approche similaire (Berg et al., 1997) est prise pour le prototype Lava. Il utilise une connexion internet pour accéder aux données géographiques
et une applet Java pour leur traitement et leur visualisation, similaire à l’applet GAEA
présentée dans (Kotzinos et al., 1999). Dans (Kvedarauskas et al., 1997), on présente
une bibliothèque de composants logiciels appelée GeoLib. Un module ActiveX est
utilisé pour la visualisation de données géoréférencées.
Avec l’évolution de l’informatique mobile, il apparaît des systèmes possèdant une
architecture web, et leur traitements sont réalisés en majeure partie sur le client : systèmes de navigation (Stockus et al., 2000), (Kotsakis et al., 2001), services utilisant la
localisation des clients mobiles (Location Based Services) (Virrantaus et al., 2001).
Dans ces différents exemples, les composants logiciels reçoivent les données géoréférencées directement à partir de leurs sources (les fichiers sont accédés via le serveur web ou par des connexions directes aux bases de données). Ils peuvent aussi les
acquérir via des applications spécialisées intermédiaires (middleware en anglais). Généralement, ces applications proposent une interface uniforme d’accès aux données et
effectuent une partie du traitement des données.
3. Architecture du système réalisé
En définissant l’architecture du système, nous avons eu comme perspective de
faciliter l’accès aux sources de données géoréférencées en prenant en compte certaines
restrictions et choix techniques.
3.1. Contraintes et principes de mise en œuvre
Les caractéristiques et exigences que nous imposons au système sont les suivantes :
– le système est bâti sur une architecture client-serveur. La source principale de
données est un serveur, et le client (mobile) peut accéder et charger les données au fur
et à mesure, en fonction de ses besoins. La position du client mobile est le principal
critère pour le choix des données ;
– la réalisation est basée sur les technologies web. Les outils de visualisation d’informations sur le web (les navigateurs web) constituent l’environnement de présenta-
233
tion d’informations. Les données sont transférées à l’aide de communications de type
internet (protocole HTTP ou de protocoles de plus bas niveau comme TCP ou UDP).
Ainsi, la plate-forme étudiée peut être vue essentiellement comme un moyen d’accès et de visualisation d’informations géoréférencées.
3.2. Principe adopté
Nous avons choisi un environnement de mise en œuvre (Bouju et al., 1999) fondé
sur des technologies web. La communication étant un aspect essentiel dans les systèmes mobiles, et comme cette dernière peut être interrompue à tout moment, nous
avons opté pour le traitement des données sur le client. Ainsi le système peut continuer à fonctionner durant une interruption des communications en utilisant les données
disponibles en local.
Les applications sont écrites avec le langage Java. Cette approche nous permet
de considérer le code d’une application (applet) comme téléchargeable. Il peut être
obtenu à partir d’un serveur de données et ensuite exécuté localement.
Rappelons que le langage Java (Gosling et al., 2000) permet de développer des
applications portables dont le code (compilé en pseudo-code) est indépendant de la
plate-forme d’exécution. Cette indépendance est assurée par la machine virtuelle Java.
Elle constitue le véritable environnement d’exécution des applications et sert d’intermédiaire entre les application Java et le système d’exploitation. Une application Java
peut donc être exécutée dans tout environnement possédant une machine virtuelle sans
recompilation du code. Ainsi, un navigateur web possédant une machine virtuelle Java
peut constituer un environnement d’exécution d’applications Java.
Le système présenté n’est pas un système de gestion de bases de données. Il constitue un système permettant l’accès distant, la présentation et la visualisation de données
stockées sur un serveur distant à partir de systèmes mobiles. Il ne propose pas de gestion des données (création, mise à jour...). Nous considérons que des outils spécialisés
seront utilisés pour ces différentes tâches.
3.3. L’architecture web
L’architecture du système repose sur le modèle client-serveur. La figure 2 présente
l’organisation du système dans le cas général. Nous supposons qu’il est déployé dans
un contexte web, où nous utilisons un serveur web comme moyen d’accès aux données
et un navigateur web comme environnement de présentation. Les données peuvent se
situer sur un serveur distant (par exemple, une carte numérique) ou localement (les
données du GPS connecté à l’ordinateur du client).
234
Serveur
Page
HTML
Serveur
Web
Client
Navigateur Web
Présentation (Applet)
Code
Applet
Serveur distant
Fichiers
BD
Serveur
local
Données locales
(GPS, fichiers)
Figure 2. Architecture générale dans un environnement web : composants et flux de
données
Les parties principales du système sont les suivantes :
– Le serveur distant. Cette application gère l’accès à différentes sources de données : bases de données, données stockées dans des fichiers, etc. C’est aussi un gestionnaire de données, car elle peut répondre aux requêtes des utilisateurs en les exécutant elle-même ou en les redirigeant vers des bases de données. Le serveur distant
constitue le point d’accès aux données pour le reste du système.
– Le serveur local. Cette application gère la communication avec les serveurs distants et l’accès aux sources de données locales. L’ensemble de ces fonctionalités se réduit uniquement à la gestion des communications : il redirige les connexions du client
en se connectant aux sources de données et en renvoyant la réponse. Le serveur n’effectue aucune gestion de données, ni exécution de requêtes. Ce fonctionnement est similaire au fonctionnement des serveurs proxy utilisés sur le web (Wessels et al., 1998).
– L’applet. Une applet Java est exécutée par un navigateur web. Elle représente le
gestionnaire des données sur le client. L’applet effectue la visualisation de données,
gère le cache de données et exécute les requêtes utilisateur (dans le cas où les données
nécessaires à la requête sont disponibles sur le client).
Les serveurs (local et distant) fournissent au client (l’applet) une interface d’accès
aux données. Ils masquent l’hétérogénéité des sources de données, et assurent, pour le
client, l’uniformité de l’accès et de la structure des données.
À titre d’exemple, on peut citer le serveur local qui gère le GPS connecté à l’ordinateur. Il reçoit le flux de données du GPS et en extrait la position actuelle du mobile.
La gestion de ce périphérique repose sur un code qui dépend du système d’exploitation (appelé « code natif »). La séparation du code d’accès aux données et de celui de
leur gestion permet de rendre la partie présentation des données moins complexe et
plus indépendante de la plate-forme d’exécution.
235
Le principe de fonctionnement est simple. Au début d’une séance de travail, le navigateur télécharge la page web contenant la référence au code de l’applet. Un fichier
de configuration représente un des paramètres de l’applet. Il contient des informations
sur les cartes qui doivent être présentées par l’applet au cours de la session de travail.
Une fois téléchargée, l’applet débute son exécution en initialisant la communication avec le serveur distant. Puis elle charge la description de la carte à présenter,
initialise les structures locales de données (la définition des couches) et envoie les
premières requêtes d’initialisation d’instance de la carte. Lorsqu’on dispose d’une information de géolocalisation du système, ou une zone d’intérêt on peut sélectionner,
parmi les informations disponibles sur le serveur, celles qui correspondent à une zone
de travail6 . Le système maintiendra à jour un ensemble de données permettant de répondre aux besoins de l’utilisateur.
L’architecture peut être modifiée afin de répondre à des besoins spécifiques d’utilisation du système. Une de ces modifications peut être la suppression du serveur local
et/ou distant :
– Absence du serveur local. Cette modification est possible lorsque nous n’avons
pas besoin d’utiliser les ressources locales (par exemple, le positionnement en temps
réel). L’applet communique alors directement avec le serveur distant. La figure 3 (a)
présente l’architecture modifiée ;
Serveur
Page
HTML
Serveur
Web
Code
Applet
Fichiers
Client
Navigateur Web
Présentation
(Applet)
Serveur
Page
HTML
Client
Navigateur Web
Serveur
Web
Présentation
(Applet)
Code
Applet
Serveur
local
Serveur
distant
Fichiers
BD
BD
Données locales
Figure 3. Architecture logicielle sans serveur local (a) et sans serveur distant (b)
Cette architecture peut être utilisée pour la création des applications où la performance de transfert ne nécessite pas de traitement particulier. Par exemple, une application de surveillance de clients mobiles dont les positions sont centralisées dans une
base de données.
– Absence du serveur distant. Dans ce cas, tout le traitement des données doit
être effectué sur le client. Ceci correspond à un scénario où l’exécution des requêtes
. Zone plus large englobant la zone de visualisation.
236
s’effectue uniquement sur le client. L’applet doit aussi gérer différents modes d’accès
aux sources de données distantes. Cette modification est illustrée par la figure 3 (b) ;
Cette architecture peut être utilisée pour la création des clients « autonomes »
pour lesquels les serveurs distants ne constituent pas des sources de données souvent
accédées.
– Absence des serveurs (local et distant). Ce dernier cas correspond à l’architecture
la plus simple, car aucune application, locale ou distante, ne nécessite d’être installée.
La figure 4 présente ce cas. Cette configuration peut être utilisée pour des présentations simples. Par exemple, la visualisation des cartes numériques dans les pages web.
À noter également que dans cette architecture, les aspects de la gestion efficace du
transfert de données ne peuvent pas être traités.
Serveur
Page
HTML
Client
Navigateur Web
Serveur
Web
Présentation
(Applet)
Code
Applet
Fichiers
BD
Figure 4. Architecture logicielle sans les deux serveurs
Ces modifications de l’architecture peuvent impliquer une modification des applications, et en particulier une modification de l’applet. Certaines fonctionnalités
doivent être ajoutées ou supprimées, en particulier celles liées à l’accès aux données.
4. Les principes de conception et les composants du système
Nous présentons ici certains aspects de la conception et de la mise en œuvre du
système. Rappelons que nous distinguons deux niveaux d’utilisation de la plate-forme.
Au niveau développement, la plate-forme représente une bibliothèque de classes définissant les structures de données et les méthodes permettant d’effectuer certains traitements sur les données. Par extension, la plate-forme représente également un ensemble de modules effectuant chacun un traitement spécialisé des données. Ces différents modules sont conçus pour fonctionner ensemble et permettent ainsi de faciliter
le développement d’applications.
237
4.1. La bibliothèque de classes
La mise en œuvre peut être vue comme un ensemble de classes permettant de
télécharger les données dans la mémoire du programme et d’appliquer certaines opérations sur ces données. Cette mise en œuvre suit les définitions que nous donnons
dans notre modèle formel.
4.1.1. Modèle et type de données
Notre espace de modélisation est défini par :
– Les valeurs : afin de décrire les propriétés de nos objets nous manipulons des
valeurs telles que des nombres réels, des entiers, des caractères et des chaînes de caractères. Dans la modélisation formelle nous ne prenons pas en compte les caractéristiques particulières de chacun de ces domaines. Nous nous intéressons donc uniquement aux valeurs sans préciser le type et nous utilisons un domaine généralisé des
valeurs alphanumériques que nous notons .
– Le temps : nous introduisons le domaine des valeurs de temps. Bien que le
temps soit continu, nous considérons le domaine comme un domaine discret. Les
valeurs dans ce domaine représentent les instants du temps et sont mesurées en unités
temporelles (en secondes par exemple) ;
– L’espace : nous représentons l’espace par le domaine . Nous considérons
comme un domaine à deux dimensions. Les valeurs de , que nous appelons valeurs
géométriques, représentent la projection d’objets spatiaux du monde réel dans deux dimensions (le plan). Les objets pouvant avoir des formes différentes et complexes, on
considère leur approximation et leur discrétisation correspondant à trois types principaux : les points, les lignes et les régions.
Il faut noter que le modèle, tel qu’il est actuellement défini, ne traite pas les aspects
topologiques notamment la topologie du réseau routier. Il est orienté visualisation de
données. Pour l’utilisation de ce modèle dans des applications de type « aide à la
navigation », il serait nécessaire de l’enrichir avec les relations topologiques entre les
objets.
Les principaux objets géométriques simples :
– Point : un point est un couple
, où et sont deux nombres réels
définissant ses coordonnées spatiales. L’interprétation de et dépend du système de
coordonnées et de la projection choisis ;
– PolyLigne : une polyligne connexe est une suite de points
, où
chaque couple
définit un segment
avec
;
– Région : une région connexe simple est une suite de points
définissant un polygone simple sans trous. Cette suite définit aussi une polyligne délimitant
la région (la frontière de la région). Dans ce cas, le dernier et le premier points de la
polyligne forment un segment
;
– Région connexe : une région connexe munie de trous est définie comme une paire
,
, où est la frontière de la région, et
sont les frontières
des trous (s’ils existent).
"!
68/9:6 6 <; 03=?>
6
# $%&'(!'*)
# 4 7*)
+
-,./%0213,
/45
6
6
238
@AB
Nous voyons que le point est un objet de base pour la définition d’objets plus
complexes. Notons par
l’ensemble des points utilisés dans la définition d’un
objet spatial . Nous appelons ces points, les « sommets » d’un objet géographique.
A
Les objets donnés dans les définitions précédentes sont des objets connexes. Certains objets du monde réel peuvent être composites (des constructions composées de
plusieurs bâtiments, des espaces verts, des routes passant sous des tunnels, etc.) et
ils nécessiteraient une modélisation « non connexe ». Ainsi, nous définissons des objets géométriques complexes et non connexes, construits à partir d’objets connexes
(figure 5).
À partir de ces objets géométriques simples, nous construisons les objets géométriques complexes :
composé d’un ensemble de
C
-7D/&'E 0F=G,
– MultiLigne : elle représente une ligne non connexe H composée d’un ensemble
de polylignes connexes : HI
JHK&HLB , 0M=N, .
– MultiRegion : elle représente une région non connexe O composée d’un ensemble de régions connexes : OP
-OQ:OR , 0M=G,
– MultiPoint : il représente un point généralisé
,
.
points (simples) :
PSfrag replacements
SNTVUWYXYZ\[:X^]_W SNTVUWYXY`LXab]dc SNTVUWYXYe5cabXY[:]
Figure 5. Objets géométriques complexes
Nous considérons les objets géométriques définis par les définitions 4.1.1 comme
étant les valeurs du domaine . Sémantiquement, ces valeurs définissent la forme de
l’objet ainsi que sa position absolue.
L’organisation des informations dans notre modèle suit la définition classique des
cartes géographiques : les objets sont regroupés dans des couches, et celles-ci forment
une carte. Les objets possèdent des propriétés (des attributs) géométriques et temporelles, ce qui permet de les relier à l’espace et au temps. Une modélisation similaire existe dans (Sistla et al., 1998) ou (Erwig et al., 1997), où les objets sont définis
comme ayant des attributs géométriques et temporels.
Nous considérons les objets d’une carte comme des entités pouvant contenir des
informations alphanumériques ou multimédias. Les objets sont regroupés dans des
couches suivant leur structure et leur sémantique. Cette organisation des objets est
239
similaire à celle utilisée dans les bases de données, et notamment les bases de données
objets (Atkinson et al., 1989).
Notre modèle de carte est un modèle objet. Il est basé sur le modèle formel utilisé
dans (Lagorce et al., 1997) et peut être vu comme une spécialisation de celui-ci en
permettant d’intégrer des informations spatio-temporelles.
Formellement, une carte est composée de couches, chacune des couches étant caractérisée par des attributs associés.
fh
i9kj jmlD ;
f g
jLqo
gn
o9kp &pblD ;
jsrFf Soient deux ensembles et
dénombrables et disjoints de noms de couches
et de noms d’attributs
. On définit une signature comme une expression
, où
et représente un domaine généralisé
de valeurs alphanumériques correspondant aux propriétés des objets (nombres réels,
entiers, chaîne de caractères, . . . ). Un attribut est comme un couple
.
p<jdqtu
v est définie comme un couple vw
JHx*y8 , où :
1) HI
Jj:j l &jmB est une suite finie de noms de couches de f ;
2) y est un ensemble de définitions d’attributs p<jsqoz , où j est dans H . Pour
tout j5r{H , un attribut p est défini dans j une fois au plus (la définition p<&j|q}z
apparaît une fois au plus dans y ).
Une carte
Intuitivement, la définition d’une carte est une suite de couches, chacune ayant un
ensemble d’attributs associés. Elle correspond à la définition d’un schéma pour une
base de données. Elle décrit la structure des objets regroupés dans une couche (les
attributs) et indique les couches constituant une carte.
H
v
Nous pouvons noter que est une suite mais pas un ensemble dans la définition
d’une carte . Nous imposons de cette manière un ordre parmi les couches. Bien
qu’au niveau formel cet ordre n’ait pas d’importance, il en a lors d’utilisations pratiques. Par exemple, lors de la visualisation de la carte, l’ordre des couches dans la
liste peut indiquer l’ordre de superposition de ces couches.
4.1.2. Structures de données
Les structures utilisées pour le stockage des données dans la mémoire du programme correspondent aux définitions et aux types donnés précédemment. La figure 6
présente brièvement les classes les plus importantes selon la notation UML (Unified
Modeling Language) (Object Management Group, 2003).
~B.DEE
Un objet représente une entité d’information gérée au sein du système. C’est une
instance de la classe
. Un objet est composé d’un identificateur et possède
une description géométrique. Chaque objet comporte aussi une liste de propriétés. Le
contenu de la liste correspond à la structure définie dans la couche à laquelle l’objet
appartient.
~.EDEbE:
.
Les objets concrets sont définis par des classes dérivant de la classe
Dans une sous-classe, on spécialise les objets et on donne la réalisation de certaines
méthodes. Par exemple, les méthodes
et
permettent respective-
kE. kE.B..
240
ment d’afficher l’objet dans la fenêtre d’une application et d’afficher les informations
détaillées sur l’objet.
:
Pour faciliter la gestion des objets par le système, on associe aux objets du système un identificateur. Il est représenté par une instance de la classe
et contient un
ensemble d’informations sur l’objet : son identificateur proprement dit (il est unique
dans une couche) et sa date de modification.
Geometry
ObjectSet
0..1
1
0..*
ID
moment
MapObject
Map
0..*
1
1
Layer
VisuParameter
1
Figure 6. Les principales classes des objets d’une carte
EbEBb . Elle propose des
Une couche est représentée par une instance de la classe B. . Elle représente
Une collection d’objets est représentée par la classe
opérations de mise à jour de la collection et d’accès à ses objets.
une collection d’objets à laquelle on associe la description des propriétés des objets
(leurs attributs). La couche propose des méthodes pour accéder aux propriétés d’un
objet. La couche possède également des paramètres de visualisation des données et la
liste des requêtes ayant comme résultat cette couche.
Une carte représente une liste de couches. Elle définit donc l’organisation des
couches les unes par rapport aux autres.
La géométrie d’un objet est définie par une des classes de la hiérarchie présentée
dans la figure 7.
V.
B.VD.
EkB BDEEkE
BDB<kE
La géométrie simple est modélisée par trois classes principales :
,
et
. La frontière de la région est une extension de la
, où le dernier et
le premier point sont connectés. Une région avec des trous est modélisée par la classe
qui, en plus, contient une liste des frontières des trous.
B:Bbb:Vb ~DV:B
Les objets de la géométrie simple sont des objets connexes. Les objets non connexes
sont modélisés par les classes héritant de la classe
:
,
et
. Chacune des ces classes contient une liste d’objets géométriques simples.
~.VkE ~.VkVDD
Toutes ces classes proposent des méthodes permettant d’accéder aux éléments
de chaque objet géométrique : les points, les segments, le rectangle englobant, etc.
Ces éléments sont modélisés par des classes dites « classes géométriques de base » :
241
Geometry
ComplexGeometry
SimpleGeometry
MultiPoint
Point
Region
1..*
PolyLine
1..*
1..*
MultiLine
Boundary
HoleRegion
MultiRegion
1..*
Figure 7. Les classes de la géométrie d’objets
BkB .
¡E.
pour un point défini dans un espace à deux dimensions,
segment droit,
pour un rectangle englobant.
bV.B
pour un
Lors de la définition de la géométrie dans notre modèle de données, nous nous
sommes basés sur l’OpenGIS Simple Features Specification (OpenGIS, 1994). Notre
modèle est également proche de la norme SQL/MM (ISO, 2000). Il comporte des définitions similaires des types géométriques simples (points, polylignes, polygones)
et des collections associées (multipoints, etc.). Cependant notre modèle est moins
riche, notamment en ce qui concerne les opérations pouvant être réalisées. La norme
SQL/MM donne également une définition plus précise des directions et des angles
(utilisés pour établir la position des objets). Cette différence se justifie par la nature
des objectifs de ces définitions. SQL/MM est une norme que les SGBD doivent respecter afin de fournir les solutions complètes pour le stockage et le traitement de données
spatiales. Pour notre part, nous avons considéré uniquement le transfert et la visualisation d’informations et nous nous sommes limités au modèle minimal permettant de
représenter les données et d’effectuer des opérations simples comme leur recherche et
leur sélection.
Il est également à noter que la géométrie modélise la forme et la position spatiale
d’un objet, mais elle ne précise pas son type. Dans certains modèles (par exemple,
dans GeoLib (Kvedarauskas, 1999)) on trouve des classes spéciales pour les images
rasteures, les étiquettes (label) de texte et d’autres types d’objets dans la hiérarchie
des classes géométriques. Nous utilisons les objets
pour gérer ce type de
données.
~DDEb
4.1.3. Accès aux données
L’accès aux sources de données est géré à l’aide de « pilotes ». On propose un
ensemble de pilotes pour accéder aux différents types de données : les données sauvegardées dans un fichier (
), stockées dans un SGBD (
)
¢<.b<:£
B.¡E.bVk£
242
bbkbV:£B
ou envoyées par un flux de données (
). Ils masquent les différences de
formats, de structure et de mode d’accès aux données au reste du système. Ils effectuent aussi la conversion des données de leur format d’origine au format interne au
système. Les pilotes établissent une connexion avec la source de données en fonction
de la description donnée (une requête, le nom d’un fichier, etc.) et renvoient comme
).
résultat une collection d’objets correspondants (un
DEbE:b
Lorsque les pilotes sont utilisés comme une bibliothèque de classes, leur choix
doit être explicite, i.e. c’est l’utilisateur qui choisit le pilote utilisé pour accéder aux
données. Lorsque la communication est gérée par le gestionnaire de communication,
le choix du pilote se fait en fonction de la description des données disponibles dans le
système.
4.1.4. Opérations
Les opérations spatiales sont mises en œuvre de manière indépendante par rapport aux données sur lesquelles elles peuvent être appliquées. Ainsi, il est possible
de modifier les opérations (par exemple, télécharger une nouvelle version à partir du
serveur), sans pour autant changer le contenu des objets.
Operation
UnaryPredicat
Contains
BynaryPredicat
Intersects
UnaryFunctionDbl
Perimeter
Area
BynaryFunctionDbl
Distance
Figure 8. La hiérarchie des opérations
Les différentes opérations sont classées en prédicats unaires/binaires ou fonctions
unaires/binaires (cf. figure 8). Chacune de ces classes doit implémenter une méthode
qui prend, comme paramètres, un ou deux objets de type
. Elle
renvoie comme résultat une valeur booléenne ou réelle. L’ensemble des opérations
implémentées correspond à celles proposées lors de la définition du modèle formel. Il
peut être étendu en définissant de nouvelles opérations (pas nécessairement spatiales).
B¤B
~.DbE
L’ensemble des classes contient aussi l’implémentation d’opérations plus complexes : le test de couverture d’un rectangle par un ensemble de rectangles donnés,
le calcul d’angles entre les segments, etc. Elles ne font pas partie de la hiérarchie
présentée sur la figure 8 et constituent la base pour l’implémentation des algorithmes
présentés dans les chapitres précédents (algorithmes de mise en correspondance et de
test d’inclusion sémantique des résultats des requêtes, etc.).
243
4.1.5. Gestion du GPS
Les classes de traitement des données GPS (la figure 9) permettent d’accéder à ce
périphérique (un GPS connecté au port série par exemple) et de décoder les données
GPS. Le GPS est représenté par un objet de la classe
. Il peut produire un
flux de données qui est ensuite décodé à l’aide d’un décodeur (un objet de la classe
). À son tour, le décodeur redirige les données vers les consommateurs
de données, i.e. les programmes utilisateurs. Un paquet de données concernant une
. Cet objet comporte une
position GPS est stocké dans un objet de la classe
suite d’informations sur la position : les coordonnées, le temps, la précision, etc. Le
décodeur GPS décode les données à partir de n’importe quel flux de données Java
(
). Leur source peut être de type
, mais également n’importe
quel fichier avec des données GPS enregistrées précédemment ou une autre source.

ED¥B
B
kbbbb:
Bb
<<Interface>>
GPSDataConsumer
GPSDecoder
<<Interface>>
GPSStreamListener
0..*
0..*
NMEA183
GPSData
0..1
GPSPort
GGA
GLL
VGT
Figure 9. Les classes pour la gestion du GPS
Nous proposons l’implémentation d’un certain nombre de décodeurs, et en particulier les décodeurs de trames GPS au format NMEA183 (NMEA, 2000)
4.1.6. Les requêtes
La figure 10 présente le diagramme des classes correspondant à la définition des
requêtes et de leurs résultats.
Suivant la définition formelle, chaque requête est composée d’une référence sur sa
condition de sélection, de la liste des couches sur lesquelles elle est définie et de la
couche à laquelle appartient son résultat. Nous distinguons deux types de requêtes : la
requête « principale » (
) et les requêtes restreintes (
). La requête principale correspond à la requête initiale formulée par l’utilisateur ou générée par l’utilisateur. Sa condition contient donc la condition initiale de sélection. La requête restreinte
correspond à une restriction appliquée à la requête initiale. Sa condition correspond
uniquement à la condition de restriction. La condition de la requête effectivement exécutée est la conjonction de la condition initiale et de celle de la restriction.
¦DE.b
E¦Eb
La requête initiale possède une liste de requêtes restreintes associées. Chacune des
requêtes restreintes possède une réponse associée. Ceci correspond donc à l’historique
de la requête.
244
ObjectSet
AbstractQuery
Condition
1
0..1
1
1
Result
RQuery
Query
1
0..*
Figure 10. Les classes de requêtes et de réponses
4.2. Composants du système
Pour faciliter le développement d’applications, la plate-forme propose un ensemble
de modules, que nous appelons aussi gestionnaires. Chacun d’eux prend en compte
différents aspects du traitement des données : la visualisation, l’analyse de requêtes,
la communication, etc. Leur mise en œuvre est basée sur les structures de données et
les opérations présentées dans la section précédente. Chaque gestionnaire réalise un
ensemble de fonctionnalités et définit une interface permettant de les appeler.
Les gestionnaires ne proposent que des solutions générales pour la gestion des données. Ils peuvent ou doivent être spécialisés lors du développement d’une application
concrète.
L’organisation des modules assurant la présentation sur le client sera décrite plus
en détails, car elle intègre un grand nombre de modules.
4.2.1. La gestion de la présentation
La figure 11 montre l’organisation modulaire de la présentation de données sur le
client. Les gestionnaires composant la présentation sont les suivants :
– Gestionnaire de la carte. C’est le gestionnaire central autour duquel sont organisés les autres gestionnaires. Sa tâche principale consiste à recevoir et rediriger les
requêtes ainsi que leurs réponses. En fonction du résultat de l’analyse des requêtes, il
prend une décision sur le lieu d’exécution des requêtes. Lorsque les requêtes peuvent
être exécutées localement, il établit le dialogue avec le gestionnaire de données. La
communication via le gestionnaire de communication est initialisée à chaque fois que
la requête doit être envoyée à des sources de données externes à la présentation.
– Gestionnaire de visualisation. Ce gestionnaire accomplit deux tâches. Il définit un environnement pour la visualisation des données de la carte. En particulier, il
fournit un objet graphique assurant l’affichage des objets de la carte.
Le gestionnaire convertit aussi les actions de l’utilisateur sur les objets de type
« requêtes » qui peuvent être traités par le reste du système. Ces actions sont variées :
des requêtes de sélection de données, le changement d’échelle de visualisation des
données, le changement d’organisation des couches (leur visibilité ou leur ordre).
PSfrag replacements
Gestionnaire
des Requêtes
´D¬kµ¬«D¬.¬k®:¯k° )
( ²/ª.¯k°:³«D¬.¬k®:¯k° )
½ ¿ ½2¿
½2¾
½2¾
Gestionnaire
Gestionnaire
Gestionnaire
À
de la Carte
de Communication
de Visualisation
À
(«D¬±«D¬/.¬k®¯k° )
(§.¨:©*ª«D¬/.¬k®¯k° )
( ¶·¹¸k¸.«D¬.¬®¯k° )
½2¿
(
des Données
Gestionnaire
des Donnees
245
(
Gestionnaire
d’Index
º*D»¯k¼«D¬.¬k®:¯k° )
Figure 11. L’architecture modulaire de la présentation
– Gestionnaire des requêtes. Ce gestionnaire effectue l’analyse des nouvelles requêtes vis-à-vis des requêtes déjà exécutées. Les résultats de cette analyse sont ensuite
utilisés pour la prise de décision sur le lieu d’exécution des requêtes.
– Gestionnaire des données. Il gère l’accès à l’ensemble des objets disponibles sur
le client. Les résultats des requêtes sont sélectionnées dans ce module.
– Gestionnaire de communication. e gestionnaire prend en charge la communication avec les sources de données. Cette communication est effectuée à l’aide de pilotes
de communication. Ses fonctionnalités consistent principalement au choix des pilotes
en fonction d’une requête proposée, à l’établissement de la communication avec les
sources de données et au renvoi du résultat obtenu.
– Gestionnaire d’index. Le gestionnaire d’index n’est pas nécessairement inclus
dans la partie présentation des données. Il gère l’index spatial des données disponibles sur le client, et il permet de sélectionner les objets candidats pour le résultat des
requêtes.
L’envoi de messages entre les modules s’effectue soit via l’appel d’une méthode,
soit via un mécanisme d’événements Java. Le premier cas correspond à l’appel de méthode classique de la programmation objet : lorsqu’un module appelle une méthode
d’un autre module, le premier reste bloqué jusqu’à la fin de l’exécution de la méthode
dans la figure 11). Après exécution de la méthode, le premier mo(les messages
dule peut recevoir son résultat et continuer l’exécution. Ce type de dialogue (communication synchrone) est maintenu entre le gestionnaire de la carte et les gestionnaires
de données, des requêtes et de l’index.
vÂÁ
246
Dans le deuxième cas, les modules communiquent en émettant des événements.
Un module appelle un autre module en invoquant une de ces méthodes. Cet appel
n’est pas bloquant, et le premier module peut continuer son exécution (les messages
dans la figure 11). Lorsque le traitement du message est fini, le deuxième module
envoie un événement au premier pour l’informer de la fin d’exécution du message
et lui transmettre un résultat éventuel (les messages ). Le gestionnaire de la carte
dialogue de cette manière avec les gestionnaires de la visualisation et de la communication. L’implémentation de ces trois modules utilise le mécanisme de threads (flux
d’exécution) du langage Java. Ces gestionnaires peuvent donc s’exécuter en parallèle
dans la même application (communication asynchrone).
vI
Ã
4.2.2. Le gestionnaire GPS
Ce gestionnaire facilite la gestion d’un GPS connecté à l’ordinateur. La gestion de
l’accès au GPS, le décodage des données GPS et la sauvegarde des données dans des
fichiers sont les principales fonctionnalités de ce module. Il permet aussi la simulation
du fonctionnement d’un GPS à partir des données sauvegardées précédemment.
L’organisation modulaire du système diffère suivant le but recherché. L’architecture de la partie de présentation (d’une applet) suit le schéma donné dans la figure 11.
Le serveur distant est organisé de manière similaire, ayant pour différence l’absence
du gestionnaire de visualisation. La mise en œuvre du serveur local est principalement
basée sur le gestionnaire GPS et certaines fonctionnalités du gestionnaire de communication.
5. Mise en œuvre et expérimentations
La plate-forme développée constitue une bibliothèque de modules logiciels avec
des fonctionnalités prédéfinies permettant la gestion de données géoréférencées, leur
transfert et leur visualisation.
Ces modules logiciels ont été utilisés à plusieurs reprises dans d’autres travaux
de recherche et d’autres projets. Les structures de données ont été élaborées lors de
travaux menés au laboratoire L3i sur la définition des relations d’orientation entre les
objets spatiaux (Malki et al., 2000). Elles constituaient une base pour des travaux expérimentaux. Ceci nous permet d’envisager l’intégration de nouvelles fonctionnalités
sur le raisonnement spatial dans la bibliothèque de classes et de les proposer dans des
applications futures.
Ces modules logiciels ont été utilisés pour la réalisation d’un prototype embarqué permettant la visualisation de cartes et la localisation des véhicules (interface de
l’application présentée sur les figures 12 et 13). Il permet d’étudier l’optimisation des
transferts d’informations (Stockus et al., 2001) en connaissant la localisation de l’utilisateur.
La partie « visualisation de données » a été utilisée dans un prototype développé
dans le cadre du projet européen Magic Tour Net (ESPRIT 961578). Ce projet était la
247
suite du projet Magic Tour (ESPRIT 8752), dont le but était le développement d’un
système auteur facilitant la création d’applications multimédia dédiées au tourisme. Le
projet Magic Tour Net était une extension de celui-ci vers la création de présentations
touristiques via internet (Boursier, 1997). La composante de présentation (applet) était
incluse dans ce projet pour la visualisation de données géographiques sur un site web.
Figure 12. Prototype développé sur un assistant personnel
Les classes de gestion du GPS sont utilisées dans la mise en œuvre d’une plateforme expérimentale dans le cadre du projet européen ELCIDIS (Electric Vehicle City
Distribution Systems) (ELCIDIS, 1997). Le but de ce projet est le développement d’un
système de distribution des marchandises utilisant des véhicules électriques. La plateforme expérimentale permet de suivre à l’aide d’un GPS les parcours de livraison des
marchandises au centre ville de La Rochelle. Les classes GPS ont servi pour l’acquisition, la conversion et la sauvegarde des trajets GPS.
6. Conclusion et perspectives
Nous avons présenté les principaux aspects d’un système d’information géographique mobile. Nous avons décrit son architecture générale et son organisation interne.
Le système développé a permis d’étudier les problèmes inhérents aux SIG mobiles :
la limitation du transfert d’information par la réutilisation des données et les déconnexions fréquentes. Cette étude s’est accompagnée d’une réalisation de prototypes et
la participation à de nombreux projets. Une des caractéristiques essentielles de notre
travail réside dans le développement d’une architecture client-serveur flexible pouvant
s’adapter à des clients fixes ou mobiles, munis ou non de moyens de géolocalisation.
De nouveaux travaux ont récemment débuté au sein de l’équipe REVIM dans le
domaine de l’indexation spatiale dans un contexte mobile. Actuellement, cette pro-
248
blématique constitue un axe principal de recherche, mais les premières expérimentations ont déjà été effectuées (Chua et al., 2001). Elles s’appuient sur la bibliothèque
de structures de données et de traitement de la plate-forme présentée.
Centrer la carte
autour de la position
Mettre en
correspondance
Afficher la page
d’informations
Afficher
la position
Réafficher
la carte
Organiser
les couches
Changer
l’échelle
Le véhicule
L’échelle
Figure 13. Fonctionnalités du prototype (version fonctionnant sur PC portable).
D’autres travaux (Follin et al., 2003) sont menés pour permettre une meilleure gestion des problèmes de changement d’échelle. Notre objectif est d’adapter la quantité
d’informations transférées à l’échelle d’utilisation des données et en permettant également une réutilisation des données fournies d’autres échelles.
Le système que nous avons développé repose sur l’utilisation d’un modèle où
les données sont bien structurées sur le serveur. Nous travaillons sur des évolutions
permettant une prise en compte plus souple des données en utilisant les nouveaux
formats d’informations semi-structurées tel que GML (OpenGIS Consortium, 2003).
Notre expérience nous incite à penser qu’il sera nécessaire d’ajouter à ces formats des
mécanismes d’indexation performants.
249
Ces modules logiciels ont été utilisés à plusieurs reprises dans d’autres travaux
de recherche et d’autres projets. Ils constituaient une base pour des travaux expérimentaux. Ceci nous permet d’envisager l’intégration de nouvelles fonctionnalités sur
le raisonnement spatial dans la bibliothèque des classes, et de les proposer dans des
applications futures.
Remerciements
Les auteurs tiennent à remercier pour leur coopération et leur soutien financier la
Communauté d’Agglomération de La Rochelle et la région Poitou-Charentes.
7. Bibliographie
Atkinson, M., Bancilhon, F., DeWitt, D., Dittrich, K., Maier, K., Zdonik, S. (1989). « The
Object-Oriented Database System Manifesto ». Proceedings of the First International
Conference on Deductive and Object-Oriented Databases, p. 223–240, Kyoto, Japan.
Autodesk (1997). « Autodesk MapGuide : State-of-the-art network-centric GIS application
architecture for publiching and accessing geodata ». Autodesk White Paper.
Balovnev, O. T., Breunig, M., Cremers, A. B. (1997). « From GeoStore to GeoToolKit : The
Second Step ». Symposium on Large Spatial Databases, p. 223–237.
Behrens, C., Shklar, L., Basu, C., Yeager, N., Au, E. (1997). « The Geospatial Interoperability Problem : Lessons Learned from Building the GoeLens Prototype ». International
Conference on Interoperating Geographic Information Systems.
Berg, C., Tuijnman, F., Vijlbrief, T., Meijer, C., Uitermark, H., Oosterom, P. (1997). « Multiserver Internet GIS : Standardization and Practical Experiences ». International Conference
on Interoperating Geographic Information Systems.
Blasby, D. (2001). « Building a Spatial Database in PostgreSQL ». Open Source Database
Summit, Providence, Rhode Island.
Bouju, A., Stockus, A., Bertrand, F., Boursier, P. (1999). « Client-server Architecture for Accessing Multimedia and Geographic Databases within Embedded Systems ». Proceedings
of 10th International Workshop on Database and Expert Systems Applications (DEXA’99),
p. 760–764, Florence, Italy.
:ÄYÅ
Boursier, P. (1997). « Integration of Multimedia and GIS technologies : the Magic Tour
European Workshop on EC-funded GIS
and Magic Tour Net projects ». Proceedings
projects (EC-GIS’97), Bruxelles, Belgique.
Buehler, K., McKee, L. (1998). « Introduction to Interoperable Geoprocessing and the
OpenGIS Specification ». Open GIS Consortium Technical Committee, Third edition.
http://www.opengis.org/techno/guide.htm.
Byars, B., Clamons, S. (1998). « GRASS is back ! ». GeoWorld, 11(2) :60–67.
Chua, J., Bouju, A., Stockus, A. (2001). « Application of Spatial Indexing for Spatial Data
Access in Mobile Environment ». Rapport de Stage, Université de La Rochelle, Laboratoire
d’Imagerie Industrielle et d’Informatique - L3i.
250
Clement, G., Larouche, C., Gouin, D., Morin, P., Kucera, H. (1997). « OGDI : Toward Interoperability Among Geospatial Databases ». SIGMOD Records, 26(3).
ELCIDIS (1997). « Electric Vehicle City Distribution Systems. An Integrated Targeted Project
supported by the European THERMIE programme ». http://www.elcidis.org.
Erwig, M., Güting, R., Schneider, M., Vazirgiannis, M. (1997). « Spatio-Temporal Data
Types : An Approach to Modeling and Querying Moving Objects in Databases ».
Informatik-Report 224, FernUniversität Hagen.
ESRI (2001). « What Is ArcGIS ?, ArcGIS Product Literature ».
http://www.esri.com/library/whitepapers/pdfs/what_is_arcgis.pdf.
Follin, J.-M., Bouju, A., Bertrand, F., Boursier, P. (2003). « Extension to Multi-Resolution of
an Embedded Spatial Information Visualization System ». Proceedings of the 6th AGILE
Conference on Geographic Information Science, p. 149–159.
Fonseca, F. T., Davis, C. A. (1997). « Using the Internet to Access Geographic Information : And Open GIS Interface Prototype ». International Conference on Interoperating
Geographic Information Systems.
Frew, J., Freeston, M., Freitas, N., Hill, L., Janée, G., Lovette, K., Nideffer, R., Smith, T.,
Zheng, Q. (2000). « The Alexandria Digital Library architecture ». International Journal
on Digital Libraries, 2(4) :259–268.
Gosling, Joy, Steele, Bracha (2000). Java Language Specification. Addison-Wesley.
Gundavaram, S. (1996). CGI programming on the world wide web. O’Reilly.
ISO (2000). « Infomation Technology – Database Languages – SQL Media and Application
Packages (SQL/MM) – Part 3 : Spatial ».
Kotsakis, E., Caignault, A., Woehler, W., Ketselidis, M. (2001). « Integrating Differential
GPS data into an Embedded GIS and its Application to Infomobility and Navigation ». 7th
EC-GI and GIS Workshop.
Kotzinos, D., Prastacos, P. (1999). « GAEA, a Java-based Map Applet ». TELE-GEO’99.
Kvedarauskas, D. (1999). Intégration de fonctionnalités géographiques dans les environnements de développement de systèmes d’information. PhD thesis, Université Paris-XI.
Kvedarauskas, D., Boursier, P., Culos, X., Deltheil, T., Iris, S. (1997). « GEOLIB : A Software
Component for Making GIS Tools Interoperable ». International Conference on Interoperating Geographic Information Systems, Santa Barbara, California.
Lagorce, J.-B., Stockus, A., Waller, E. (1997). « Object-Oriented Database Evolution ». 6th
International Conference on Database Theory - ICDT ’97, vol. 1186 de Lecture Notes in
Computer Science, p. 379–393, Greece. Springer.
Laurini, R. (1994). « Sharing Geographic Information in Distributed Databases ». 2nd Annual
Conference URISA (Urban and Regional Information Systems Association), p. 441–455.
Malki, J., Mascarilla, L., Zahzah, E.-H., Boursier, P. (2000). « The Orientation Histogram :
A Representation for Direction Relations Between Spatial Objects ». 9th International
Symposium on Spatial Data Handling (SDH2000).
MapQuest.com (2000). « MapQuest : Driving Directions, Maps and Live Traffic Reports ».
http://www.mapquest.com.
Morin, P., Gouin, D., Clement, G., Larouche, C. (1997). « Interoperating Geographic Information Systems Using the Open Geospatial Datastore Interface (OGDI) ». International
Conference on Interoperating Geographic Information Systems.
251
NMEA (2000). NMEA 0183 Interface Standard. National Marine Electronics Association.
http://www.nmea.org/0183.htm.
Object Management Group (2003). OMG Unified Modeling Language Specification v. 1.5.
OMG Inc.
OpenGIS (1994). « OpenGIS ». http://www.opengis.org.
OpenGIS Consortium (2003). « OpenGIS Geography Markup Language (GML) Implementation Specification, v. 3 ». rapport, OpenGIS Consortium.
OpenMap (1998). « OpenMap - Open System Mapping Technologie, BBN Technologies ».
http://openmap.bbn.com.
Oracle Corporation (2001). « Oracle Spatial, An Oracle Technical White Paper ».
http://otn.oracle.com/products/oracle9i/pdf/OracleSpatial.pdf.
Sistla, A., Wolfson, O., Chamberlain, S., Dao, S. (1998). Querying the Uncertain Position of
Moving Objects. Temporal Databases : Research and Practice, p. 310–337. Springer.
Smallworld (1997). « GE Smallworld ». http://www.smallworld.co.uk.
Sondheim, M., Gardels, K., Buehler, K. (1999). GIS Interoperability. Longley, P., Goodchild,
M., Maguire, D., Eds., Geographical Information Systems : Principles, Techniques, Management and Applications, p. 347–358. Cambridge, GeoInformation International, second
edition.
Stockus, A., Bouju, A., Bertrand, F., Boursier, P. (2000). « Web-based Vehicle Location ».
IEEE Intelligent Vehicles Symposium (IV2000), Dearborn, USA, p. 436–441.
Stockus, A., Bouju, A., Bertrand, F., Boursier, P. (2001). « Accessing to Spatial Data in Mobile
Environment ». Proceedings of the 2nd International Conference on Web Information
Systems Engineering, p. 414–422.
Szmurlo, M., Gaio, M., Madelaine, J. (1998). « The Geographical Anteserver : a Client/Server
Architecture for GIS ». Strobel, J. , Best, C., Eds., Proceedings of the Earth Observation
& Geo-Spatial Web and Internet Workshop in "Salzburger Geographische Materialien",
vol. 27. Instituts für Geographie der Universität Salzburg.
Virrantaus, K., Veijalainen, J., Markkula, J., Katasonov, A., Garmash, A., Tirri, H., Terziyan,
V. (2001). « Developing GIS-Supported Location-Based Services ». First International
Workshop on Web Geographical Information Systems (WGIS 2001).
Wang, F. J., Jusoh, S. (1999). « Integrating Multiple Web-based Geographic Information
Systems ». IEEE MultiMedia, 6(1) :49–61.
Wessels, D., Claffy, K. (1998). « ICP and the Squid Web Cache ». IEEE Journal on Selected
Areas in Communications, 16(3) :345–356.
Wu, D., Agrawal, D., El Abbadi, A., Singh, A. (1996). « A Java-based architecture for digital
library storage ». SPIE, Photonics East, Voice, Video, and Data Communications, p. 23–24.