Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
SAGEO’2006, pages 00 à 00
Chargement et visualisation dynamiques de données géoréférencées pour un utilisateur mobile
Salvijus LAUCIUS, Alain BOUJU, Frédéric BERTRAND L3i Université de La Rochelle Pôle Sciences et Technologie 17042 La Rochelle Cedex 1 - FRANCE {prénom.nom}@univ-lr.fr
RÉSUMÉ. Dans cet article nous présentons différentes stratégies destinées à améliorer le chargement dynamique de données géoréférencées et leur visualisation sur un assistant personnel via une liaison de données à faible débit. L’objectif de l’outil développé est de pouvoir visualiser des données sur l’environnement géographique d’un utilisateur au fur et à mesure de son déplacement. L’architecture logicielle de cet outil, fondée sur un modèle client-serveur, gère un ensemble de zones de données superposées et permet leur évolution en fonction de la vitesse et la direction de l’utilisateur avec prise en compte de la densité des données à télécharger. Nous décrivons notre méthodologie d’évaluation et nous montrons que la stratégie développée améliore les situations dans lesquelles le client n’arrive pas à charger suffisamment rapidement les données par rapport au déplacement de l’utilisateur.
ABSTRACT. In this paper, we present strategies with objectives to optimize the dynamic loading of spatial data via a low bandwidth connection and to improve its visualization on PDA. A prototype system has been developed allowing visualization of user environment data based on user movement. Our system is based on client-server architecture. The prototype manages several overlayed data areas and adapts them to user’s speed and direction taking into accounts the density of data to be loaded. We describe our evaluation methods and we show that the developed strategy improves data loading in the cases when the client has some difficulties to load data rapidly according to user movement.
MOTS-CLÉS : visualisation, architecture client-serveur, service localisé, mobilité,
KEYWORDS: visualization, client-server architecture, location-based service, mobility
2 SAGEO’2006
1. Introduction
Nos travaux ont pour objectifs de fournir à un utilisateur mobile des informations
géographiques sur son environnement en prenant en compte sa position. L'évolution
des terminaux mobiles comme les assistants numériques, les téléphones mobiles et
les moyens de localisation permettent d'avoir à la fois des moyens de localisation
(GPS) et de transmission de données. Nous considérons un système de type client-
serveur permettant d'avoir un volume important de données géographiques sur un
serveur. Ces données peuvent être transférées sur un client mobile en fonction des
besoins comme, par exemple, pour l’obtention et la visualisation d’informations sur
l'environnement de l'utilisateur lors de son déplacement. Nous proposons une
architecture logicielle et matérielle pour répondre à ce besoin. Elle repose sur
l'utilisation de moyens de communications (GPRS1), de calcul (assistant personnel,
PDA) et de localisation (GPS2) largement répandus. Actuellement des applications
existent pour l'aide à la navigation. Elles utilisent des données fortement
compressées permettant le stockage de cartes complètes sur un PDA. Nous
proposons un chargement des données à la demande permettant d'obtenir des
données correspondant toujours à leur dernière mise à jour. Nous nous plaçons
également dans une perspective dans laquelle nous serons amené à gérer un volume
de données relativement important comme des données 3D ou des cartes possédant
une très grande densité d’information.
2. Travaux connexes
Dans (Wei et al, 1999) il est décrit un système de visualisation accédant
dynamiquement à un serveur de données géographiques mais l’architecture mise en
œuvre est assez différente car le client est un PC utilisant une liaison Internet à haut
débit. Une approche hiérarchique s’appuyant sur la notion de « niveaux de détail » et
un chargement asynchrone des données est décrite dans (Tu et al, 2001) mais, dans
ce cas également, le client est constitué d’une machine relativement riche en
ressources (puissance, mémoire).
Les méthodes de cache distribué sur plusieurs serveurs dans le domaine de LBS3
ont été développées (Wu et al 2003). Elles permettent d’évaluer et de charger des
données effectivement du serveur distant aux serveurs de cellules ayant dans leurs
zones des clients mobiles. Le cache sémantique a été proposé comme une alternative
aux techniques de cache de pages et de paquets dans (Dar et al 1996). Les « régions
sémantiques » introduites expriment la granularité de données moins fine que l’objet
1 General Packet Radio Service 2 Global Positioning Service 3 Location Based Services
Chargement et visualisation dynamiques de données pour un utilisateur mobile 3
Serveur
liaison
de
données
GPRS
GPS
Pocket PC
Client
Figure 1. Architecture globale du système
géographique. Les requêtes sont découpées en deux parties : une partie qui peut être
exécutée sur le client (probe query), car le cache contient de données dans cette
zone, et une deuxième qui doit être envoyée au serveur (remainder query). Dans
notre travail nous utilisons également ce découpage de requêtes en deux parties. Ren
et Dunham (Ren et al, 2000) ont développé une stratégie de la substitution du cache.
Cette stratégie, appelée FAR, choisit les résultats des requêtes à éliminer les plus
éloignés de la position actuelle de l’utilisateur. Au début, les résultats n’étant pas
dans la direction du déplacement sont sélectionnés, puis ceux dans la direction du
déplacement. Le travail le plus proche du notre est le « proactive caching »
développé par H. Hu (Hu et al, 2005). Cette technique inclut la gestion d’index et de
cache. Leur stratégie consiste à charger les nœuds de l’index visités et les objets
potentiellement absents dans le cache du client. Contrairement au travail de H. Hu,
nos stratégies d’indexation et de gestion du cache extraient chaque objet du cache de
client s’il y est présent.
Dans la section 3 nous décrivons l’architecture matérielle et logicielle sur
laquelle reposent nos travaux. Dans la section 4 nous présentons les concepts
définissant la gestion de la visualisation. La mise ne œuvre de ces concepts est
décrite dans la section 5. Puis nous présentons notre protocole d’expérimentation et
les résultats obtenus dans la section 6. La conclusion et les perspectives de notre
travail sont présentées en section 7.
3. Architecture globale
L'architecture que nous proposons (cf. Figure 1) est fondée sur une architecture
client-serveur (Fuggeta et al, 1998). Pour nos expérimentations, le client est un
assistant numérique, en l’occurrence un Compaq IPAQ h5550. Le serveur est un PC
disposant d’une bonne capacité de calcul, d'une connexion internet et d'espace
disque. Nous considérons un lien de communication de type GPRS. Ce moyen de
4 SAGEO’2006
communication est largement répandu et nous avons réalisé des expérimentations
montrant qu'il permet de visualiser des cartes (Stockus et al, 1999). Pour effectuer
nos expérimentations et permettre une mesure stable (ne dépendant pas des
fluctuations du réseau) des solutions proposées nous utilisons une liaison série (via
un câble null-modem) reliant le client et le serveur dont nous pouvons fixer la vitesse
de transmission. Nous pouvons ainsi effectuer des mesures de débits et de temps de
transfert en étant indépendant du nombre d'utilisateur du système. Un composant
logiciel a été développé permettant de « rejouer » des déplacements enregistrés lors
de trajets réels à partir d’un GPS. Pour effectuer le transfert de données nous
utilisons le protocole TCP/IP. Il nous permet d'utiliser la même application pour
l'utilisation d'une communication par téléphone mobile ou par un câble.
4. Gestion de la visualisation
Nous définissons un ensemble de zones nécessaires pour notre gestion des
données et de la visualisation. La partie de la carte affichée sur l’écran de
l’utilisateur est nommée « zone de visualisation » et nous la notons ZV (cf. Figure 2).
Comme les écrans utilisés sont de forme rectangulaire nous avons choisi de travailler
sur des zones possédant la même forme. Pour un bon fonctionnement de la
visualisation le client doit disposer de toutes les données affichables dans cette zone.
En raison du temps mis pour charger, à partir du serveur, les données sur le client, il
est nécessaire que ce dernier puisse posséder une zone de données plus importante
que la ZV. Cette zone, nommée « zone tampon » et notée ZT, permet au client de
disposer de données directement affichables lors d’un faible déplacement de
l’utilisateur. Les données de cette zone sont stockées dans ce que nous appelons un
cache de données. L’envoi d’une nouvelle requête au serveur s’appuie sur
l’évaluation de position future de l’utilisateur. Cette nouvelle requête est envoyée au
serveur lorsque le temps nécessaire pour charger les données associées à la future
position de l’utilisateur est égal au temps nécessaire pour atteindre cette position.
Grâce aux requêtes successives, le cache est enrichi et dispose ainsi des données
nécessaires à la prochaine visualisation. La contrainte de bon fonctionnement est que
la ZV doit toujours être inclue dans la zone correspondant à l’union des ZT déjà
chargées.
Figure 2. Définition des différentes zones intervenant dans la visualisation
Chargement et visualisation dynamiques de données pour un utilisateur mobile 5
Nous avons cependant remarqué que les rafraîchissements de la ZV dus à de
légers changements de position de l’utilisateur déclenchent systématiquement une
exécution d’une nouvelle requête sur le client. Afin de diminuer le nombre des
requêtes exécutées sur le client et améliorer la fluidité de l’affichage, nous avons
défini une « zone de recentrage » (notée « ZR », cf. Figure 2) incluse dans la zone de
visualisation. Grâce à la ZR, le déplacement de l’utilisateur dans cette zone ne
déclenche pas d’exécution de nouvelles requêtes. Une nouvelle requête est formée et
exécutée sur le client seulement lorsque la position actuelle de l’utilisateur
s’approche d’une des limites de la ZR. De cette manière nous réduisons le nombre
de requêtes exécutées sur le client et améliorons la fluidité de l’affichage.
5. Adaptation de la visualisation aux déplacements de l’utilisateur
5.1. Problématique
Le système doit pouvoir s'adapter aux changements de vitesse et de direction de
l'utilisateur ainsi qu'à la variation de la densité des données en particulier routière
entre par exemple un centre urbain et une zone de campagne. La principale
limitation du système est la vitesse de transfert maximale du lien de communication.
Cette contrainte correspond à un volume de données maximal pouvant être chargé à
partir du serveur pour un intervalle de temps donné. Notre objectif est de pouvoir
estimer la future position de l’utilisateur et de déterminer ainsi la zone qui sera
visualisée dans un avenir proche et donc les données devant être téléchargées. La
situation que l'on souhaite éviter est celle où des données nécessaires à l'affichage de
la zone de visualisation ne sont pas disponibles sur le client. Nous appelons cette
situation une « rupture de données ». Notre objectif a été d'étudier l'apparition des
ruptures et proposer des méthodes pour la retarder. Nous avons des informations sur
le déplacement de l'utilisateur, nous pouvons donc prendre en compte la position, la
vitesse et la direction de l’utilisateur. Pour évaluer le transfert des données nous
allons considérer comme paramètres :
− la zone de recentrage (ZR) ;
− la zone de visualisation(ZV) ;
− la zone tampon(ZT) ;
− le débit de la connexion.
Les trois paramètres de zone sont définis par l'application. Le débit de la
communication varie et il est estimé lors de son utilisation par le client. Pour la suite,
nous considérons que le client obtient du serveur la densité moyenne des données
devant être téléchargées. Lors de chaque déplacement, le client estime l’instant où il
devra effectuer une nouvelle requête pour obtenir les données manquantes. Nous
avons noté ii) sur la Figure 3 la position où le client effectue une requête pour
6 SAGEO’2006
obtenir des données pour la future position i correspondant au prochain affichage
effectué lorsque l’utilisateur atteint la limite de la zone de recentrage.
Nous considérons trois scénarios :
1. ZT=ZV
2. ZT= β ZV (on considère β > 1, avec une ZT plus grande que la ZV)
3. Déformation de ZT avec une surface = β ZV
Dans le premier scénario, la zone tampon correspond à la zone de visualisation.
Il faut pouvoir prévoir exactement la future position à l’instant de la réception des
données pour obtenir toutes les données nécessaires à l’affichage sinon le risque est
de ne pas disposer, à temps, de ces données lors de la mise à jour de la zone de
visualisation. Dans le second scénario, on agrandit la zone de données demandées au
serveur cela permet de compenser l’incertitude sur l’estimation de la position future
de l’utilisateur. Il faut effectuer un choix pour la taille de la ZT. Si cette zone est très
proche de la ZV on se retrouve dans la situation précédente (risques de données
incomplètes). Si ZT est choisie trop grande, on ne pourra obtenir les données assez
rapidement. Dans le troisième scénario, nous proposons d’effectuer une déformation
de la zone tampon permettant de mieux prendre en compte la direction de
déplacement de l’utilisateur.
5.2 Déformation de la zone tampon
Le principe consiste à déformer la surface de la zone tampon en prenant en
compte la direction de déplacement de l’utilisateur que nous notons ),( yx vvv = .
Nous cherchons à obtenir une déformation proportionnelle à la direction et avec une
surface constante afin de conserver une quantité de données équivalentes. De plus,
lors de la déformation, la ZV doit être maintenue à l’intérieur de la ZT.
Nous avons déterminé une relation de proportion entre ZTxetvx et
ZTyetv y . Soit un multiplicateur α tel que :
Figure 3. Déformation de la zone tampon
=
=
y
x
vZTy
vZTx
*
*
0
0
α
α
Chargement et visualisation dynamiques de données pour un utilisateur mobile 7
Nous considérons que la surface de ZT est constante donc nous pouvons en
déduire la valeur d’α en fonction de la valeur initiale ZTx0 et ZTy0. Cela permet
ainsi d’adapter la largeur et la hauteur de la fenêtre en fonction de la direction du
vecteur vitesse. Avec cette méthode se pose le problème de définition de la direction
lorsque la vitesse est nulle. Dans ce cas, nous considérons une fenêtre ZT
proportionnelle à la zone d’affichage ZV. Ce mécanisme permet de prendre en
compte l’orientation du vecteur vitesse mais nous devons également prendre en
compte le fait que la ZV doit être incluse dans la ZT. Nous présentons ces différents
cas sur la Figure 4.
Dans le cas i), lorsque l’utilisateur suit une direction faisant un angle de 45° par
rapport à l’écran on ne peut réaliser de déformation de la zone tampon (à surface
constante). Dans ce cas, nous n’obtenons pas de gain. Dans le cas ii), on effectue une
déformation proportionnelle à la direction de déplacement de l’utilisateur. Dans le
cas iii), la figure permet de montrer que la zone de visualisation n’est pas couverte
par la zone tampon. C’est une situation que l’on doit éviter. Dans ce dernier cas,
nous limitons la déformation à la taille de la fenêtre de visualisation cas iv).
Nous pouvons formaliser la déformation présentée sur la Figure 4 de la façon
suivante ( xv et yv correspondent au module des composantes du vecteur vitesse) :
1) 0== yx vv :
Si la vitesse de l’utilisateur est égale à zéro, la
forme de la zone tampon reste telle quelle était au
=
=
0
0
ZTyZTy
ZTxZTx
i
i
Figure 4. Déformation de la zone tampon (cas ZV carrée)
8 SAGEO’2006
=
=
0
0
*2
*
ZVx
ZTyZTxZTy
ZVxZTx
i
i
démarrage du système (à l’initialisation du client c'est-à-dire englobant la
zone de visualisation).
2) 00 >= yx vetv :
Si l’utilisateur se déplace selon un axe nord-sud,
la largeur de la zone tampon diminue jusqu’a
atteindre celle de la zone de visualisation. On fait
en sorte que la surface de la ZT reste constante.
3) 00 => yx vetv : ce cas est analogue au précédent
4) 00 >>≥ yxyx vetvetvv :
5) 00 >>≤ yxyx vetvetvv : ce cas est analogue au précédent.
Selon les directions de déplacement de l’utilisateur on calcule la hauteur et la largeur
de la zone ZT afin que la surface de ZT reste constante.
6. Expérimentations et résultats
Nous avons conçu un protocole pour tester les différents principes décrits dans la
section précédente. Ce protocole est constitué de plusieurs modules logiciels :
− le premier permet de créer des couches de données artificielles comportant une
densité de données prédéfinie avec des objets possédant une boite englobante
permettant de les indexer. Cela permet d’obtenir des couches de données
homogènes indépendantes des variations des données réelles.
− un second permet de générer des trajets ayant le même format que les trajets
réels enregistrés avec un GPS : ligne droite (est-ouest), et un déplacement selon
une trajectoire circulaire.
Notre travail à consister à évaluer les densités de données pouvant être utilisées avec
l'architecture proposée et un lien de communication de 56 kbits/s.
>
≤
=
>
≤
=
2
0
000
2
0
0000
2
0
00
0
00
2
0
0000
*,
*,
**
*,
*
*,
**
ZVy
ZTyZTx
v
vZVy
ZVy
ZTyZTx
v
v
v
vZTyZTx
ZTy
ZVy
ZTyZTx
v
v
ZVy
ZTyZTx
ZVy
ZTyZTx
v
v
v
vZTyZTx
ZTx
y
x
y
x
x
y
i
y
x
y
x
y
x
i
Chargement et visualisation dynamiques de données pour un utilisateur mobile 9
Nous présentons des résultats expérimentaux permettant d’évaluer les trois
scénarios. Pour les comparer et modifier facilement les paramètres d’utilisation, nous
avons considéré les déplacements suivants :
− un trajet rectiligne est-ouest à vitesse constante,
− un trajet circulaire,
− un trajet réel obtenu à l’aide d’un GPS lors d’un déplacement urbain en véhicule
Dans les figures suivantes (Figure 5, Figure 6 et Figure 8) nous avons un
ensemble de graphiques avec :
− en abscisse, le nombre de requêtes ayant été effectuées avec, en rouge, les objets
correspondant aux requêtes du client calculées sur le serveur et en bleu foncé,
les objets réellement disponibles sur le client au moment de l’affichage.
− en ordonnée, le nombre d’objets correspondant aux différentes requêtes.
− la densité des données artificielles est exprimée en octet/m².
Nous débutons nos graphiques à partir de la 12ième
requête pour avoir une
situation relativement indépendante des conditions initiales. Pour chaque figure,
chaque ligne correspond à des expérimentations avec des densités de données
différentes présentées en ordre croissant. Les densités présentées correspondent à
celles où on observe un changement de comportement. Les colonnes correspondent à
différentes gestions de la visualisation qui correspondent respectivement (de gauche
à droite) :
− aucune déformation n’est effectuée ;
− mise en œuvre de la déformation de la zone tampon.
12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44
0
50
100
150
200
250
300ZT non déformée (densité 0,042)
requêtes
objets
12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44
0
50
100
150
200
250
300ZT deformée (densité 0,042)
requêtes
objets
12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44
0
50
100
150
200
250
300ZT = ZV (densité 0,042)
requêtesobjets
12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44
050100
150200
250300350
ZT non déformée (densité 0,047)
requêtes
objets
12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44
0
50100
150200250300350
ZT deformée (densité 0,047)
requêtes
objets
12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44
0
50100
150200250300350
ZT = ZV (densité 0,047)
requêtes
objets
12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44
0
100
200
300
400
500ZT non déformée (densité 0,057)
requêtes
objets
12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44
0
100
200
300
400
500ZT deformée (densité 0,057)
requêtes
objets
12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44
0
100
200
300
400
500ZT = ZV (densité 0,057)
requêtes
objets
Figure 5. Nombre de ruptures détectées durant un trajet horizontal
10 SAGEO’2006
− cas où la zone tampon égale à celle de visualisation. Elle correspond ainsi à un
volume de transfert de données minimal.
Dans la Figure 5, nous présentons un trajet rectiligne est-ouest. Dans cette
configuration, la déformation de la zone tampon permet d’obtenir une amélioration
importante en diminuant de façon significative le nombre d’objets manquants. Dans
le cas le plus favorable (densité 0,057) nous pouvons noter une augmentation
d’environ 52% du nombre d’objets présents grâce à la mise en œuvre de la
déformation.
Lors d’un trajet circulaire (Figure 6) nous avons un changement continu de
l’orientation du déplacement de l’utilisateur, ce qui induit une erreur permanente
dans l’estimation du déplacement de l’utilisateur. Néanmoins la déformation de la
zone tampon permet une amélioration d’environ 28% du nombre d’objets manquants
(densité 0,052).
Dans le cas d’un trajet réel en zone urbaine, celui-ci est constitué d’un ensemble
de segments correspondant à des portions linéaires et circulaires (cf. Figure 7). En
analysant les résultats obtenus dans ce dernier test, présentés sur la Figure 8, on
12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80
0
50
100
150
200
250
300ZT non déformée (densité 0,042)
queries
objets
12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80
0
50
100
150
200
250
300ZT déformée (densité 0,042)
requêtesobjets
12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80
0
50
100
150
200
250
300ZT = ZV (densité 0,042)
requêtes
objets
1216 2024 28 3236 4044 48 5256 6064 68 7276 80
0
100
200
300
400ZT non déformée (densité 0,047)
requêtes
objets
1216 202428 3236 4044 4852 5660 6468 727680
0
100
200
300
400ZT déformée (densité 0,047)
requêtes
objets
121620 2428 3236 4044 4852 5660 6468 7276 80
0
100
200
300
400ZT = ZV (densité 0,047)
requêtes
objets
12 1620 24 28 32 36 40 4448 52 56 60 64 68 72 7680
0
100
200
300
400ZT non déformée (densité 0,052)
requêtes
objets
1216 2024 2832 36 4044 4852 5660 6468 72 7680
0
100
200
300
400ZT déformée (densité 0,052)
requêtes
objets
12162024 283236 40444852 566064 68727680
0
100
200
300
400ZT = ZV (densité 0,052)
requêtes
objets
Figure 6. Nombre de ruptures détectées durant un trajet circulaire
Figure 7. Trajet réel en milieu urbain
Chargement et visualisation dynamiques de données pour un utilisateur mobile 11
constate que la déformation de la zone tampon permet une amélioration notable par
rapport au cas où la déformation n’est pas appliquée.
Cependant, en fonction de la direction de déplacement de l’utilisateur, le gain est
n’est pas constant.
Par exemple lors d’un déplacement oblique, comme nous gérons des zones
rectangulaires, aucune déformation ne peut être appliquée et donc aucun gain ne peut
être constaté (cf. Figure 4, cas i).
7. Conclusion et perspectives
Nous avons présenté une méthode permettant d’améliorer l’affichage de données
géoréférencées sur un client mobile. Ces données, chargées « à la volée » à partir
d’un serveur, concernent l’environnement du client et leur chargement est lié à la
position de l’utilisateur. Nous avons défini un ensemble de zones permettant cette
gestion dynamique de la visualisation et diminuant le volume de données transférées
entre le client et le serveur. Associées à la zone tampon, une opération d’ajustement
fondée sur la vitesse de l’utilisateur et le débit du lien de communication permet
d’améliorer le chargement des objets à partir du serveur. Nous diminuons ainsi le
nombre de situations où le client subit des ruptures de données c’est-à-dire où il ne
peut afficher la totalité des objets présents dans la zone de visualisation. Bien qu’il
existe actuellement des produits commerciaux permettant une aide à la navigation
(TomTom, 2003), notre approche vise dans un futur proche à permettre la
visualisation des données 3D qui, en raison de leur taille, peuvent difficilement être
stockés sur des assistants personnels.
Nous travaillons actuellement sur le chargement de données (notamment sur les
tailles de zones optimales) et la gestion du cache stockant ces données sur le client.
12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76
0
50100
150200
250300
350ZT non déformée (densité 0,042)
requêtes
objets
12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76
0
50100
150200
250300
350ZT déformée (densité 0,042)
requêtes
objets
12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76
0
50100
150200
250300
350ZT = ZV (densité 0,042)
requêtes
objets
12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76
0
100
200
300
400ZT non déformée (densité 0,047)
requêtes
objets
12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76
0
100
200
300
400ZT déformée (densité 0,047)
requêtes
objets
12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76
0
100
200
300
400ZT = ZV (densité 0,047)
requêtes
objets
12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76
0
100
200
300
400ZT non déformée (densité 0,052)
requêtes
objets
12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76
0
100
200
300
400ZT déformée (densité 0,052)
requêtes
objets
12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76
0
100
200
300
400ZT = ZV (densité 0,052)
requêtes
objets
Figure 8. Nombre de ruptures détectées durant un trajet réel
12 SAGEO’2006
Nous cherchons à définir des règles permettant de charger les données « les plus
utiles » au client et de vider régulièrement le cache pour éviter sa saturation tout en
conservant certaines informations sur les objets amenés à être supprimés. Un autre
axe consiste dans l’intégration de la gestion de données multi-échelles développées
dans (Follin et al, 2004).
Bibliographie
Bouju A., Stockus A., Bertrand F., Boursier P., « Architecture d’un système d’information
géographique mobile », Revue internationale de géomatique, vol. 13, n° 2, 2003, p. 225–
251
Dar S., Franklin M. J., Jonsson B., Srivastava D., Tan M.. « Semantic data caching and
replacement », In Proceedings of VLDB, p. 330–341, 1996.
Follin J.M., Bouju A., Bertrand F., Boursier P. « Multi-resolution extension for transmission
of geodata in a mobile context ». Computers and Geosciences. Special issue on Geospatial Research in Europe: Agile 2003.2004 31(2), p 179-188.
Fuggeta G., Picco G. « Understanding code mobility ». IEEE Transactions on Software
Engineering, 24(5) p. 342-361, May 1998
Hu H., Xu J., Wong W. S., Zheng B., Lee D. L., Lee W.-C., « Proactive caching for spatial
queries in mobile environments ». In Proceedings of the 21th IEEE Int. Conf. on Data Engineering, Tokyo, Japan, 2005.
Laucius S., Bertrand F., Stockus A., Bouju « A.Query management and spatial indexing in
mobile context ».Proceedings of 8th AGILE Conference on Geographic Information Science, p. 429-438 Lisboa, Portugal, May 2005
Ren Q., Dunham M. H., « Using semantic caching to manage location dependent data in
mobile computing », In Proceedings of the MOBICOM Conference, p. 210–221, 2000.
Stockus A., Bouju A., Bertrand F., Boursier P., « Integrating GPS Data within Embedded
Internet GIS », 7th International Symposium on Geographic Information Systems (ACM GIS’99), 1999, p. 134–139.
TomTom Navigator www.tomtom.com, 2003
Tu S., He X., Li X., Ratcliff J. J., « A systematic approach to reduction of user-perceived
response time for GIS web services », Proceedings of the ninth ACM inter-national symposium on Advances in geographic information systems, ACM Press, 2001, p. 47–52.
Wei Z.-K., Oh Y.-H., Lee J.-D., Kim J.-H., Park D.-S., Lee Y.-G., Bae H.-Y., « Efficient
spatial data transmission in Web-based GIS », Proceedings of the second inter-national workshop on Web information and data management, ACM Press, 1999, p. 38–42.
Wu S., Wu K. T., « Dynamic Data Management for Location Based Services in Mobile
Environments, » ideas, In Proceedings of the Seventh International Database Engineering and Applications Symposium (IDEAS'03), p. 180-191, 2003.