generation cartographique a la volee pour des terminaux mobiles

BOUBAKER BOULEKROUCHE
GENERATION CARTOGRAPHIQUE A LA VOLEE
POUR DES TERMINAUX MOBILES DE TYPE PDA
Mémoire présenté
à la Faculté des études supérieures de l'Université Laval
dans le cadre du programme de maîtrise en informatique
pour l'obtention du grade de Maître es Sciences (M. Se.)
DEPARTEMENT D'INFORMATIQUE ET DE GENIE LOGICIEL
FACULTÉ DES SCIENCES ET GÉNIE
UNIVERSITÉ LAVAL
QUÉBEC
2006
© Boubaker Boulekrouche, 2006
Résumé
Notre société est caractérisée par l'utilisation à grande échelle des équipements mobiles
tels que téléphones cellulaires, assistants personnels et toutes autres sortes d'appareils
embarqués. Avec l'évolution récente dans le domaine des réseaux sans fil et leur
intégration à l'Internet, on assiste à une augmentation de la demande pour des services
cartographiques accessibles par des appareils de plus en plus variés. Le but du présent
travail est d'offrir un service permettant la production et la livraison des cartes sur le Web
pour des terminaux mobiles de type PDA (Personal Digital Assistant). Cependant, la
génération des cartes sur le Web pour des terminaux mobiles constitue un grand défi, non
seulement le temps de génération de la carte doit être le plus court possible, mais il faut
que la production de la carte s'adapte aux différentes contraintes de l'environnement
mobile (caractéristiques techniques limitées des terminaux mobiles, faiblesse et instabilité
de transfert de données, etc). Pour relever ce défi, nous avons opté pour une approche
appelée «génération et transmission des cartes par couches d'intérêt », une approche
basée sur l'utilisation d'une base de données à représentations multiples et un système
multiagent pour la génération et l'adaptation de la carte finale en fonction des contraintes
liées au contexte mobile.
11
Abstract
Nowadays, the use of mobile devices such as cellular phones, personal assistants is
increasing Worldwide.
The récent advances in the field of the wireless networks and their intégration with the
Internet, results in the increased need for cartographie services accessible using mobile
devices. The goal of this work is to offer a service allowing the production and the
delivery of Web maps for PDA (Assisting Personal Digital).
Furthermore, in order to generate maps on-the-fly for mobile devices, we must deal with
several challenges. Indeed, in addition to processing time which must be short, we hâve
to adapt the maps to the various constraints of the mobile environment (small amount of
memory slow processor, display size, bandwidth, etc).
In order to overcome thèse
challenges, we chose an approach called " a progressive automatic map génération based
on loyers of interest ", this approach is based on the use of a multiple représentation
database and a multiagent System for the génération and the adaptation of maps according
to the mobile context constraints.
111
Préface
« Ç foire à Toi ! [Nous n'avons de savoir que ce que Tu nous asappris.
Certes c'est Toi COmniscient, Ce Sage»
«ÇCory to Theel <We hâve no knowCedge but that which Thou hast
taught us; sureCy Thou art the Xnowing, the Wise »
(Coran, 2:32)
IV
Dédicaces
C'est avec un immense plaisir que je dédie ce travail :
A la mémoire de mon père Mohamed Salah
(qu'Allah ait son âme en paix)
A ma mère Zoubida et mes grands-parents qui ont
sacrifié leur vie toute entière pour m'amener là où je
suis maintenant
A ma chère épouse et ma complice de vie Karima
pour m'avoir soutenu tout au long de mon périple
A mon cher fils Nour-lslam qui épice ma vie et
qui la rend plus joyeuse
A mes frères khiereddine, Bilal, Hamza et ma
seour Nadjla
A ma grande famille, tantes et oncles, cousins et
cousines, pour tout l'amour que vous portez pour moi.
A mes collègues et mes amis qui m'ont aidé dans
l'élaboration de ce travail
Remerciements
J'aimerais tout d'abord remercier mon directeur de recherche
Bernard Moulin qui m'a dirigé tout le long de ma maîtrise avec
sérieux et générosité. Qu'il veuille bien à travers ces lignes accepter
l'expression de ma profonde gratitude.
J'aimerais remercier tout le personnel du département informatique
et du centre de recherche en géomatique de l'université Laval,
Je tiens à remercier les professeurs Nadir Belkhiter et Jean-Marie
Beaulieu d'avoir accepté généreusement d'examiner mon
mémoire et d'assister à ma soutenance orale.
Je remercie infiniment tous les professeurs qui ont participé à mes
études primaires, moyennes et secondaires : Bendir Mohamed,
Nemiri Mahfoudh, Brahimi Hasnaoui, Kachotte Dalila, Kouzi
Yamina, Daif Zakia, Bouseta, Metarfi Nacéra, Sayed Mohamed,
Mansouri Abdelwaheb, Amrane Layachi, Mansouri Aissa, Gharbi
Noura, Mansouri Halima, Mansouri Farouk, Jamai Amar, Fisli
Houcine, Atoui Noura, Nemiri Moussa, Boulekrouche Noureddine,
Boulekrouche Allaoua, Boulekrouche Salah, Serghini Farida,
Chraifia Amar, Mansouri Miloud , Lamamra Zaghdoud, Walhasi
A/Hafid, Boulechfar, Bouchrouk Elarbi, Lehmaza Noura, Hajouji
Saleh, Attek Laila, Zaidi Hacenne, Gmihi Houes, ...etc. Je prends
ici le temps de sincèrement les remercier et je leur dois à tous, une
partie importante de cette recherche,
Je tiens à exprimer ma sincère gratitude à mon pays l'Algérie qui
m'a offert une bourse pour mener à terme ma maîtrise.
VI
Table des matières
Chapitre 1 : Introduction générale
2
1.1 Contexte et problématique
3
1.2 Objectifs et démarche suivie
5
1.3 Structure du mémoire
6
Chapitre 2 : Revue de la littérature
8
2.1 Introduction
8
2.2 Technologies mobiles
8
2.2.1 Terminaux mobiles
8
2.2.2 Réseaux mobiles
9
2.2.3 Technologies de localisation
11
2.3 Cartes géographiques
12
2.4 Génération des cartes sur le Web dans un contexte mobile
14
2.4.1 Contraintes de génération de carte pour des terminaux mobiles
14
2.4.1.1 Contraintes liées au système :
14
2.4.1.2 Limitations liées au contexte utilisateur :
15
2.4.2 Gestion de données
15
2.4.2.1 Généralisation à la volée
16
2.4.2.2 Représentation multiple
21
2.4.3 Transmission progressive de données
25
2.4.4 Visualisation de données
27
2.5 Conclusion
Chapitre 3: Solution proposée
31
33
3.1 Introduction
33
3.2 Architecture et fonctionnement du système SIGERT
33
3.3 Génération et transmission progressive des cartes par couches d'intérêt
35
3.3.1 Modèle de données à représentations multiples
38
3.3.2 Génération des cartes à la volée à base d'agents logiciels
40
3.3.3 Visualisation progressive de données par couches d'intérêt
44
3.4 Conclusion
48
Vil
Chapitre 4 : Le service SIGERT-Mobile
50
4.1 Introduction
50
4.2 Présentation du système SIGERT
50
4.3 Choix technologiques
54
4.3.1 La base de données géographiques du Système SIGERT
54
4.3.2 La base de données utilisateurs
54
4.3.3 Utilisation du Framework .NET pour le développement du SIGERT-Mobile 55
4.3.4 Développement des modules de traitement et de catégorisation
56
4.3.5 Choix d'un PDA pour tester le service SIGERT-Mobile
57
4.3.6 Choix technologique pour le développement d'un viewer SVG pour PDA.... 57
4.4 Développement du service SIGERT-Mobile
59
4.4.1 Préparation de données
59
4.4.2 Présentation du développement du service SIGERT-Mobile
61
4.4.3 Développement du viewer SIGERT-Mobile
68
4.5 Le prototype SIGERT-Mobile
72
4.6 Discussion des avantages de l'approche utilisée
75
4.7 Conclusion
79
Chapitre 5: Conclusion générale
81
5.1 Conclusion
81
5.2 Travaux futurs
83
Bibliographie
85
Annexes
92
Vil
Liste des figures
Figure 1 : Architecture générale du projet GEMURE et place de SIGERT
Figure 2 : Architecture générale de l'intégration de l'Internet aux réseaux sans
3
fil
10
Figure 3 : Critère de résolution spatiale
13
Figure 4 : Opérateurs de généralisation ESRI
19
Figure 5 ; Multiplicité géométrique et graphique
22
Figure 7 : Réutilisation d'objets entre deux niveaux de détail
26
Figure 8 : a) Système de navigation, (b) LBS et (c) Guides de cartes urbaines
28
Figure 9 : Affichage adapté des données à différents LoDs
29
Figure 10 : Affichage de cartes à grande et à petite échelle
29
Figure 11 : Affichage de carte à échelle variable
30
Figure 12 : Carte schématique
30
Figure 13 : Architecture générale du système SIGERT
34
Figure 14: (a) Carte basée sur le réseau routier et (b) Carte avec plus de détail
36
Figure 15: Génération et transmission progressive de cartes par couche d'intérêt
37
Figure 16 : Diagramme UML du modèle de données à représentations multiples
39
Figure 17 : Exemple de fichier GML à représentation multiple
40
Figure 18 : Contraintes de conflits spatiaux
41
Figure 19 : Architecture multicouches du système multiagent
43
Figure 20 : Cartes au format SVG Basic affichée sur PDA : (gauche) viewer Pocket
SVG, (droite) viewer Tinyline
46
Figure 21 : Visualisation progressive des couches d'intérêt sur le terminal client
47
Figure 22 : Architecture du système SIGERT
51
Figure 23 : Série de traitement des données du système SIGERT
60
Figure 24 : Indexation des objets géographiques en utilisant une grille orthogonale
61
Figure 25: Méthodes de la classe SpatialQuery
62
Figure 26: Méthodes de la classe « RequeteExist »
63
Figure 27 : Exemple de fichier SVG Tiny adapté au contexte mobile
65
Figure 28 : Génération des symboles pour des terminaux mobiles
66
Figure 29 : Diagramme de classe du viewer SIGERT-Mobile
68
Vlll
Figure 30: Description de la méthode Display_NR()
69
Figure 31 : Description des méthodes Displayjayer () et InsertJayerQ
70
Figure 32 : Description des méthodes Disply_desc () et Extract_desc ()
71
Figure 33 : (a) Sélection de la zone de recherche, (b) Sélection des objets à afficher .. .72
Figure 34 : (a) Affichage de la couche RR, (b) Affichage de la couche RR+OED,(c)
Zoom sur la couche RR+OED
73
Figure 35 : (a) Affichage de la couche RR+OED+OR, (b) Affichage de la couche
RR+OED+OR+OO
74
Figure 36 : Comparaison entre les deux approches selon le temps génération
76
Figure 37 : Comparaison entre les deux approches selon le temps d'attente
77
Figure 38 : Comparaison des deux approches selon le coût de transfert de la carte
78
IX
Liste des tableaux
Tableau 1 : Avantages et inconvénients de la généralisation à la volée et la
représentation multiple
23
Chapitre I
Introduction Générale
Chapitre 1 : Introduction générale
Notre société est caractérisée par l'utilisation à grande échelle des équipements mobiles
(ordinateurs de poche, téléphones cellulaires, systèmes de localisation GPS). La dernière
décennie a été marquée par l'évolution rapide des technologies liées à Internet et aux
technologies mobiles, ce qui a incité la naissance de l'Internet sans fil.
Avec l'évolution récente dans le domaine des réseaux sans fil et leur intégration à
l'Internet, on assiste à une augmentation de la demande pour des services cartographiques
accessibles par des appareils de plus en plus variés. Ces services sont d'un apport
indéniable pour l'organisation et la gestion des activités des utilisateurs nomades et en
particulier celles manipulant des données géographiques.
La génération à la volée de cartes sur le Web pour des terminaux mobiles implique que la
carte soit produite en fonction des préférences des utilisateurs, et qu'elle doive s'adapter
au contexte d'utilisation du service cartographique et aux contraintes de la mobilité de
l'utilisateur. Dans une étude indépendante faite par le Cambridge Stratégie Management
Group (CSMG 2001), l'accessibilité de l'information a été suggérée comme un des
critères les plus importants pour le succès d'un service géospatial en ligne. Ces études
montrent que les services actuels doivent être améliorés. En d'autres termes, les questions
de format de données, d'interopérabilité, du traitement à la volée des données
géographiques et de leur transfert rapide et fiable doivent être réexaminés. A cet effet, de
nouvelles méthodes et techniques doivent être mises en place (Gbei et al. 03).
Dans un premier temps, nous allons aborder dans ce chapitre le contexte de notre travail
ainsi que la problématique. Dans un deuxième temps, nous allons énumérer l'objectif
général ainsi que les objectifs spécifiques qui résultent de cette problématique et que nous
souhaitons atteindre dans ce travail. De plus, nous exposerons la démarche de notre
recherche. Enfin, nous terminerons avec la structure du mémoire en présentant
brièvement tous les chapitres subséquents.
1.1 Contexte et problématique
La recherche présentée ici s'inscrit dans le cadre du projet GEMURE (« Generalization
and Multiple Représentation for On-Demand Map Production and delivery»), projet
financé par le réseau GEOIDE (« GEOmatics for Informed DEcisions »). Ce projet vise à
fusionner plusieurs sources de données, essentiellement hétérogènes, dans un entrepôt de
données (Data Warehouse) qui sera exploité en spécialisant l'information qu'il contient
dans des bases de données pivots (Datamarts). Ces bases de données servent, ensuite, à
fournir des services cartographiques aux utilisateurs, selon leurs besoins et leurs
préférences.
Nous projetons d'utiliser un datamart du projet GEMURE dans le but de fournir un
ensemble de services touristiques et récréatifs aux utilisateurs. Ce paquet de services est
regroupé dans le cadre du système SIGERT (Système Intelligent pour la Gestion des
Espaces Récréatifs et Touristiques), voir figure 1.
Importation
Intégration
Généralisation
édition manuelle
appartement des données
classification des pattems
Figure 1 : Architecture générale du projet GEMURE et place de SIGERT
Le développement en cours du système SIGERT (Gbei et al. 03) met l'emphase sur la
génération automatique des services cartographiques sur le Web pour des ordinateurs de
bureau. Dans l'optique d'augmenter l'utilité du système SIGERT, il serait important de
pouvoir livrer un service cartographique multimodal (service pour desktop, service sur
PDA [Personal Digital Assistant]) à travers SIGERT.
De cette orientation émane la problématique essentielle du présent travail: comment
peut-on étendre le système SIGERT pour qu'il supporte un service cartographique
multimodal automatique?
Un problème sous-jacent à la génération cartographique sur le Web est celui de la
production à la volée de cartes permettant de présenter les informations demandées par
l'utilisateur en fonction de son contexte d'utilisation (le lieu, l'environnement). La
production automatique et efficace de cartes sur le Web pour des terminaux mobiles fait
face à des contraintes additionnelles par rapport à celles touchant les ordinateurs de
bureau : la production doit s'accommoder aux caractéristiques techniques plutôt limitées
des terminaux mobiles, notamment la faiblesse et l'instabilité du transfert de données, les
capacités réduites en termes de calcul, de stockage, etc. Ces contraintes influent sur la
gestion et la visualisation des données géographiques. Par conséquent, un système de
génération automatique des cartes pour des terminaux mobiles de type PDA doit être
adapté aux contraintes de la mobilité de l'utilisateur.
Nous nous proposons de développer le service SIGERT-Mobile : une extension du
système SIGERT permettant la génération cartographique pour des terminaux de type
PDA. Ce système s'appuie sur une approche qui combine l'utilisation d'une base de
données à représentations multiples, la généralisation cartographique à base de systèmes
multiagents et la transmission progressive de données entre le serveur et le client mobile.
1.2 Objectifs et démarche suivie
Dans le cadre de ce mémoire de Maîtrise, notre objectif principal est d'étendre le système
SIGERT pour qu'il supporte un service cartographique multimodal automatique (service
pour des ordinateurs de bureau, service pour PDA). Pour atteindre ce but, nous nous
sommes fixés les objectifs spécifiques suivants:
•
Premièrement, nous étudierons les concepts théoriques relatifs à la génération
cartographique sur le Web dans un contexte mobile.
•
Deuxièmement, nous devrons identifier les contraintes liées à la génération
automatique des cartes dans un contexte mobile (caractéristiques de l'écran
d'affichage, la bande passante pour le transfert des données, la capacité de
calcul du terminal de l'utilisateur, etc.) et leurs influences sur le service
cartographique à fournir à l'utilisateur mobile.
•
Troisièmement, nous proposerons une approche permettant l'extension du
système SIGERT pour qu'il supporte un service de génération automatique
des cartes sur PDA.
•
Finalement, nous présenterons le développement du
service SIGERT-
Mobile : un service du système SIGERT permettant la génération
cartographique sur le Web pour des terminaux de type PDA.
Afin d'atteindre nos objectifs, nous avons commencé par une étape d'exploration des
domaines connexes qui tournent autour de la génération cartographique à la volée pour
des terminaux mobiles. Pour cela, nous avons fait une étude bibliographique en nous
concentrant principalement sur les différentes approches qui ont été utilisées pour la
gestion et la visualisation des données géographiques dans un contexte mobile. Cette
exploration nous a permis de définir une approche permettant au système SIGERT de
générer des cartes pour des terminaux mobiles. Dans le but de valider l'approche
proposée, nous avons
développé SIGERT-Mobile, un service du système SIGERT
permettant la génération automatique des cartes pour des terminaux mobiles de type
PDA.
1.3 Structure du mémoire
Le présent mémoire est structuré en cinq chapitres. Le premier et le dernier représentent
l'introduction et la conclusion générale. Alors que les trois autres chapitres visent à
répondre aux objectifs de notre recherche.
Le présent chapitre est une introduction générale renfermant le contexte et la
problématique du travail effectué. De plus, il énumère nos objectifs et présente les
différents chapitres du mémoire.
Dans le deuxième chapitre de ce mémoire, nous présentons une revue des concepts
théoriques sur lesquels nous avons basé notre recherche, notamment la gestion et la
visualisation de données géographiques dans un contexte mobile et les technologies
mobiles.
Le troisième chapitre présente l'approche adoptée pour la génération à la volée des cartes
sur le Web pour des terminaux mobiles. Nous commençons par présenter la nouvelle
architecture du système SIGERT. Ensuite nous détaillons l'approche proposée appelée
« génération et transmission progressive des cartes par couche d'intérêt ».
Dans le quatrième chapitre nous présentons le prototype développé dans le but de valider
l'approche proposée pour la génération cartographique sur le Web dans un contexte
mobile. Nous donnons également des détails sur les fonctionnalités de ce prototype.
Le dernier chapitre est une conclusion générale contenant une synthèse des travaux
effectués ainsi qu'une discussion sur les résultats obtenus. Nous y faisons aussi des
suggestions de recherches futures qui peuvent améliorer la génération cartographique sur
le Web pour des terminaux mobiles dans le cadre du système SIGERT.
ChapitreII
Revue de la littérature
Chapitre 2 : Revue de la littérature
2.1 Introduction
Cette revue de la littérature vise à faire un état de l'art sur les concepts théoriques sur lesquels
nous avons basé notre recherche, notamment la gestion et la visualisation de données
géographiques dans un environnement mobile. L'objectif principal de notre recherche étant de
proposer une solution pour la génération des cartes sur le web pour des terminaux mobiles.
Afin de mieux saisir les problèmes entourant la génération des cartes pour des terminaux
mobiles, nous allons présenter en premier lieu les différentes technologies mobiles. Ensuite,
nous présenterons quelques concepts gravitant autour de ces notions : carte, échelle, résolution.
Dans la section suivante, nous allons explorer les solutions existantes pour la gestion et la
visualisation de données géographiques dans un environnement mobile.
2.2 Technologies mobiles
L'utilisation à grande échelle des périphériques mobiles de communication (téléphone
cellulaire, PDA et GPS) a favorisé l'accès à des informations géographiques liées à la
localisation de l'utilisateur. Nous esquissons dans cette section les différentes technologies
liées à l'environnement mobile tels que : les terminaux mobiles, les réseaux mobiles et les
dispositifs de localisation.
2.2.1 Terminaux mobiles
On distingue plusieurs types d'équipements mobiles, parmi les plus importants il y a :
Les téléphones cellulaires: ces terminaux ont des capacités d'affichage limitées et ne
permettent pas l'installation de logiciels supplémentaires.
Les smart Phones : ce sont des téléphones cellulaires possédant un système d'exploitation et
permettant l'installation de logiciels supplémentaires;
Assistant Personnel Numérique (PDA) : Un assistant personnel numérique est un petit
ordinateur qui tient dans la poche et qui fonctionne grâce à un écran tactile. Tout se pilote
grâce à un stylet et aux boutons intégrés à la machine.
Le développement du marché des PDA passe par la mise à disposition sur ces terminaux, d'un
nombre croissant d'applications présentes sur les PC et d'un accès à l'Internet. Ce
développement est rendu possible actuellement par, les performances actuelles des processeurs
Low-Power et Low-Voltage et par la capacité sans cesse croissante des mémoires. Un autre
facteur important qui concout au développement des PDA est la facilité de mise en œuvre de la
technologie d'objets répartis qui ouvre des possibilités d'échanges de données et
d'applications entre l'environnement logiciel du PDA et d'autres environnements différents.
Le PDA est incontestablement un bon exemple de terminal grand public avec un système
embarqué. L'intérêt croissant manifesté pour les PDA est lié à la fusion avec les mobiles. En
effet, les capacités de ces produits les positionnent comme des terminaux d'accès à Internet à
part entière, que ce soit par modem ou sans fil (protocole WAP : Wireless Access Protocol).
Cet intérêt est également lié à la possibilité de mise à jour et de sauvegarde aisée sur un PC
associé.
Un PDA possède généralement un écran de 5 pouces d'une résolution moyenne de 240 * 320
pixels et peut afficher jusqu'à 65000 couleurs. La plupart des PDAs possèdent des cartes
d'extension de type Secure Digital (SD), Compact Flash (CF). Une carte d'extension pourrait
être une extension mémoire, un module GPS ou une caméra numérique.
Il existe plusieurs types de PDAs. On les différencie selon le système d'exploitation sous
lequel ils fonctionnent : Les PDAs sous POCKET PC1 (HP, ASUS, CASIO, FUJITSU
SIEMENS, DELL, COMPAQ, TOSHIBA), les PDAs sous Palm OS2 (handspring, Palm, Sony
clié), les PDAs sous Linux OS3 (SHARP, YOPI), etc.
2.2.2 Réseaux mobiles
Les ordinateurs mobiles tels que : les ordinateurs portables et les PDAs, peuvent communiquer
à travers un réseau mobile. Un réseau mobile est composé généralement de cellules. Dans
chaque cellule, on trouve une station de base (BTS : Base Station Transciever), ces stations de
base sont des antennes permettant la gestion des appels vers ou en provenance des terminaux
mobiles situés dans leur zone de service. Les stations de base sont connectées au réseau câblé
et communiquent avec les terminaux mobiles via des liaisons radio.
1
Pocket PC : http://www.microsoft.com/windowsmobile/pocketpc/defanlt.mspx
Palm OS : http://www.palm.com/
3
Linux OS : http://www.linux.org/
2
10
Actuellement le réseau GSM (Global System for Mobile communication) est le standard le
plus utilisé dans la téléphonie mobile ; il offre une bande passante d'environ 9,6 Kbit/s. Pour
bénéficier d'un taux de transfert plus élevé et approprié à la transmission de données, des
nouveaux standards de troisième génération (3 G) tels que UMTS (Universai Mobile
Télécommunications System) et GPRS (General Packet Radio Service) ont été proposés
(Siemens, 05).
UMTS est conçu essentiellement pour l'Internet mobile avec un taux de transfert théorique de
2 Mbits/s, ce qui a favorisé le développement et le déploiement des nouveaux services et
applications Internet (Messagerie, multimédia, services géolocalisés et bien d'autres).
Station de base
3
Terminal mobile
Terminal mobile
Figure 2 : Architecture générale de l'intégration de l'Internet aux réseaux de données sans fil.
11
La figure 2 présente un exemple d'intégration de l'Internet aux réseaux de données sans fil
Le réseau UMTS est basé sur des protocoles de haut niveau pour la commutation de circuits et
la commutation de paquets (i.e le dispositif mobile est constamment connecté au réseau). Les
utilisateurs des réseaux 3 G paient les frais de communication selon le volume de données
transféré vers et en provenance du terminal mobile et non pas en fonction du temps de
connexion.
2.2.3 Technologies de localisation
II y a trois approches de localisation des terminaux mobiles (Swedberg 1999):
Positionnement basé sur le réseau (Network-based positioning) : cette approche calcule la
position du terminal mobile en fonction du temps de propagation du signal entre le terminal
mobile et la station de base.
Positionnement basé sur l'équipement (Device-based positioning) : dans cette approche le
terminal mobile dispose d'un module GPS permettant de calculer la position avec une
précision de 10 à 20 mètres.
Approche de localisation hybride : dans cette approche, la position de l'utilisateur est
calculée en combinant les deux approches citées ci-dessus, un exemple A-GPS (Assisted
GPS).
La précision de calcul de localisation dépend de l'environnement
de l'utilisateur (ville,
montagne) et de la méthode de calcul utilisée. Le choix d'une technique de localisation dans
un contexte mobile dépend du but d'utilisation de l'information de localisation (i.e il est inutile
de chercher une précision de localisation de l'ordre du centimètre si on cherche à visualiser la
position de l'utilisateur sur une carte à petite échelle).
12
2.3 Cartes géographiques
« Les cartes géographiques fournissent une représentation graphique du monde réel qui
permet au lecteur de voir la localisation des objets ou des phénomènes qui l'intéressent »
(IGN).
L'échelle d'une carte est le « facteur d'homothétie entre la taille sur le terrain des entités et la
taille de leur représentation sur une carte. Taille=Taille-terrain x Echelle » (Ruas et al,
02). Sur un support papier, la distance est mesurée en centimètres. Par exemple, à l'échelle
1/50000, une distance de 1 centimètre sur une carte correspond à une distance réelle de 500
mètres. Une carte à grande échelle permet de visualiser plus de détails qu'une carte à petite
échelle.
L'échelle correspond aussi à l'adaptation d'une carte à des besoins particuliers des
utilisateurs.
L'IGN
(Institut
Géographique
National
France)
génère
des
cartes
topographiques à une échelle de 1/25000 pour les randonnées, des cartes recommandées
pour les promenades à vélo (1/50000) et les cartes destinées aux promenades touristiques
(1/100000).
Une autre caractéristique importante pour les cartes est la résolution du support de dessin
qui est « la taille de la plus petite unité dessinable (comptée en points par millimètre ou en
dpi - dotper inch) » (Ruas et al, 02a).
Une carte numérique (affichée sur un écran) n'a pas d'échelle intrinsèque car elle peut être
visualisée à n'importe quelle échelle avec les fonctions de zoom (Duchene, 04). D'un autre
point de vue, une base de données géographique ne possède pas d'échelle, mais elle est faite
pour une gamme d'échelle. Ainsi, il est facile de générer une carte possédant une échelle
proche de l'échelle de saisie de la base de données.
Une carte numérique est caractérisée aussi par sa résolution. La résolution est la taille du
plus petit détail significatif que contient une carte.
Elle possède deux composantes
(Vangeno, 01) :
-La résolution sémantique se traduit par le schéma de données. Lorsque celui-ci est basé sur
une représentation objet, il peut être structuré sous la forme d'une organisation hiérarchique
dans laquelle, on trouve des relations de type généralisation/spécialisation.
13
-La résolution spatiale représente la taille du plus petit objet géographique sur une carte,
elle est définie par trois critères (Follin, 04) (figure 3) :
-
La taille minimale que doit avoir un objet pour être visible sur la carte : superficie
(1), largeur (2) pour un objet surfacique, et longueur pour un objet linéaire,
-
La distance minimale (3) séparant deux objets, pour pouvoir les discerner,
-
La taille minimale d'un détail (4) pour pouvoir le conserver.
Figure 3 : Critère de résolution spatiale (tiré de Follin, 04)
Ces tailles minimales sont appelées généralement tailles de lisibilité et elles sont liées aux
capacités visuelles en terme de seuils de perception et distinction.
Les seuils de perception correspondent à la capacité de différencier les symboles à l'oeil nu.
Une ligne doit avoir une largeur minimum de 0,1 mm pour être perceptible, un cercle un
diamètre d'au moins 0,2 mm et un carré un côté d'au moins 0,4 mm (Boffet, 01).
Les seuils de séparation représentent la distance minimale devant séparer deux entités
graphiques pour pouvoir les distinguer à l'œil nu. Ils dépendent des types d'objets, leurs
couleurs et leurs positions. Ils varient entre 0,15 et 0,2 mm.
Ces valeurs minimales sont valables pour une résolution papier d'environ 0,04 mm. Pour un
PDA la résolution moyenne est d'environ 0,25 mm (i.e la taille du pixel). Donc les seuils de
perception et de séparation sont d'un pixel. Les recherches entreprises dans le cadre du
projet GiMoDig (GiMoDig, 04), proposent l'utilisation de tailles minimales suivantes pour
des terminaux mobiles :
-
8 x 4 pixels pour les objets surfaciques,
10 x 1 pixels pour les objets linéaires,
-
3 x 3 pixels pour les objets ponctuels.
14
Lorsque la taille d'un objet est plus petite que le seuil de perception, on est obligé de le
rendre visible sur la carte. Des amplifications sont donc nécessaires. Par exemple, la
majorité des routes et des bâtiments sont dilatés à partir d'une échelle de 1 : 25 000. Les
conflits d'espace qui proviennent de la dilatation et du déplacement sont résolus en
appliquant des opérateurs de généralisation qui seront détaillés dans la section suivante.
2.4 Génération des cartes sur le Web dans un contexte mobile
2.4.1 Contraintes de génération de carte pour des terminaux mobiles
Plusieurs contraintes techniques influencent la génération de cartes sur le web pour des
terminaux mobiles. On distingue deux grandes familles de contraintes liées aux différents
contextes de l'environnement mobile (Nivala et al, 03):
2.4.1.1 Contraintes liées au système : ces contraintes
sont liées aux caractéristiques
techniques des technologies sans fil, on peut les résumer comme suit :
La taille de l'écran : Les tailles d'écrans des micro-ordinateurs varient entre 14 et 21 pouces,
entre 12 et 15 pouces pour les ordinateurs portables et se situe entre 4.5 et 9 pouces pour les
écrans des assistants personnels (PDAs).
La résolution de l'écran : bien que la résolution des écrans des micro-ordinateurs s'améliore
de plus en plus, et qu'une résolution de 1024 par 768 pixels soit couramment utilisée, les
écrans des PDAs (assistants personnels) offrent généralement une résolution qui ne dépasse
pas 320 par 240 pixels.
Le nombre de couleurs : Les assistants personnels actuels ont des profondeurs qui peuvent
aller jusqu'au 16 bits, mais plusieurs PDAs et téléphones cellulaires sont encore
monochromes.
La bande passante pour le transfert des données : Actuellement, les taux de transfert varient
entre 20 kbps et 2 Mbps pour les technologies sans fil, ce qui reste insuffisant pour transmettre
des données géographiques à partir du serveur au client mobile.
15
La capacité de calcul du terminal de l'utilisateur : Un terminal mobile possède généralement
des caractéristiques techniques très limitées (vitesse d'horloge, espace de stockage, etc.). À cet
effet, la génération cartographique pour un contexte mobile doit s'accommoder de ces
limitations.
Un problème supplémentaire pour la génération cartographique pour des terminaux mobiles
vient du fait que ces contraintes sont incontrôlables par le système de génération de cartes.
2.4.1.2 Limitations liées au contexte utilisateur : l'utilisateur perçoit en temps réel les
objets géographiques, et il est distrait par son environnement. De plus, le contexte mobile
(mobilité de l'utilisateur, localisation, condition d'utilisation, temps, activité, etc.) nécessite
une attention particulière quant à l'adaptation et la personnalisation de la carte. Ainsi, il est
presque impossible de prévoir les types d'utilisateurs de la carte relativement à leur niveau
d'expertise, connaissance en cartographie, etc.
La gestion et la visualisation des données géographiques dans un environnement mobile
doivent s'adapter davantage à ces différentes contraintes dans le but d'offrir un service
cartographique de qualité aux différents utilisateurs nomades.
2.4.2 Gestion de données
L'accès aux données géographiques par Internet se généralise avec le développement des
moyens de communication. Les données fournies ont atteint des niveaux de détail de plus en
plus importants (Bertolotto et al 01). Leur communication via des connexions à faible bande
passante engendre par conséquent des coûts de plus en plus exorbitants relatifs au volume de
données transférées.
Pour générer des données géographiques sur le web pour des terminaux mobiles, deux types
de solutions sont envisageables (Cecconi et al 02) :
Une approche basée sur la généralisation à la volée : les données géographiques sont
généralisées à la volée à partir d'une source de données plus détaillée et transférées au client
mobile.
16
Une approche basée sur la représentation multiple: les données à différentes échelles sont
stockées sur le serveur dans une base de données multi-échelle, multi-représentation ou multirésolution (Follin, 04).
2.4.2.1 Généralisation à la volée
La carte est une abstraction du monde réel. Lorsque l'échelle de la carte diminue, son degré
d'abstraction augmente. Les mécanismes qui permettent d'augmenter le degré de
simplification et de compression des données géographiques sont les processus de
généralisation cartographique (Follin, 04).
La généralisation cartographique est Y« action de simplifier les éléments cartographiques et
leur représentation, en fonction d'un besoin particulier et selon des règles précises. La
généralisation cartographique fait appel à la simplification des formes, à la modification de
la position des entités spatiales, et à la suppression ou au regroupement d'entités spatiales.
Elle est utilisée notamment pour le passage à une échelle cartographique inférieure. » (OLF,
99).
La généralisation de données cartographiques est un processus très complexe du fait qu'il
dépend beaucoup de la nature du produit cartographique à produire. Ainsi, il est difficile de
parler d'un processus de généralisation standard puisqu'il diffère selon le produit final visé
(Han-Sze-Chuen, 02). De plus la génération de la carte finale dans un processus de
généralisation cartographique doit tenir compte du cadre d'utilisation de la carte, la
symbologie et les différentes sources d'informations qui seront utilisées.
Weibel et Dutton (Weibel & Dutton, 99), définissent la généralisation : « En cartographie
conventionnelle, la généralisation cartographique consiste à réduire la complexité d'une
carte dans un processus de réduction d'échelle, en mettant l'emphase sur l'essentiel tout en
supprimant ce qui est inutile, en maintenant les relations logiques et sans ambiguïtés entre
les objets de la carte, et en préservant une qualité esthétique. ».
Notons que la généralisation d'une carte offre en résultat une carte plus lisible par rapport à
celle générée dans un simple zoom arrière, car elle ne se limite
pas seulement à
sélectionner les objets géographiques qui vont faire partie de la carte, mais elle les rend
17
compréhensibles par le futur utilisateur en y appliquant certains traitements. Ces traitements
résultent de l'application des opérateurs de généralisation cartographique.
Opérateurs de généralisation cartographique
Un opérateur de généralisation transforme un objet géographique en un autre objet généralisé.
Ce dernier doit satisfaire les contraintes imposées par l'échelle de la carte, par l'espace de
représentation disponible, ou par sa lisibilité. Nous relevons dans la littérature plusieurs
classifications des opérateurs de généralisation. Nous présentons à titre d'exemple la
classification suivante (ESRI, 96) :
Elimination
Éliminer des objets géographiques qui sont de petites tailles ou qui sont non significatifs pour la
thématique de la carte. Par exemple (figure 4-a), éliminer les petites îles, les routes courtes, etc.
Simplification
Éliminer des détails non nécessaires sans distorsion de la forme essentielle de l'objet. Par exemple
éliminer les courbures ou les fluctuations d'une ligne (figure 4-b).
Agrégation
Combiner des objets proches ou adjacents dans un nouvel objet. Par exemple combiner plusieurs
petits lacs proches en un seul lac (figure 4-c).
Réduction de dimension
Réduire les dimensions d'un objet géographique (figure 4-d).
Typification
Réduire la densité des objets et le niveau de détail tout en conservant le patron de leur distribution
représentative et l'impression visuelle du groupe d'objets originaux (figure 4-e).
Exagération
Augmenter l'extension spatiale de la représentation d'un objet dans le but de mettre l'accent sur
son importance et d'améliorer sa lisibilité (figure 4-f).
18
Classification et symbolisation
Grouper des objets qui partagent des attributs géographiques similaires dans un nouvel objet de
niveau d'abstraction plus élevé et le représenter avec un nouveau symbole (figure 4-g).
Résolution de conflit (Déplacement)
Détecter les conflits entre les objets et faire les déplacements nécessaires pour les résoudre afin de
respecter la limite de séparation et les spécifications cartographiques qui peuvent exister (figure 4h).
Raffinement
Modifier et ajuster la géométrie ou l'apparence d'un objet afin d'améliorer son aspect esthétique
(visuel) et d'assurer sa compatibilité avec la réalité (figure 4-i). Par exemple, faire le lissage d'une
ligne, changer l'orientation de certaines limites d'un symbole, etc.
19
(a) Élimination
(b) Simplification
(c) Agrégation
(d) Réduction de dimension
fe
(e) Typification
(f) Exagération
• • •• •
•• •
•
•
: > II
•
•
• •
m
•
•
(g) Classification et symbolisation
1
G2
S.
\/
(h) Déplacement
Jet
I»
BÎV—i+^j
(i) Raffinement
Figure 4 : Opérateurs de généralisation ESRI
• • ••
20
Généralisation cartographique à la volée
La généralisation cartographique à la volée consiste à créer un produit cartographique en
temps réel et en fonction des préférences de l'utilisateur, approprié à son échelle et à son but,
et effectué à partir d'une base de données à plus grande échelle (Weibel et al, 02).
La généralisation de données à la volée doit être effectuée automatiquement et le temps de
traitement doit être réduit au maximum. Les relations spatiales qui existent entre les objets
doivent rester les mêmes (du moins similaires) avant et après la généralisation (Follin, 04). Le
processus de généralisation doit être aussi efficace afin de répondre aux exigences des
applications interactives via Internet (Zhou et al, 04). Les cartes générées dans le cadre d'une
généralisation à la volée doivent satisfaire les préférences de l'utilisateur ainsi que les
spécifications techniques du terminal de l'utilisateur.
Les travaux réalisés dans le cadre de projet GiMoDig (GiMoDig, 04), se sont intéressés a
l'aspect cartographique de la généralisation à la volée. Ils visent à utiliser un tel processus pour
la visualisation des données géographiques dans un contexte web sur une variété de
périphériques mobiles. Les cartes générées dans le cadre du projet GiMoDig sont destinées aux
utilisateurs mobiles, la généralisation est réalisée à la volée, et il est presque impossible de
vérifier la consistance des données résultant de la généralisation.
Les différentes approches de généralisation à la volée peuvent être distinguées selon qu'elles
sont combinées avec une base de données multi-résolution ou pas. Les approches de
généralisation à la volée combinées à une base de données multi-résolution sont destinées à
couvrir une plus grande gamme d'échelles que celles qui ne sont pas combinées à une base de
données multi-résolution (Lehto, 01).
Malgré les recherches entreprises dans le but d'automatiser le processus de généralisation
cartographique, il n'existe pas de solutions complètes et le processus nécessite encore
l'intervention des cartographes pour corriger certains résultats générés. La généralisation est
largement utilisée dans un contexte de production de données géographiques à partir de
données à une plus grande échelle. Par contre, si on a besoin de produire des cartes à la volée,
le facteur temps de réponse devient très important et la généralisation s'avère trop lente du
moment que les traitements effectués lors de la généralisation engendrent des temps de
réponse élevés. En effet, dans le but de minimiser le temps associé à la généralisation à la
21
volée de données, il faut que les algorithmes utilisés dans ce processus puissent être appliqués
sur des intervalles d'échelles relativement réduits (ce qui diminue la complexité en calcul des
algorithmes de généralisation).
Pour la génération de cartes sur le web pour des terminaux mobiles, le processus de
généralisation doit s'accommoder des contraintes liées à l'environnement mobile (mobilité de
l'utilisateur, propriétés d'affichage, bande passante etc.). De plus, il faut qu'il soit efficace
lorsque plusieurs clients nomades accèdent au serveur.
Une solution alternative qui a été étudiée par les chercheurs impliqués dans le domaine est
l'approche basée sur la représentation multiple.
2.4.2.2 Représentation multiple
Dans une approche représentation multiple, les données à différentes résolutions sont précalculées pour différentes échelles prédéfinies et stockées sur le serveur dans une base de
données multi-échelle, multi-représentation ou multi-résolution (Devogele, 97).
La représentation multiple est la coexistence, dans une même base de données à référence
spatiale ou dans un fichier de carte numérique, de plusieurs représentations cartographiques
(géométrie et sémiologie graphique) d'un même phénomène pour des fins d'utilisation
différentes à la même échelle ou à des échelles différentes (Martel, 99).
De son coté, Martel (Martel, 99) a identifié trois grandes catégories de multiplicité :
multiplicité géométrique, multiplicité graphique, multiplicité sémantique (figure 5).
Lorsqu'un même objet géographique possède plusieurs géométries, on parle de multiplicité
géométrique. Nous pouvons avoir une multiplicité géométrique multiéchelle ou une
multiplicité géométrique uniéchelle. La multiplicité géométrique multiéchelle se présente dans
le cas où un même objet géographique possède des géométries différentes à des échelles
différentes. Dans le cas où un même objet géographique possède plusieurs géométries
différentes, pour une même échelle, on parle de multiplicité géométrique uniéchelle.
La multiplicité graphique s'observe lorsque plusieurs symbologies peuvent représenter un
même objet géographique. Ce sont alors les variables visuelles qui changent d'une
représentation à l'autre : forme, dimension, orientation et couleur. Nous pouvons avoir une
multiplicité graphique multiéchelle du moment que certains symboles sont plus détaillés (plus
22
faciles à visualiser à grande échelle) alors que d'autres sont plus simples (plus faciles à
visualiser à petite échelle).
Uniéchelle
Multiéchelle
Multiplicité
Géométrique
4*
Vue A
.
La
Vue B
Vue C
Vue D
i
Multiplicité
graphique
Vue A
f.
VueU
VueV
E
VueB
VueU
VueW
£
VueV
Figure 5 : Multiplicité géométrique et graphique (tiré de Martel, 99)
On parle de
multiplicité sémantique, lorsqu'un même élément géométrique représente
plusieurs objets géographiques (Martel, 99). Comme dans le cas par exemple où un seul
bâtiment, réunit plusieurs services : restaurant, hôtel, café. Ainsi, différentes ontologies
peuvent être utilisées pour l'enregistrement des sémantiques attachées à un objet géographique
en fonction du contexte d'utilisation des données (figure 6).
23
Contexte d'utilisation
Application touristique
Application d'impôt
n>
a
Niveau
Niveau
I
i
Bâtiment
/*
B
tt
a
\
(
Niveau
/ ' Niveau
Bâtiment privé
/ ^
Accommodation
^ \ f
Transport
j
Niveau
Château Frontenac
Figure 6 ; Multiplicité sémantique (tiré de Cosma, 04)
Les approches basées sur les représentations multiples présentent plusieurs désavantages
relatifs à la gestion de la représentation multiple des objets géographiques : le stockage, la
duplication des opérations de mise à jour
des différentes représentations des objets
géographiques et le nombre limité de niveaux de détail.
Le tableau 1 résume les avantages et inconvénients des deux approches : généralisation à la
volée et représentation multiple (le + indique les avantages et le - les inconvénients).
Généralisation à
Accès aux
données
données
cartes
+
-
-
+
-
-
+
+
-
+
la volée
Qualité des flexibilité
Ressources de
Volume de
calcul
Représentation
multiple
Tableau 1 : Avantages et inconvénients de la généralisation à la volée et représentation multiple.
(Tiré de Follin, 04).
24
Dans une approche de généralisation à la volée, les cartes générées sont plus flexibles du
moment que les niveaux de détail ne sont pas prédéfinis. Par contre, cette approche demande
plus de ressources de calcul du coté serveur.
La représentation multiple fournit des cartes de meilleure qualité et nécessite moins de
ressources de calcul. Ainsi que l'accès aux données est plus rapide que dans une approche de
généralisation à la volée. Par contre, cette approche nécessite le stockage d'un grand volume
de données sur le serveur, ce qui soulève le problème des mises à jour des données.
Dans le but de tirer profit des avantages des deux approches précédentes, tout en palliant à
leurs inconvénients, de nouvelles recherches proposent leur combinaison. Des approches
permettant la génération cartographique à la volée sur le web et combinant la généralisation à
la volée et la représentation multiple sont proposées dans le cadre du projet GiMoDig
(GiMoDig, 04), par Cecconi (Cecconi et al, 02) et par (Gbei et al., 04). Dans l'approche
proposée par (Cecconi et al, 02), les classes d'objets sont sélectionnées à partir du niveau de
détail le plus approprié à l'échelle de la carte puis raffinées par des opérations de
généralisation à la volée. L'approche proposée par (Gbei et al. 04), vise à offrir un service
cartographique de qualité sur le web, en combinant la représentation multiple et la
généralisation à la volée à base de système multiagent.
Dans un contexte de génération cartographique en temps réel pour des terminaux mobiles les
deux concepts de généralisation en temps réel et représentation multiple doivent être associés à
une solution permettant de transférer progressivement les données générées par le serveur au
client mobile. Cette solution est appropriée à la faiblesse de la bande passante dans un contexte
mobile.
25
2.4.3 Transmission progressive de données
La transmission progressive est une solution pour transférer des données multi-résolution via
des liens de communication de bande passante réduite (Buttenfield, 99): La plupart des travaux
réalisés dans le domaine se sont inspirés des recherches entreprises dans la transmission de
données raster (avec les formats GIF et JPEG) ou la transmission de données vectorielles sous
la forme de maillages triangulaires dans le domaine de l'infographie (Follin, 04). La
transmission progressive avec des données raster, consiste à afficher initialement une image
avec une résolution minimale, puis avec de plus en plus de clarté, jusqu'à atteindre la
résolution normale.
Dans le domaine de la génération cartographique à la volée, la transmission progressive de
données a été abordée beaucoup plus avec des données raster qu'avec des données vectorielles
pour la simple raison que la plupart des cartes sur Internet ont été générées dans un format
raster (i.e : les navigateurs supportent beaucoup plus les formats raster que vectoriels).
La solution proposée dans (Bertolotto et Egenhofer, 01) est basée sur une structuration de
données vectorielles multi-résolution dans le but de les transmettre progressivement au client.
Le modèle de données utilisé a une structure arborescente dont la racine est la carte de niveau
de détail le plus bas. Une relation père fils correspond à un affinement et la relation fils-père à
une généralisation.
Le modèle proposé par (Bertolotto et Egenhofer, 01) consiste à (i) pré calculer et structurer
une séquence de représentations à différents niveaux de détails et à les stocker sur le serveur;
(ii) transmettre progressivement ces différents niveaux de détail (incréments) au client et (iii)
intégrer les incréments dans l'ensemble de données déjà reçu. Dans la première étape, chaque
entité géométrique est subdivisée en utilisant l'algorithme de Douglas-Peucker (Douglas D. et
Peucker, 73), puis stockée dans un arbre. La deuxième étape consiste à envoyer les données au
client par ordre croissant de niveaux de détail, le client peut arrêter le téléchargement s'il est
satisfait du niveau de détail atteint.
26
Niveau
a
t
!
•
Bâtiment nouvellement introduit (incréments ou modifié
Q Bâtiment du mwsau i + t réutilisé au n'weau i
iP* Route nouvellement introduit© (incrément) ou modifiée
* * Route du n wea u i + i réut ill sée au niveau i
Figure 7 : Réutilisation d'objets entre deux niveaux de détail ( Bertolotto et Egenhofer, 01)
La figure 7 montre la réutilisation d'objets entre deux niveaux différents de détail, ces objets
sont stockés dans les niveaux de détail les moins détaillés afin d'en optimiser le transfert.
Dans (Buttenfield, 02), Buttenfield propose une approche de transmission des données en
préservant leurs relations topologiques. Les objets vectoriels sont partitionnés dans des paquets
lors de la phase de prétraitement, en utilisant une décomposition hiérarchique basée sur
l'algorithme de simplification de Douglas-Peucker (Douglas D. et Peucker, 73). Chaque
paquet contient une représentation d'un objet vectoriel à un niveau intermédiaire de détail. Les
entités présentes dans les différents niveaux de détail ne sont stockées qu'une seule fois (dans
le niveau le plus grossier) et seules les entités nouvellement introduites sont enregistrés pour
les niveaux suivants. Du point de vue du transfert, l'utilisateur reçoit d'abord les données les
moins détaillées. Puis des données de plus en plus fines lui sont envoyées jusqu'à ce qu'il
décide d'arrêter leur transfert.
Dans (Brenner et Sester, 03), Brener et Sester présentent une approche de généralisation
continue, celle-ci est basée sur la transmission incrémentale d'opérateurs et elle vise à éviter
les « effets de saut » (« popping effects ») lors d'un zoom continu entre deux niveaux de détail.
Dans la phase de prétraitement, une séquence de représentations à différents niveaux de détail
est pré-générée sur le serveur : chaque objet géographique est représenté par la plus simple
géométrie et un ensemble d'opérateurs permettant de générer sa représentation la plus
détaillée. La chaîne inverse permet d'obtenir une représentation plus détaillée d'un objet
cartographique à partir de sa représentation la moins détaillée. Elle permet aussi la
27
transmission progressive de données à travers des liens de communication lents, en transférant
d'abord les données moins détaillées suivies par une séquence d'opérations inverses de
généralisation.
Dans (Thiemann et Sester, 04): Thiemann et Sester proposent également, une approche de
transmission progressive d'objets 3D (objets de type bâtiments) visant à éviter les « effets de
saut » lors de l'affichage de ces objets 3D. L'approche proposée se décompose en trois étapes :
(i) segmentation des bâtiments, (ii) analyse et généralisation des différents éléments obtenus,
(iii) génération et stockage des résultats dans une structure multi-échelle.
Toutes les approches de transmission progressive proposées visent à produire une service
cartographique adapté aux préférences des utilisateurs, et permettant au client de contrôler
raffinement de niveau du détail (transfert de niveaux de détail intermédiaires). Elles visent
aussi la diminution de la quantité de données à transmettre au client.
La génération de service cartographique sur le web pour des terminaux mobiles nécessite
l'adoption de solutions aussi bien du point de vue de la gestion de données géographiques que
de celui de leur visualisation comme nous le voyons dans la section suivante.
2.4.4 Visualisation de données
La visualisation de données géographiques (ou géovisualisation) fait appel à plusieurs
techniques de visualisation d'informations, de cartographie, analyse de données, traitements
d'images et systèmes d'informations géographiques. Elle permet l'analyse, la synthèse et
l'exploration visuelle de données spatiales (MacEarchen, 01).
Une carte est un moyen puissant de communication visuelle d'informations. Dans le but de la
rendre de plus en plus facile à comprendre, il faut tenir compte de plusieurs variables durant la
génération d'une carte (la taille, la couleur, la densité, la structure, la direction et la position)
(Bertin, 67). La visualisation de cartes sur un terminal mobile doit aussi s'accommoder aux
contraintes liées à l'environnement mobile et en particulier aux caractéristiques d'écran du
terminal mobile : la taille, la résolution, le nombre de couleurs et le seuil de visibilité.
Les différents produits commerciaux qui se partagent le marché de visualisation des données
géographiques sur des terminaux mobiles peuvent être classés en trois grandes familles
(Reichenbacher, 03) :
28
Systèmes de navigation routière : les premiers systèmes de navigation étaient destinés aux
voitures de luxe. Actuellement presque toutes les voitures de classe moyenne en sont
équipées. Ces systèmes génèrent des cartes simplifiées et destinées principalement à la
navigation routière. La figure 8-a présente un exemple de carte de navigation routière
fournie par TomTom Navigator4.
Services géolocalisés (Location Based Services) : ces services sont généralement fournis
par les compagnies de télécommunication. Ils offrent plusieurs types de cartes (cartes de
villes, cartes routières, etc.). L'exemple de la figure 8-b présente une carte pour PDA
fournie par la compagnie de télécommunication O25.
Guide de cartes urbaines (City map guide) : ces guides cartographiques permettent la
visualisation d'une carte d'une ville, avec des points d'intérêt (POIs) de l'utilisateur. Un
exemple d'un tel service : Falk City Guide6 qui permet la visualisation d'une carte d'une
ville en fonction de la position GPS de l'utilisateur (Figure 8-c).
(a)
(b)
(c)
Figure 8 : a) Exemple de système de navigation, (b) LBS et (c) Guides de cartes urbaines
Tom Tom navigator : www.tomtom.com
5
O2: www.o2-online.de
6
Falk City Guide : www.Falk.de
II y a trois approches pour la visualisation de données géographiques dans une fenêtre
restreinte d'un terminal mobile (Harrie et al, 02):
la première approche (figure 9) consiste à afficher les entités cartographiques à
différents LoD dans la totalité de l'espace d'affichage et de manière adaptée à l'échelle
de visualisation. L'utilisateur peut naviguer entre une carte à petite échelle et une autre
à grande échelle.
Figure 9 : Affichage adapté des données à différents LoDs (tiré de Follin, 04)
la deuxième solution (figure 10) permet d'afficher la carte à grande échelle dans la
fenêtre principale et la carte à petite échelle dans une petite fenêtre appelé « key-map ».
Figure 10 : Affichage de cartes à grande et à petite échelle (tiré de Follin, 04)
Dans la troisième approche (figure 11), les données géographiques à différentes
échelles sont présentées dans la même carte appelée carte à échelle variable. Dans cette
carte les données autour de la position de l'utilisateur sont représentées à grande
échelle, et plus loin, elles sont représentées à petite échelle.
30
Figure 11 : Affichage de carte à échelle variable (tiré de Harrie et al, 02)
Barkowsky (Barkowsky et al. 00) et Avelar (Avelar, 02) et Casakin (Casakin et al. 00),
présentent des approches basées sur les cartes schématiques (schematic map). Ces cartes
schématiques (figure 12) sont généralement obtenues par relaxation des contraintes
spatiales ce qui veut dire qu'elles déforment intentionnellement l'information spatiale dans
le but d'en faciliter la compréhension (exemple les cartes de réseau de transport publique).
•
i
Figure 12 : Carte schématique (tiré de Avelar, 02)
L'approche d'affichage adapté des données à différents LoDs présente l'avantage de
visualisation des cartes à grandes et petites échelles dans leur intégralité, mais ne permet
pas une vision simultané ce qui rend l'identification des objets communs très difficile. Par
contre l'approche d'affichage simultanée de cartes à grandes et à petites échelles permet
une vision simultanée des cartes, mais il est toujours difficile d'identifier les objets
31
communs aux deux cartes. L'approche de visualisation à échelle variable, permet
l'intégration des données à grande et petite échelle dans la même carte, mais elle engendre
un problème d'encombrement spatial surtout dans la zone qui sépare les deux cartes
(coupure entre les représentations des objets dans les deux cartes) ce qui augmente sa
complexité de calcul.
L'approche basée sur les cartes schématiques présente l'avantage d'être très efficace pour
la visualisation des cartes qui sont orientées davantage vers des buts d'usage fixés à
l'avance (carte de transport public), mais au détriment de la déformation des informations
spatiales.
2.5 Conclusion
Dans ce chapitre, nous avons présenté une revue des concepts et technologies qui forment le
fondement théorique de notre recherche. Dans la première section nous avons présenté les
différentes technologies mobiles : les concepts de carte, d'échelle et de résolution ont été
présentés dans la deuxième section. Dans la troisième section de ce chapitre nous avons
présenté les solutions actuellement proposées pour la gestion et la visualisation de données
géographiques dans un contexte mobile.
Notons par ailleurs, la génération cartographique pour des terminaux mobiles est un domaine
en plein essor, et il reste beaucoup de travail à faire pour générer des services cartographiques
qui s'adaptent aux contraintes du contexte mobile et aux préférences de l'utilisateur.
32
Chapitre III
Solution proposée
33
Chapitre 3: Solution proposée
3.1 Introduction
Le chapitre précédent nous a permis de présenter les concepts les plus importants sur lesquels
notre recherche se base. Dans le présent chapitre, nous présentons l'approche adoptée pour la
génération à la volée des cartes pour des terminaux mobiles. Dans ce chapitre nous faisons une
brève description de la nouvelle architecture du système SIGERT et nous présentons les
avantages d'utilisation du standard SVG pour la gestion et la visualisation des données
cartographiques dans un contexte mobile. Finalement, l'approche appelée « génération et
transmission progressive des cartes par couches d'intérêt » est présentée en détail.
3.2 Architecture et fonctionnement du système SIGERT
Le système SIGERT a été conçu dans le but d'offrir des services cartographiques sur le
Web, pour des terminaux fixes et mobiles. Sa version initiale se base sur une approche qui
combine la généralisation automatique et la représentation multiple pour la génération
automatique des cartes pour des terminaux de type desktop (Cosma, 04). Par ailleurs, Dans
un contexte de génération cartographique à la volée pour des terminaux mobiles, les deux
concepts de généralisation en temps réel et représentation multiple doivent être associés à une
solution qui permet de diminuer la quantité de données à transmettre au client nomade et
d'adapter le contenu de la carte en fonction des caractéristiques d'affichage des terminaux
mobiles.
Dans le but d'étendre SIGERT pour qu'il supporte un service cartographique pour des
terminaux mobiles de type PDA, nous proposons une approche de génération et transmission
progressive des cartes par couches d'intérêt pour des terminaux mobiles. Cette approche
combine la généralisation cartographique et la représentation multiple afin de tirer profit de
leurs avantages en palliant à leurs inconvénients (voir section 2-4-2-2).
Elle vise aussi la réduction de taille de la carte finale à transmettre au client mobile, et
l'adaptation de son contenu en fonction des préférences des utilisateurs et des contraintes
liées au contexte mobile.
34
Comme la plupart des systèmes d'information distribuée, la nouvelle version du système
SIGERT, adopte une architecture client-serveur. Cette architecture (figure
13) est
composée :
•
du coté client qui fournit des interfaces adaptées aux différents types de terminaux
(desktop, PDA, Smart phone, etc.). Ces interfaces
permettent à une application
client quelconque de se connecter au système SIGERT et d'obtenir certains des
services disponibles;
Web SIGERT
Système multiagent
Desktop
S
ne PDA
Application client
ASIVIITMI,
rinv/SVG Basic
Module de
traitement
Module de
contrôle
et adaptation
r
Informations
utilisateurs
Données spatiales
Tonnât GML(base
de données cXist )
prétraitement
ï
Données
spatiales
Figure 13 : Architecture générale du système SIGERT
du coté serveur qui est composé d'une base de données géographiques contenant les
différentes représentations des objets spatiaux. Il contient aussi une base de données
utilisateurs permettant l'authentification des clients et le stockage des profils des
utilisateurs, pour la personnalisation de la carte en fonction des propriétés d'affichage
du terminal de l'utilisateur. Le serveur contient aussi le système multiagent,
responsable de la production de la carte demandée et l'adaptation de son contenu en
fonction des préférences des utilisateurs et des propriétés d'affichage du terminal
utilisé (voir section 3-3).
35
Avant d'accéder au service cartographique, l'utilisateur (desktop ou mobile) doit s'authentifier
auprès du système SIGERT. Par après, il
sélectionne la région d'intérêt sur une carte
d'orientation affichée sur son terminal. En utilisant l'interface client SIGERT, l'utilisateur peut
spécifier les objets recherchés (bâtiments, hôtels, restaurants, etc.). Quand le serveur SIGERT
reçoit la requête utilisateur, le système multiagent (module de contrôle et adaptation) l'analyse
et demande à la base de données géographiques toutes les informations concernant la région
spécifiée. Il demande également à la base de données utilisateurs les informations concernant
l'utilisateur (préférences, caractéristiques d'affichage, etc.). Ensuite, le système multiagent
stocke ces données dans un fichier GML (Geography Markup Language) et les traite afin de
générer une carte qui correspond aux besoins et au profil de l'utilisateur. Durant le traitement,
le système multiagent (module de traitement) a besoin d'améliorer la lisibilité des objets, il est
appelé aussi à résoudre les conflits spatiaux qui résultent du chevauchement de ces objets. A
la fin du traitement, il adapte le contenu de la carte en fonction des caractéristiques d'affichage
du terminal de l'utilisateur et la transmet progressivement au client.
Pour offrir un service cartographique dans un contexte mobile nous avons opté pour une
approche de génération et transmission progressive des cartes par couches d'intérêt comme
nous le voyons dans la section suivante.
3.3 Génération et transmission progressive des cartes par couches
d'intérêt
La plupart des approches utilisées actuellement pour la génération des cartes sur le Web et
dans un contexte mobile, consistent à extraire et à afficher des données spatiales précalculées
dans des bases de données géographiques. Généralement, ces approches génèrent des cartes
en mettant l'accent sur le réseau routier et la localisation de l'utilisateur (figure 14a). Ainsi, le
contenu de ces cartes ne permet pas de donner suffisamment d'information aux utilisateurs
quand ces derniers cherchent un emplacement spécifique dans la zone d'intérêt. D'un autre
côté, la majorité des cartes générées contiennent plus de détails que celui recherché par
l'utilisateur (figure 14b). Ce type de cartes pénalise les utilisateurs qui doivent attendre la
génération et le transfert d'un volume important de données qui n'est pas nécessairement utile.
Considérant, les limitations de ces approches, nous constatons la nécessité d'une approche qui
36
génère des cartes qui contiennent les informations demandées par l'utilisateur et qui s'adaptent
aux contraintes du contexte mobile (taux réduit de transfert de données, délai de génération de
la carte, etc.).
Les différentes approches de transmission progressive des cartes utilisées dans les services
cartographiques sur le web pour des terminaux fixes et mobiles, visent à diminuer le temps
associé au transfert des données entre le serveur et le client. Cependant l'utilisateur est
toujours obligé d'attendre jusqu'à la fin du téléchargement de la totalité de la carte.
Figure 14: (a) Carte basée sur le réseau routier et (b) Carte avec plus de détail (source :
YahooMaps)
Dans le cadre du projet SIGERT, nous avons opté pour une apprcohe de génération et
transmission progressive de données en fonction de leur importance pour l'utilisateur. Nous
proposons de catégoriser les objets spatiaux en plusieurs niveaux d'importance. Une fois les
objets spatiaux associés à un niveau d'importance donné générés, ils peuvent être transférés à
l'utilisateur. Notre approche permet de résoudre les problèmes relatifs aux taux de transfert et
au délai de transmission de données dans un contexte mobile. Elle permet aussi de réduire le
temps d'attente de l'utilisateur et d'améliorer la personnalisation de la carte. En effet,
l'utilisateur peut arrêter le transfert de données sans avoir besoin d'attendre la fin du
téléchargement de toutes les données, aussitôt qu'il obtient l'information demandée à partir
des données déjà transférées. L'approche proposée est appelée génération et transmission
progressive de cartes par couches d'intérêt (figure 15). Une couche d'intérêt regroupe un
ensemble d'objets d'une même importance pour l'utilisateur. Ces objets peuvent appartenir
aux différentes classes d'objets (routes, bâtiments, rivières, etc.).
37
Dans le but de catégoriser les données en couches d'intérêt, il faut identifier l'importance de
l'objet pour l'utilisateur et déterminer le nombre de niveaux d'importance qui devrait être
utilisé pour classer les objets spatiaux. La catégorisation des objets géographiques nous permet
de définir différentes priorités (poids) que nous donnons aux objets en fonction de leur degré
d'importance pour l'utilisateur.
Cette catégorisation peut varier en fonction du but et du
contexte d'utilisation de la carte. Par exemple, dans un contexte touristique, le touriste peut
demander la localisation de quelques objets spécifiques (e.g cinéma, hôtel, musée, etc.). Il peut
aussi demander les places d'intérêt dans une ville et les directions pour les atteindre. Dans le
cadre du système SIGERT, nous proposons quatre catégories d'objets spatiaux : objets
explicitement demandés (OED), réseau routier (RR), objets repères (OR) et objets ordinaires
(OO) (Jabeur, 05). Dans cette catégorisation, les objets explicitement demandés représentent
l'objectif principal de la carte demandée par l'utilisateur, le réseau routier et les objets repères
sont utilisés par l'utilisateur pour la navigation
et la recherche du chemin et les objets
ordinaires sont des objets qui ne présentent pas un intérêt spécifique pour l'utilisateur.
Dans un autre contexte tel que le domaine militaire, en plus du réseau routier, du réseau
hydrographique, l'utilisateur pourrait avoir besoin d'une couche d'intérêt contenant les points
stratégiques (ponts, places, bâtiments,etc.) à protéger et d'une couche contenant les positions
de l'ennemi. Ces différentes couches peuvent être mises à jour en temps réel pour une bonne
planification d'interventions militaires.
Cl(2)
CI(3)
CI(4)
CI(i) : couche d'intérêt de priorité i
Données initiales
Figure 15: Génération et transmission progressive de cartes par couche d'intérêt
38
La mise en place d'une approche de génération et transmission progressive de cartes par
couches d'intérêt dans un contexte web pour des terminaux fixes et mobiles nécessite
l'adoption d'un modèle de données adéquat pour le stockage et l'accès aux données
géographiques.
3.3.1 Modèle de données à représentations multiples
Dans le but d'offrir un service cartographique sur le web pour des différents types de
terminaux (ordinateur personnel, PDA, téléphone cellulaire), le système SIGERT adopte un
modèle de données à représentations multiples (Cosma, 04).
Dans ce modèle de données (figure 16), chaque objet géographique possède trois catégories
de représentations : représentation géométrique, représentation graphique et représentation
sémantique. Chaque catégorie de représentation a plusieurs instances. Ainsi, nous pouvons
avoir une nouvelle représentation d'un objet géographique donné, en combinant des
instances des trois catégories de représentation. Le modèle de données proposé utilise le
standard GML7 (Geography Markup Language) pour stocker les différentes représentations
des objets spatiaux.
7
Geography Markup Language
39
i
Région
regionMember
y
s
RegionMember
GeoObjectMember
Geometry
«restriction»
9
PoIntGeometry
-scale ; int
-sem : int
0..*
LineGeometry
-xlink:href : string
-scale : Int
0..*
PolyGeometry
-scale : int
0..*
AbstractFeature
Figure 16 : Diagramme UML du modèle de données à représentations multiples
(tiré de Cosma, 04)
40
La figure 17 présente un fichier GML à représentations multiples respectant le modèle de
données présenté dans la figure 16.
- <regionMember esist:id»"2070" ::nilns-"">
- <G900bject>
<NearbyObjects>74 82 86</Nearbyûbjects>
<tile>AQAL</tile>
<tile>APAL</tile>
<AREA>411.246</AREA;.
<PERIMETER>90.318</PERIMETER>
<ID_GEMURE>79</ID_GEMURE>
<address>1140, rue Sa!nt-Jean</addres5>
- <geoObjed:Mernber>
Représentations multiples
.--?category level-"l">Batiment</category>
<category level="2">Restaurant</catagary>
....jxategory level-"3" narne="Cafe 'Casse-Crepe Breton"'>Cafe</ca
<78èïrrantiœ>.
</geoObjectMember>
C
__.*erSphîcs>
..••'*'
i"
\
<symbol sem="Cafe" xlink:href="Cafe.svg"/>
"''"••.
<symbol SBrn="Restaurant" xiink;href="Restaurant.svg"/> )
<symbol sem="Batiment" xlink:href="Batlment.svg"
<S,hi
• <geoObjectMember>_
V
_..--!l5ôîy6eometry optScale-"1000">
- <gml:polygonProp8rty>
- <gml:Polygon srsName»"">
- <gml:outerBoundaryl5>
- <gml;LinearRing>
<gml:coordinates>331383.0625,5186899.75 331386.96875,5186895.625 331387.9375,51B68_9 ;
331388.59375,5186893.25 331388.5625,5186892 331387.90625,5186890.875
-331368.5,5186877.375 331356.53125,5186890.625 3 3 1 3 5 5 . 1 5 6 2 5 , 5 1 8 6 8 a 2 . 1 M - " '
3313*6'6.?3yS,M8&90X3at37 i 4...625,5186893.75.3313.83 J 0fi25,Sl«eBg9^5</qml:coordinat8s>
Figure 17 : Exemple de fichier GML à représentation multiple
La génération cartographique dans un contexte web pour des terminaux mobiles ne se limite
pas à extraire les objets pertinents pour l'utilisateur et à les afficher sur le terminal du client,
mais il faut aussi qu'elle améliore la lisibilité de la carte en résolvant les conflits spatiaux
résultant du chevauchement de ces objets spatiaux.
3.3.2 Génération des cartes à la volée à base d'agents logiciels
La génération à la volée des cartes est une tâche extrêmement difficile qui doit surmonter
plusieurs types de contraintes : les contraintes techniques, les contraintes des données
spatiales, les contraintes utilisateurs et les contraintes de traitement spatial. Les contraintes
techniques concernent le temps de chargement et du taux de transfert de données et la taille de
l'écran dans un contexte mobile. Les contraintes des données spatiales
concernent la
modélisation, la disponibilité et l'extraction de données. Les contraintes utilisateurs sont liées
41
aux préférences de l'utilisateur et à sa culture. Par ailleurs, la génération des cartes à la volée
doit
surmonter les contraintes de traitement spatial qui sont liées à la généralisation
cartographique et à la résolution des conflits spatiaux qui sont causés par le chevauchement
des objets spatiaux et la taille réduite de l'écran de visualisation de la carte (Figure 18).
Figure 18 : Contraintes de conflits spatiaux (Jabeur, 05)
Plusieurs recherches ont utilisé les systèmes multiagents pour résoudre les conflits spatiaux
dans le cadre de la génération automatique des cartes. L'utilisation de tels systèmes possède
plusieurs avantages parmi les plus importants : (i) une solution acceptable peut être souvent
obtenue (Lamy et al. 99), (ii) La flexibilité d'une solution multiagent pour la résolution des
problèmes complexes (Jabeur et al, 03) et (iii) l'adaptation dynamique aux changements de
l'environnement permet de modéliser avec succès toute la scène d'ajout, de fusion, de
symbolisation et d'élimination d'objets spatiaux lors du processus de génération automatique
des cartes (Lamy et al 99).
Dans le projet SIGERT, nous utilisons un système multiagent pour la génération automatique
des cartes. Ce système résulte de l'affectation d'un agent à chaque objet géographique qui peut
potentiellement apparaître dans la carte. Chaque agent aura alors les caractéristiques de l'objet
auquel il est affecté et il en sera responsable. Du fait que les objets n'ont pas tous la même
importance pour l'utilisateur, les agents auront des priorités (poids) distincts en fonction des
objets dont ils sont responsables (Jabeur et al, 03). Les agents ayant des priorités élevées
(ex.un agent correspondant à l'objet théâtre explicitement demandé par l'utilisateur) doit
figurer sur la carte finale.
42
La structure du système multiagent est composée de deux modules de base : le module
contrôle et d'adaptation et le module de traitement spatial (figurel0-).
Le module de contrôle et adaptation est composé d'un agent coordonnateur dont le rôle est
d'extraire de la base de données, les données spatiales qui concernent la zone sélectionnée par
l'utilisateur. Les données sélectionnées sont stockées dans un fichier GML. À partir de ce
fichier / 'agent coordonnateur génère un ensemble de fichiers par catégorie (OED, RR, OR et
OO), et les transmet au module de traitement spatial. Une fois que le module de traitement a
envoyé les données finales concernant une couche d'intérêt au module de contrôle et
adaptation, ce dernier fait l'adaptation de ces données et les transmet au client. Cette
adaptation consiste à transformer les données au format GML en format SVG8 en utilisant une
transformation XSL9. Cette transformation XSL permet à l'agent coordinateur de générer des
fichiers SVG pour des terminaux de type desktop, SVG Basic pour des PDAs et SVG Tiny
pour des SmartPhones. De plus, dans la cas où la carte est générée pour un terminal mobile,
cette adaptation consiste à appliquer des traitements sur les données afin d'en diminuer la
taille et de les transmettre progressivement au client mobile.
Le module de traitement se compose de trois couches principales. La première couche est
appelée couche de fédération, elle est composée des agents-types. Chaque agent-type
correspond à une couche d'intérêt spécifique (OED, RR, OR et OO). Le rôle de l'agents-type
est d'extraire les données de chaque objet géographique (instance du type) et de créer un agent
instance qui sera affecté à cet objet.
La deuxième couche du module de traitement est appelée couche de traitement spatial, elle est
composée de tous les agents instances créés par les différents agents-types. Dans cette couche,
les agents instances interagissent dans le but de générer la carte demandée et adaptent son
contenu aux préférences de l'utilisateur et aux propriétés d'affichage du terminal. Durant ce
processus, les agents instances résolvent
maintiennent
les relations spatiales entre les objets, et préservent la lisibilité des objets
important pour l'utilisateur (Jabeur, 05).
8
9
les conflits spatiaux qui peuvent les opposer,
Scalable Vector Graphics
Extensible Stylesheet Language
43
Module de contrôle et adaptation
Couche coordination
Base de
données
spatiales
fichier GML i
.
Informations
utilisateur
I
Conclu
sp;
Figure 19 : Architecture multicouches du système multiagent (Jabeur, 05 )
La troisième couche du module de traitement est appelée couche de contrôle. Dans cette
couche des agents-conteneurs peuvent intervenir dans le cas d'un conflit majeur ne pouvant
pas être résolu par les agents instances. Un agent-conteneur est un agent qui contient
l'ensemble des objets qui seraient en agrégation à une échelle plus petite que l'échelle de la
carte de base (dont nous disposons) et l'échelle de la carte demandée par l'utilisateur.
Comme nous avons vu dans le deuxième chapitre, la génération cartographique pour des
terminaux mobiles, nécessite des solutions aussi bien pour la gestion que pour la visualisation
de données. Dans la section suivante, nous allons présenter, la solution adoptée dans le cadre
du projet SIGERT pour la visualisation des données cartographiques sur des terminaux
mobiles de type PDA.
44
3.3.3 Visualisation progressive de données par couches d'intérêt
De nos jours, la majorité des graphiques sont présentés sous format matricielles (PNG, GIF, ou
JPEG). Ces images en mode matriciel présentent les inconvénients suivants: (i) elles sont très
volumineuses, (ii) leur présentation est lente, (iii) elles perdent la lisibilité lorsque l'utilisateur
désire y faire un zoom, (iv) elles contiennent des informations qui sont souvent statiques.
Les mêmes formats sont utilisés pour l'affichage des cartes sur le Web, ce qui restreint les
possibilités d'interaction de l'utilisateur avec la carte et donne des cartes de faible résolution.
L'émergence du standard XML10 a amélioré la fonctionnalité du Web en fournissant une
identification plus flexible et plus adaptable de l'information. Lorsque nous envisageons la
visualisation de données spatiales dans un environnement Web, la nécessité d'un format
standard pour les graphiques vectoriels, se fait sentir. C'est là qu'intervient le SVG, qui est une
grammaire basée sur XML pour la description d'objets graphiques en deux dimensions. Le
SVG permet la gestion des objets graphiques de formes vectorielles (lignes, polygones, etc.),
les objets de type texte et les images raster. Il offre aussi la possibilité d'intégrer le graphisme
vectoriel aux sites Web aussi bien pour des terminaux fixes que mobiles.
Dans la spécification SVG 1.1, des profils SVG tels que SVG Mobile sont définis. Ce profil est
une forme de SVG adaptée à l'affichage de graphiques vectoriels sur petits terminaux. Pour
satisfaire la variété des terminaux mobiles (chaque terminal a des caractéristiques différentes ),
deux profils sont définis : le premier profil de bas niveau, SVG Tiny est défini pour les
terminaux très restreints (téléphones cellulaires), le deuxième profil, SVG Basic est destiné
aux terminaux mobiles des plus haut niveaux (PDA).
Le SVG présente plusieurs avantages pour la visualisation de graphiques vectoriels sur des
terminaux mobiles, dont les plus importants:
taille réduite des fichiers SVG,
il est basé sur le standard XML ce qui le rend intégrable dans les différentes
technologies web,
1
XML-eXtensible Markup Language, http://www.w3.org/TR/Rec-xml
45
-
le rendu du document SVG varie automatiquement selon le périphérique de sortie en
matière de résolution et de mise en page.
-
il permet de faire des animations à l'aide d'un langage de script (JavaScript,
-
EMAScript, etc.),
les graphiques restent lisibles même après un zoom,
-
une structure SVG est accessible et modifiable à travers le DOM ,
-
visualisation d'images présentant une bonne clarté et une résolution élevée à partir des
navigateurs Web.
Nous pouvons dire aussi que SVG est une nouvelle forme vectorielle d'Internet qui permet de
dépasser les problèmes rencontrés jusqu'ici (avec les formats raster), et il permet de générer
des cartes interactives, adaptables pour une variété de terminaux .
Les fichiers SVG sont visualisables sur les navigateurs Web pour des terminaux mobiles
auxquels on ajoute un plugiciel (plug-in) spécialisé, par exemple celui développé par la
compagnie Bitflashn. On peut aussi visualiser un fichier SVG sur un terminal mobile en
utilisant des viewers SVG tels que : Tinyline13 SVG, Pocket SVG14 , etc. La figure 20 présente
des cartes géographiques affichées sur des terminaux mobiles en utilisant ces différents
viewers SVG.
11
DOM : Document Object Model, Le DOM fournit une représentation en mémoire d'un document XML. Le
DOM permet de lire, de manipuler et de modifier un document XML par programme, Ce dernier régit la
représentation en mémoire commune et structurée des données XML, bien que les données XML véritables soient
stockées dans un fichier.
12
Bitflash: www.bitflash,corn
13
Tinyline: www.tinyline.com
14
Pocket SVG : http://www.pocketsvg.com/
46
Figure 20 : Cartes au format SVG Basic affichée sur PDA : (gauche) viewer Pocket SVG,
(droite) viewer Tinyline
Dans la section 2-4-4, nous avons présenté les différentes approches de visualisation de
données cartographiques sur des termianux mobiles. Après avoir vu les avantages et
inconvénients de ces approches (affichage adapté, affichage de cartes à grande et petite échelle
et affichage à échelle variable), notre choix s'est porté sur la première approche (affichage
adapté des données à différents LoDs) car :
elle semble la plus intéressante pour la visualisation de données cartographiques sur
des petits écrans de terminaux mobiles, du moment qu'elle permet la visualisation des
cartes à petites et grandes échelles dans leur totalité.
Elle semble la mieux adaptée à notre solution de gestion de données : la résolution du
conflit spatial et à la génération, la transmission et l'affichage des cartes par couche
d'intérêt.
En plus de la visualisation adaptée des données à différents LoDs, nous avons opté pour une
solution d'affichage progressive des différentes couches d'intérêt sur le terminal mobile. Cette
solution (Figure 21) consiste à afficher progressivement, les couches d'intérêt (RR, OED, OR,
OO) générées par le serveur en format SVG Tiny. Ces couches sont générées par le serveur
SIGERT par catégories et dans cet ordre : le réseau routier (RR), ensuite les objets
explicitement demandés (OED), puis les objets repère (OR), et enfin les objets ordinaires
(OO). Une fois que la couche (RR) est générée sur le serveur, elle est transmise au client
mobile. Après réception de la deuxième couche (OED), l'utilisateur peut l'insérer dans la
couche (RR), la même chose pour la couche (OR), et (OO). Cela veut dire que l'utilisateur
peut insérer la couche d'intérêt précédemment reçue dans la couche d'intérêt déjà affichée sur
son terminal.
47
Serveur
Terminal mobile
OED
OR
OO
KK
RR+OED
RR+OED+OR
RR+OED+ OR+OO
Transmission progressive des couches
d'intérêt
Visualisation progressive des couches
d'intérêt
CZL
Génération progressive des couches
d'intérêt
Figure 21 : Visualisation progressive des couches d'intérêt sur le terminal client
L'approche de visualisation progressive des différentes couches d'intérêt sur un terminal
mobile, présente plusieurs avantages, dont les plus importants:
-
elle permet de réduire le temps d'attente de l'utilisateur, relatif aux taux de transfert
très réduis des réseaux sans fil.
L'utilisateur peut aussi arrêter le transfert des différentes couches à n'importe quel
moment, aussitôt qu'il obtient l'information demandée à partir des couches déjà
transférées.
En cas de perte de données (dû à l'instabilité du réseau sans fil), l'utilisateur ne perd
pas la totalité des données demandées, et peut exploiter les données déjà transférées
sur son terminal,
-
La manipulation de plusieurs couches de petites taille est très intéressante dans un
contexte mobile, du moment que les terminaux mobiles possèdent des capacités de
calcul et mémoire très limitées. De plus, la plupart des viewers SVG pour terminaux
mobiles, ont des difficultés à charger des cartes SVG de grande taille.
-
Cette approche permet aussi d'augmenter la flexibilité de l'affichage en plus
d'accroître l'interactivité.
-
La visualisation progressive des différentes couches d'intérêt accélère le processus de
génération de carte, du moment qu'à chaque fois qu'une couche est générée par le
serveur, elle sera directement transmise au client mobile, et l'utilisateur peut la
visualiser,
48
Cette approche est d'une grande importance, dans un contexte de service géolocalisé
(LBS) : à chaque fois que l'utilisateur change de position, l'ancienne carte est mise à
jour au lieu de générer une nouvelle carte (i.e propagation des mises à jour à partir du
serveur en fonction de la position de l'utilisateur).
3.4 Conclusion
Le chapitre 3 de ce mémoire a eu comme point central la présentation de l'approche adoptée
dans le cadre du projet SIGERT pour la génération et la transmission progressive des cartes
par couches d'intérêt dans un contexte mobile. Dans la section 3-1 nous avons présenté la
nouvelle architecture du système SIGERT permettant
la génération des services
cartographiques pour des terminaux fixes et mobiles. Par la suite nous avons présenté en détail
une approche qui combine : l'utilisation d'une base de données à représentations multiples, la
généralisation cartographique à base du système multiagent et la transmission
visualisation progressive des données cartographiques.
et la
49
Chapitre IV
Le service SIGERT-Mobile
50
Chapitre 4 : Le service SIGERT-Mobile
4.1 Introduction
Le chapitre précédent nous a permis de présenter l'approche proposée pour la gestion et la
visualisation des données cartographiques dans un contexte mobile dans le cadre du Système
Intelligent de Gestion des Espaces Récréatifs et Touristiques (SIGERT). Dans le présent
chapitre, nous allons présenter essentiellement le développement d'un service de génération
cartographique sur le Web pour des terminaux mobiles de type PDA afin d'étendre le système
SIGERT pour qu'il supporte un service de génération cartographique dans un contexte
mobile. Dans ce chapitre nous présentons l'architecture du système SIGERT, ensuite nous
allons voir le développement et le fonctionnement du service SIGERT-Mobile ainsi que ces
fonctionnalités.
4.2 Présentation du système SIGERT
Le système SIGERT se veut un système de génération automatique des cartes dans un
environnement Web, pour des terminaux fixes et mobiles. Nous avons vu précédemment
(chapitre 03) que nous avons opté pour une approche de génération et transmission progressive
de la carte finale par couches d'intérêt dans le but d'étendre SIGERT pour offrir un service
cartographique automatique pour des terminaux mobiles. L'architecture du système SIGERT
(Figure 22) est composée de plusieurs modules.
Un premier module du système est l'application client Web pour des terminaux mobiles de
type PDA (Figure 22, module 1). Un deuxième module du système est composé de
l'application client web pour des ordinateurs de bureau (Figure 22, module 2). Un troisième
module du système est la base de données géographiques (Figure 22, module 6), une base de
données à représentations multiples des objets géographiques de la région desservie par le
système. Un autre module du système est la base de données des utilisateurs qui permet
d'enregistrer les profils des utilisateurs (Figure 22, module 5). La génération des cartes dans le
cadre du système SIGERT est assurée par le système multiagents qui est composé de deux
modules de base.
51
Système Multi Agents
Serveur Web
SIGERT
Module de
traitement
T
3 ) Module de contrôle et
adaptation
Application client Web
Sous-module de
catégorisation (3-1)
Application client Web
mobile
(s
Informations
utilisateurs
Données spatiales
Format GML(base
de données eXist )
Sous-modulc
d'adaptation (3-3)
Prétraitement
Figure 22 : Architecture du système SIGERT
Le premier module est le module de contrôle et d'adaptation (Figure 22, module 3) et le
deuxième module est le module de traitement (Figure 22, module 4). Le module de contrôle et
d'adaptation assure à son tour : l'extraction des données de la base de données géographiques
dépendamment de la requête de l'utilisateur (Figure 22, module 3-2), la catégorisation des
données en des couches d'intérêt (Figure 22, module 3-1) et l'adaptation des couches d'intérêt
et leur transmission au client (Figure 22, module 3-3). Pour ce qui est du module de traitement,
il assure la résolution des conflits spatiaux liés à la présentation de nombreux objets dans un
espace d'affichage restreint.
52
Les données du système SIGERT ont subi une série de prétraitements (Figure 22, module 7)
avant d'être intégrées dans
la base de données du système SIGERT. Le processus de
prétraitement sera décrit dans la section 4-4-1.
Afin de mettre en place un service Web pour la génération cartographique pour des terminaux
mobiles appelé SIGERT-Mobile, mon travail s'est concentré sur le développement de : (i)
l'application client Web pour des terminaux mobiles de types PDA (Figure 22, module 1), (ii)
le sous-module d'extraction (Figure 22, module 3-2), (iii) le sous-module d'adaptation (Figure
22, module 3-3) et (iv) un viewer SVG pour la visualisation progressive des données sur le
terminal mobile.
Le fonctionnement du service SIGERT-Mobile peut être résumé dans les étapes suivantes :
a- Saisie des données : L'utilisateur mobile sélectionne la zone d'intérêt par le biais d'une
carte d'orientation au format SVG Tiny. Il sélectionne ensuite les différents types
d'objets qu'il désire voir apparaître sur la carte finale. Les coordonnées de la zone
d'intérêt ainsi que les éléments à afficher sont envoyés au serveur par l'application
client (Figure 22, module 1).
b- Soumission des requêtes à la base de données géographiques : Quand le serveur
SIGERT reçoit la demande de service (requête utilisateur), le sous-module d'extraction
(Figure 22, module 3-2) récupère les coordonnées de la sélection sur la carte
d'orientation ainsi que les types d'objets pour lesquels l'utilisateur a opté. Ensuite il
génère autant de requêtes qu'il y a de types d'objets sélectionnés. Enfin ces requêtes
sont adressées à la base de données eXist (Figure 22, module 6).
c- Génération progressive des couches d'intérêt : La base de données eXist (Figure 22,
module 3-6) génère plusieurs fichiers GML temporaires (autant de fichiers que d'objets
sélectionnés par l'utilisateur) et les envoie au sous-module d'extraction (Figure 22,
module 3-2). Une fois que le sous-module d'extraction reçoit tous les fichiers GML
temporaires, il génère le fichier GML final à partir de tous les fichiers temporaires et
l'envoie au sous-module de catégorisation (Figure 22, module 3-1). A partir de ce
fichier le sous-module de catégorisation génère un ensemble de fichiers GML par
catégorie (OED, OR et OO) et les envoie au module de traitement (Figure 22, module
4). Ces catégories qui correspondent à des couches d'intérêt sont générées dans
l'ordre suivant : les objets explicitement demandés (OED), ensuite les objets repères
53
(OR), et enfin les objets ordinaires (00). Durant le processus de génération de chaque
couche d'intérêt, le module de traitement améliore la lisibilité des objets spatiaux qui
forment la couche d'intérêt en résolvant les conflits spatiaux qui résultent de leur
chevauchement. Une fois qu'une couche d'intérêt est traitée par le module de
traitement, elle est envoyée au sous-module d'adaptation (Figure 22, module 3-3). Ce
dernier : (i) adapte les données aux préférences de l'utilisateur et aux propriétés
d'affichage du terminal mobile, (ii) traite les données de cette couche d'intérêt afin
d'en réduire le temps de chargement, (iii) transforme les données au format GML en
format SVG Tiny et (v) transmet la couche générée au client mobile. Ainsi, les
différentes couches d'intérêt sont transmises au client mobile dans leur ordre de
génération (la couche OED puis la couche OR et enfin la couche 0 0 ) .
d- Visualisation progressive des différentes couches d'intérêt : À l'aide de l'application
client, l'utilisateur peut superposer des couches d'intérêt précédemment transférées sur
son terminal mobile. Ainsi, l'utilisateur peut insérer une couche d'intérêt récemment
reçue dans une couche d'intérêt déjà affichée sur son terminal.
Par ailleurs, la couche réseau routier (RR) est prise en considération durant le processus de
génération des autres couches d'intérêt, mais elle n'est pas générée par le système multiagent
car dans les données disponibles sur la zone de Vieux-Québec, le réseau routier est considéré
comme un seul objet. Rappelons les contraintes suivantes : (i) le réseau routier est un objet
volumineux (le réseau routier occupe 60% de la taille de la carte finale), (ii) il n'est pas
modifié durant le processus de génération de la carte (iii) le coût élevé de communication dans
un contexte mobile (l'utilisateur mobile paie en fonction des données transférées). Compte
tenu de ces contraintes, nous avons décidé de sauvegarder la couche réseau routier (RR) sur le
terminal mobile. Nous avons donc utilisé le fichier SVG contenant le réseau routier comme
arrière-plan pour les autres couches générées par le système (OED, OR, 0 0 ) .
54
4.3 Choix technologiques
Dans le but d'étendre le système SIGERT pour offrir un service Web cartographique pour des
terminaux mobiles, nous avons fait plusieurs choix technologiques qui nous ont facilité
l'atteinte des objectifs que nous avions établis. Ces choix technologiques sont reliés au
développement d'une application client Web pour des terminaux mobiles de type PDA, aux
transformations et adaptations de données et à la visualisation progressive de ces données sur
le terminal mobile.
4.3.1 La base de données géographiques du Système SIGERT
Pour la gestion des données relatives aux objets géographiques, l'équipe de recherche (Cosma,
04) a testé plusieurs bases de données natives XML telles que (Xhive, Xindice, eXist,...etc),
et a opté pour eXist15 qui est un système de gestion de base de données Native XML. Parmi les
avantages d'eXist nous citons : l'utilisation d'un index «full-text » qui est simple à utiliser
pour les requêtes sémantiques, la possibilité de requête avec XPath16 et XQuery17 et la
1S
possibilité de développer des applications en utilisant les technologies telles que HTTP ,
XML-RPC19, SOAP20 (Chaudri et al, 03).
4.3.2 La base de données utilisateurs
Cette dernière a pour but de stocker les données relatives aux utilisateurs (préférences
d'affichage, types d'objets, caractéristiques techniques du terminal utilisé). L'équipe de
recherche a utilisé le SGBD relationnel SQL Server 2000 pour la gestion de la base de données
utilisateurs du système SIGERT.
15
eXist: http://exist.sourceforge.net/
XPath - XML Path Language, http://www.w3.org/TR/xpath
17
XQuery - XML Query Language, http://www.w3.org/TR/xquery/
18
HyperText Transfer Protocol (http://www.w3c.org/Protocols/)
19
XML Remote Procédure Calling (http://www.xmlrpc.com/)
16
SOAP - Simple object Access Protocol (http://www.w3c.org/TR/SOAP/)
55
4.3.3 Utilisation du Framework .NET pour le développement du SIGERTMobile
Afin mettre en place un service Web pour la génération cartographique pour des terminaux
mobiles appelé SIGERT-Mobile, nous avons implanté : (i) l'application client Web pour des
terminaux mobiles de types PDA (Figure 22, module 1), (ii) le sous module d'extraction
(Figure 22, module 3-2) et (iii) le sous module d'adaptation (Figure 22, module 3-3). Pour le
développement de ces modules nous avons utilisé la plateforme de développement ASP.NET
qui est intégrée dans l'environnement de développement de Visual Studio .NET 2003.
Le choix de l'environnement .NET pour le développement du service Web SIGERT-Mobile a
été motivé par plusieurs éléments :
-
L'environnement de développement .NET facilite la construction d'applications
orientées service.
Dans la stratégie .NET, le concept de logiciel est vu comme un service, cela
veut dire que la base de données eXist est vue comme un service Web dont les
fonctions peuvent être appelées.
.NET offre un modèle de programmation très souple pour le développement des
applications Web (séparation entre le code et l'interface).
La facilité de déploiement des applications, l'installation d'une application
(.NET nécessite seulement de la copier dans un répertoire.)
La plateforme .NET est multi-langages, ce qui est une grande nouveauté par
rapport à ses concurrents directs (il est possible de créer une classe Visual Basic
qui dérive d'une classe C++).
.NET permet la gestion automatique des ressources, la machine virtuelle
appelée CLR (Common Language Runtime) du framework .NET optimise
l'utilisation des ressources du système.
- .NET est fondé sur XML, ce qui permet de manipuler facilement les données
XML/GML dans le système SIGERT.
.NET offre un environnement sécurisé du moment qu'il permet de définir des
rôles au niveau d'une application et offre la possibilité d'y contrôler l'accès en
se basant sur ces rôles.
56
-
Le .NET Framework et les contrôles mobiles ASP.NET forment une plateforme puissante, flexible et extensible pour le développement et le déploiement
d'applications Web mobiles.
.NET permet d'utiliser les Web Forms qui se présentent sous forme de langage
HTML et de scripts compatibles avec les navigateurs, ce qui permet à n'importe
quel navigateur d'afficher ces pages, quelle que soit la plate-forme où il
s'exécute.
4.3.4 Développement des modules de traitement et de catégorisation
Le module de traitement (Figure 22, module 4) et le sous module de catégorisation (Figure 22,
module 3-1) du système multiagent qui sont responsables de la résolution des conflits spatiaux
sont implantés en se basant sur la plateforme Jade21 (Jabeur, 05). Il existe plusieurs
plateformes pour le développement des systèmes multiagent, entre autres Zeus22, MadKit23,
AgentBuilder24, Jack25, Beegent26. Ces plateformes peuvent être comparées selon plusieurs
critères tels que la méthodologie utilisée, la facilité d'apprentissage, la flexibilité, les
communications inter-agents et le déploiement (Quinqueton 2004). Par exemple, Zeus et
AgentBuilder, qui peuvent être considérés comme étant les plateformes les plus complètes
(Quinqueton 2004), offrent aux utilisateurs une documentation abondante ainsi que des outils
pertinents de débogage des programmes. Par contre, elles ne sont pas suffisamment
extensibles. En outre, les utilisateurs doivent connaître la technique de modélisation Rôle
Modeling de Zeus et le langage RADL (Reticular Agent Définition Language) de
AgentBuilder. Par ailleurs, Jade permet le développement des applications conformément aux
spécifications FIPA 2000 concernant l'interopérabilité des systèmes multiagents (Bellifemine
et al. 2001). Il permet d'établir des échanges de messages simples entre les agents et de
modéliser et gérer leurs cycles de vie. Jade, tout comme Jack, offre aux utilisateurs des
facilités d'implantation de haut niveau. Dans le cas de Jade, le développement des agents est
21
Jade (Java Agent Development framework): http://jade.cselt.it/
Zeus: http://www.labs.bt.com/projects/agents/zeus
23
MadKit: http://www.madkit.org/
24
AgentBuilder: http://www.agentbuilder.com/
25
Jack: http://www.agent-software.com/
26
Beegent: http://www2.toshiba.co.ip/rdc/beegent/index.htm
22
57
basé sur l'utilisation de Java, alors que dans le cas de Jack il est basé sur l'utilisation de JAL
(Jack Agent Language).
Le choix de Jade a été motivé par plusieurs raisons:
-
Jade offre des moyens d'implantation faciles à utiliser
Jade est développé en Java dont l'avantage essentiel est la portabilité. En effet, ce Java
permet d'utiliser le système sous différents systèmes d'exploitation.
-
Jade offre beaucoup de moyens permettant la gestion des cycles de vie des agents de
façon simple. En effet, il prédéfinit un ensemble de comportements intéressants tels
que les comportements simple, cyclique, séquentiel, parallèle et machine à état fini.
Ces comportements permettent aux développeurs de définir les actions qui devraient
être effectuées par les agents afin d'atteindre leurs objectifs.
4.3.5 Choix d'un PDA pour tester le service SIGERT-Mobile
Pour tester le prototype SIGERT-Mobile, nous avons utilisé un HP iPAQ Pocket PC h5550 qui
tourne sous le système d'exploitation Microsoft Windows Mobile 2003 (pour plus de détail
voir Annexe D). Pour simuler une connexion sans fil au serveur SIGERT, nous avons connecté
notre Pocket PC au réseau local sans fil de l'Université Laval en utilisant la carte réseau sans
fil (Compact Flash 802.1 lb Wireless LAN).
4.3.6 Choix technologique pour le développement d'un viewer SVG pour
PDA
Nous avons vu précédemment (Section 3-3-3) que la technique d'affichage progressif des
différentes couches d'intérêt (OED, OR, OO) générées par le serveur sur le terminal mobile
permet à l'utilisateur d'insérer une couche d'intérêt précédemment reçue dans une couche
d'intérêt déjà affichée sur le terminal mobile.
Pour implémenter l'affichage progressif, nous avons besoin d'un viewer SVG permettant la
visualisation progressive des différentes couches d'intérêt sur notre Pocket PC. Parmi les
différents viewers SVG pour PDA qui se partagent le marché, on en peut trouver cinq qui
fonctionnent sous Pocket PC :
27
Pocket SVG27 de la compagnie CSIRO,
Pocket SVG : www.pocketsvg.com
58
-
SharpMotionART28 player de Sharp,
-
Bitflash29 Mobile player de la compagnie BitFlash
eSVG30 (conçu par Intesis pour le compte de Ultimodule).
TinyLine31 SVG de la compagnie TinyLine.
Cependant, ces viewers ne permettent pas la visualisation progressive, ce qui nous a obligé de
développer un viewer SVG personalisé appelé SIGERT-Mobile. Pour ce faire, nous avons
utilisé TinyLine SVG Toolkit qui est un toolkit gratuit pour le développement des applications
basées sur SVG Tiny. Notre choix s'est porté sur ce toolkit car : (i) il offre un package Java
pour implémenter un viewer SVG standard ; (ii) il offre un bon support technique et une
documentation complète ; (iii) il fournit des API java permettant de manipuler des éléments
d'un document SVG Tiny (insertion, suppression, modification) et (iv) il offre la possibilité
d'afficher des documents SVG Tiny compressés.
Notre viewer SIGERT-Mobile s'exécute sur Jeode VM32 qui est une machine virtuelle Java
pour des terminaux mobiles de type PDA. Le choix de Jeode VM a été fait après exploration
des différentes machines virtuelles Java pour Pocket PC telles que (J933 d'IBM, CrEme34 de
NSIcom, Personal Java35 de SUN, MicroChaim36 VM de HP, SavaJe XE37 de SavaJe). Ce
choix a été motivé par plusieurs raisons :
Jeode VM supporte de nombreuses librairies
-
facilité de déploiement des applications
28
SharpMotionART: www.sharpmotionart,corn
29
Bitflash : www.bitflash.com
3O
eSVG: http://www.ultimodule.com
31
32
Tinyline : www.tinvline.com
Jeode est une machine virtuelle développée par la compagnie Insignia, elle est disponible pour appareils
mobiles ayant un processeur StrongARM ou MIPS.
33
J9 est une machine virtuelle disponible pour appareils mobiles ayant un processeur StrongARM
34
CrEme est une machine virtuelle Java spécialement configurée pour tourner dans l'environnement
Pocket PC.
35
Personal Java est une machine virtuelle développée par SUN, elle est disponible pour appareils mobiles ayant
un processeur StrongARM, MIPS ou SH.
36
MicroChaim est une machine virtuelle développée par HP, elle est disponible pour appareils mobiles ayant un
processeur StrongARM ou SH.
SavaJe XE est une machine virtuelle qui ne tourne pas a coté du système d'exploitation, mais elle nécessite le
remplacement complet de la ROM pour installer son propre système d'exploitation.
59
facilité d'installation
-
une version gratuite de Jeode VM est livrée avec notre HP iPAQ Pocket
PC h5550.
4.4 Développement du service SIGERT-Mobile
Après avoir vu les différents choix technologiques liés au développement du service web
cartographique SIGERT-Mobile, nous détaillons dans la présente section le processus de
préparation des données du système SIGERT, le développement du service SIGERT-Mobile,
ainsi que le développement d'un viewer SVG permettant la visualisation progressive des
données sur PDA.
4.4.1 Préparation de données
Dans le cadre du projet SIGERT, les données proviennent de diverses sources fournies par
divers organismes : Le Centre de Recherche de la Défense à Valcartier (CRDV), le Centre
d'Information Topographique de Sherbrooke (CITS), le Ministère des Ressources Naturelles
de Québec (MRNQ), le Centre de Recherche en Aménagement et Développement (CRAD).
Nous avons choisi, parmi les données à notre disposition, les données en provenance du Centre
de Recherche en Aménagement et Développement (CRAD), qui sont les données donnant le
plus de détail pour la région du Vieux-Québec et qui sont à une échelle de 1 :1000 et se
composent de plusieurs couches (couche bâtiments publics, couche bâtiments privés et la
couche des routes).
Ces données ont subi une série de transformations afin de les rendre conformes à la structure
de données de SIGERT, ces traitements se résument comme suit (figure 23) :
-
Etape d'intégration de données : élaboration de l'entrepôt de données
du projet
GEMURE.
-
Etape de transformation FME38 : transformation des données spatiales (provenant des
différentes bases de données source) en différents formats vers des fichiers GML (dans
une structure prédéfinie fournie par l'outil FME), cette étape a été réalisée par l'équipe
de recherche qui a développée la version initiale du SIGERT (Cosma, 04).
38
FME (Feature Manipulation Engine) de Safe Software, outil de type ETL {Extract, Transform, Load) qui
permet la transformation des données spatiales entre une panoplie de formats
60
Etape de transformation XSLT structure initiale : transformation XSLT permettant de
générer des fichiers GML dans la structure propre à la version desktop du système
SIGERT.
Etape de transformation XSLT structure finale : nous avons réalisé cette transformation
XSLT dans le but de générer des fichiers GML dans la structure propre à la version
finale du système SIGERT (desktop et PDA).
Chaîne de traitement des données
(Version Initiale SIGERT)
transformation finale des données
(Version finale SIGERT)
A.
Figure 23 : Série de traitement des données du système SIGERT
Quand on parle de données spatiales, il est très important de réaliser des requêtes spatiales.
Dans notre cas, on devrait être capable d'extraire de la base de données eXist, les informations
concernant l'ensemble des objets géographiques qui se trouvent à l'intérieur d'une zone
donnée. Toutefois, on ne possède pas encore de langage de requête spatiale pour les données
de type XML et aucune base de données native XML sur le marché ne supporte des requêtes
spatiales. Or, on a besoin d'extraire de la base de données des informations correspondant à
une région donnée. Pour contourner ce problème, Cosma (Cosma, 04) a introduit un
découpage de l'espace en plusieurs zones selon une grille orthogonale et l'indexation des
données est faite en fonction de cette grille (figure 24).
Pour chaque objet géographique, on a ajouté les identifiants de toutes les tuiles de la grille,
touchées par l'objet, ce qui réduit la requête spatiale à une simple requête par identifiant. Par
61
exemple, pour rechercher tous les objets géographiques qui se trouvent à l'intérieur d'un
rectangle déterminant la zone de recherche, on demande à la base de données les informations
de tous les objets possédant les identifiants suivants : ABAB, ABAC, ABAD, ABAE, ACAE,
ACAC, ACAD, ACAE, ADAB, ADAC, AD AD ET ADAE. Du moment que tous les fichiers
GML stockés dans la base de données eXist sont indexés, la recherche se réalise très
rapidement.
AA AB AC AD AE AF AG AH AI AJ AK
Figure 24 : Indexation des objets géographiques en utilisant une grille orthogonale
(tiré de Cosma, 04)
4.4.2 Présentation du développement du service SIGERT-Mobile
Nous avons vu précédemment (section 4-3-3), que notre travail s'est concentré sur le
développement des modules d'extraction et d'adaptation. Ainsi, l'extraction et l'adaptation de
données dans le cadre du service SIGERT-Mobile sont implantées par les classes
QueryService , SpatialQuery, RequeteExist, GmlToSVGtiny.
62
La classe « QueryService » assure la connexion à la base de données eXist et elle permet
d'adresser une requête à cette base. Elle fournit aussi des méthodes permettant de récupérer les
données qui sont extraites de la base de données sous la forme d'un flux textuel.
Quant à la classe « SpatialQuery », elle assure la génération de la requête à envoyer à la base
de données eXist. Ainsi, elle fournit des méthodes permettant de générer la requête eXist en
tenant compte du calcul des tuiles et des types d'objets sélectionnés par l'utilisateur. Le
processus de génération de la requête spatiale par la classe SpatialQuery est détaillé dans la
figure 25.
Coordonnées de la zone de
recherche (xl,yl ( x2,y2)
calculerTuiles()
calculerldentifiant()
I
Types d'objets sélectionnés
(Musée, Hôtel, ... )
Tuiles :
AAAB, AAAC, ABAB, ABAC, ACAB, ACAC
construireRequeteSpatialQ
ï
"document(*)//GeoObject[match-any(tile,' AAAB, AAAC, ABAB, ABAC, ACAB, ACAC')] [match-any(//category,'Hôtel')]/.."
"document(*)//GeoObject[match-any(tile,' AAAB, AAAC, ABAB, ABAC, ACAB, ACAC')] [match-any(//category,'Musee')]/..
Figure 25: Méthodes de la classe SpatialQuery
La classe « RequeteExist » fournit plusieurs méthodes permettant d'adresser des requêtes à la
base de données eXist, de récupérer les résultats des requêtes dans des fichiers temporaires et
63
enfin de créer le fichier GML final qui contiendra l'ensemble des objets correspondant à la
zone d'intérêt, sélectionnée par l'utilisateur (Figure 26). La méthode soumettreRequeteExistQ
permet d'adresser la requête à la base de données eXist. Enfin, la méthode creerFichierGmlQ
assure la création du fichier GML finale.
Requêtes
"document(*)//GeoObject[match-any(tile,' AAAB, AAAC, ABAB, ABAC, ACAB, ACAC')] [match-any(//categoiy,'Hotel1)]/.."
"dooument(*)//GeoObject[match-any(tile,' AAAB, AAAC, ABAB, ABAC, ACAB, ACAC')] [match-any(//category,'Musee')]/.."
I
soumettreRequeteExistQ
Fichier résultat
intermédiare « Hôtel »
Fichier résultat
intermédiare « Musée »
1
creerFichierGmlQ
I
Fichier
GML final
Figure 26: Méthodes de la classe « RequeteExist »
Quant à la classe GmlToSVGtiny, elle fournit trois méthodes principales, la première appelée
transformerGmltoSvg() permet : (i) la transformation d'un fichier au format GML en un
fichier au format SVG Tiny, (ii) l'adaptation du fichier SVG Tiny pour un contexte mobile et
(iii) génération automatique de symboles de la carte au format SVG Tiny. La méthode
64
transformerGmltoSvgO utilise le moteur de transformation XSLT du Framework ASP.NET.
Toute la logique de transformation et d'adaptation se trouve dans des fichiers XSLT que nous
avons conçus. Dans l'Annexe A, vous pouvez consulter un exemple de fichier XSLT que nous
avons conçu pour la transformation des données GML en format SVG Tiny (format
visualisable sur PDA).
Pour ce qui est de l'adaptation de la couche générée au contexte mobile, nous avons intégré
dans les fichiers de transformation XSLT des patterns permettant de réduire le temps de
chargement de la carte SVG Tiny finale. Cette adaptation se résume comme suit (Figure 27):
- regroupement des éléments qui se partagent des attributs communs : couleurs,
styles,... etc.
- minimisation du remplissage des formes (stroking) dans le rendu ( cela veut dire
éviter le remplissage des objets géographiques pour accélérer le temps de
chargement du fichier).
- utilisation des polices de caractères définies dans la spécification SVG mobile.
- On a aussi évité d'utiliser des textes longs, la plupart des viewers SVG pour
PDA considèrent les caractères à afficher comme des formes géométriques à
dessiner. Ainsi l'affichage d'un long texte consomme beaucoup de ressources
pour le terminal mobile.
En plus de l'adaptation et transformation, les fichiers XSLT que nous avons conçus permettent
la génération automatique des symboles dans le fichier SVG tiny. Il est à noter que les
symboles d'une carte générée par le système SIGERT pour un terminal de type desktop, sont
pré-stockés dans une base de données de pictogrammes (Annexe B) qui est composée de
fichiers SVG stockés dans le système de fichiers, et ils sont référés dans les fichiers GML de
la base de données géographiques du système SIGERT. Ainsi l'affichage d'un symbole sur
une carte revient à référencer le fichier SVG représentant le symbole dans le fichier SVG
final.
Par ailleurs, dans un contexte mobile nous avons opté pour une solution permettant la
génération automatique des symboles au moment de la transformation du fichier GML en
fichier SVG Tiny. Ces symboles ont un format simple (un rectangle et une lettre) ce qui
réduit la taille de la carte finale.
65
<?xml version="l.0" encoding="utf-8"?><?xml-stylesheet
<svg id="root" width="5cm" height="6cm"
viewBox="0 -200 400 200">
<g id="fils">
<g
Vg t r a n 8 f o t m - » m a t r i x (( i , o , o , - 1, , 0, , 0) ) ••>
v<
v
*'#«g..twçtl^form=»translate(-331517^5^^53^"^*
type="text/css"?>
Ç~
~\
Ç
<Regroupement
[ des éléments J
<path d="M 331737.8125 331745.5,5186794.75 331743.75,5186784
331737.8125,5186796.375 z" fill="blue">
<title>Auberge la Ripaille</title>
<desc>, rue de Buade</desc>
</path>
<rect x="331737" y="5186796" width="25" height="25"
stroke="rgb(0,0,0)" fill="rgb(255, 255, 255)" stroke-width="3">
</rect>
...«•••••••-••••••«...
s
< t s x t X—"2 2 5 '
Utilisation d'une
font-size:"20""fiir"bïâck«^- ï r - 1
</text>
<text x="245" y="-248" font-family="Arial"
font-size="20"
fill="black">1236
</text>
police de
police
de caractères
caractèr
définis dans SVG
<desc>79, rue Sainte-Anne</desc>
Pas de
</path>
<rect x="331484" y="5186762" width="25" height="25" remplissage des
stroke="rgb(0,0,0)" fill="rgb(255, 255, 255)"
formes des objets
stroke-width="3">
</rect>
<text x="-28" y="-214" font-family="Arial" font-size="20"
fill="black">H</text>
<text x="-8" y="-214" font-family="Arial"
font-size="20" fill="black">13 06</text>
<path d="M 331659.40625,5186768.75 331657.3125, 331651.5,5186769.5
331651.40625,5186770.625 331659.40625,5186768.75 z"
fill="rgb(255, 255, 224)">
<title>Musee de c i r e < / t i t l e >
<desc>22, rue Sainte-Anne</desc>
</path>
Figure 27 : Exemple de fichier SVG Tiny adapté au contexte mobile
Le choix de cette technique pour la génération des symboles pour des terminaux mobiles a
été motivé par plusieurs raisons :
66
la plupart des viewers SVG pour des terminaux mobiles (PDA ou téléphone
cellulaire) ne permettent pas le référencement des symboles dans un document
SVG
l'instabilité du réseau mobile, la faiblesse de sa bande passante, et le coût
associé au transfert de données entre le serveur et le client mobile nous
obligent a minimiser les données transférées au client mobile.
Le référencement de plusieurs symboles dans un même document SVG en
augmente le temps de chargement.
La figure 28 présente un fragment du fichier XSLT utilisé pour la génération automatique des
symboles. Dans l'Annexe C, vous pouvez consulter un exemple de fichier SVG qui illustre
l'intégration des symboles dans la carte finale.
<xsl :element name=*'rect"j
Rectangle du symbole
<xsl:attribute
dinates,l,6))
<xsl:value-of select="..
</xsl:attribute>
Coordonnées du rectangle
<xsl:attribute
<xsl:value-of select="(..//gml:coordinates,
),
</xsl:attribute>
<xsl :attribute name=.'l'width";*25</xsl :attribute>
<xsl:attribute name='M^igl].fr'li>25</xsl :attribute>
<xsl :attribute nam^i-stro']cë-!.'>rgb(0, 0,0) </xsl :attribute>
<xsl :attribute J»ame=\fill">)fgb(255, 255, 255) </xsl :attribute>
<xsl : attrib_u£t3 name= " s'troR'ê^-width" >3</xsl : attribute>
</xsl:element>
Longueur et hauteur du symbole en pixel
<xs 1 : élément name= " t,ext." >
<xsl : attribute)<aame- "x" ^
Texte du symbole
: c o o r d i n a t e s , j . , oi ) - ç > x x + o " / >
<xsl:vaïu"ë'-"of sele^'t'jf
</xsl:attribute>
<xsl:attribute name="y">
Coordonnées du texte
<xsl : value-of seleéjt.î?
</xsl:attribute>
<xsl :attribute name="font- - family">Arial</xsl :attribute>
<xsl :attribute name= "..f"6nt-size"'>'2.p</xsl :attribute>
<xsl : attribute name=(' f ill " >black<^xsl : attribute>
<xsl : value-of select="'ïiQî;malize-.s^6i^e ($symbol) "
</xsl:element>
Type, taille et couleur du texte
Figure 28 : Génération des symboles pour des terminaux mobiles
67
Dans le but de réduire davantage la taille de la carte finale, La deuxième méthode
« compressSvgO» de la classe « GmlToSVGtiny » assure la compression des différentes
couches d'intérêt générées sur le serveur. Cette compression nous a permis de réduire la taille
de la carte finale de 75 %.
Pour ce qui est de la troisième méthode « TransfertLayerQ » de la classe « GmlToSVGtiny »,
elle assure le transfert des différentes couches d'intérêt au client mobile.
Dans le prototype actuel du SIGERT, le module de traitement et le sous module de
catégorisation du système multiagent qui sont responsables de la résolution des conflits
spatiaux sont implantés par un autre membre de l'équipe de recherche du SIGERT en se basant
sur la plateforme Jade (Jabeur, 05). Etant donné que la communication entre Java et .NET est
actuellement impossible, la solution que nous avons développée afin d'intégrer le processus de
résolution des conflits spatiaux dans notre service SIGERT-Mobile est la suivante :
- Les données extraites par le module d'extraction sous format d'un fichier GML sont stockées
dans un répertoire « données Jnitiales».
- Le module de catégorisation du système multiagent, par le biais de l'agent Coordinateur,
scrute constamment le répertoire « donnéesJnitiales ». Lorsqu'il y trouve le fichier généré par
le module d'extraction, il lance la génération des différentes couches d'intérêt (OED, OR, OO)
et les stocke dans des fichiers GML.
- À la fin de la génération de chaque couche d'intérêt, l'agent Coordinateur met cette couche
dans un répertoire appelé «donnéesJinales». Ainsi, le module d'adaptation extrait ces données
en format GML et les transforme en format SVG Tiny tout en appliquant des adaptations pour
les rendre visualisables sur le terminal mobile. Une fois qu'une couche d'intérêt est
transformée en format SVG Tiny, elle est transférée automatiquement au client mobile.
68
4.4.3 Développement du viewer SIGERT-Mobile
Nous avons vu précédemment (section 4-3-4), que nous avons utilisé TinyLine SVG Toolkit
pour développer notre viewer SVG SIGERT-Mobile. Pour ce faire, nous avons utilisé un
package Tinyline qui contient les classes implémentant le viewer SVG: TinyLine,
PPSVGCanvas, PPSVGBitmap, MouseHandler, PPSVGPlayer, StatusBar (figure 29). En plus
de ces classes, nous avons développé une classe appelée TinySIGERT qui hérite de la classe
TinyLine et qui fournit plusieurs méthodes {Display_RN(),Display_layer(), InsertJayer et
Disply_desc()).
La méthode Display_RN() assure l'affichage de la première couche d'intérêt qui est la couche
réseau routier (RR). L'affichage de la couche réseau routier consiste initialement à parser le
fichier correspondant (les données sont stockées en mémoire dans une structure DOM39).
Ensuite, la méthode DisplayQ permet d'afficher les éléments de la structure DOM (Figure 30).
Ainsi, tous les objets géographiques (routes) qui se trouvent dans le fichier correspondant au
réseau routier sont affichés.
TinvSIGERT
TinvLine
t
1
1
r
MouseHandler
PPSVGCanvas
*
1
PPSVGBitmap
*
1
StatusBar
1
PPSVGPIaver
Figure 29 : Diagramme de classe du viewer SIGERT-Mobile
39
DOM (Document Object Model) : Le DOM fournit une représentation en mémoire d'un document XML. Le
DOM permet de lire, de manipuler et de modifier un document XML par programme
69
La méthode InsertJayerQ permet l'insertion d'une couche d'intérêt nouvellement reçue dans
une couche déjà affichée sur le terminal mobile (insertion de la couche d'intérêt OED dans la
couche RR déjà affichée) (Figure 31).
DisplayRN (fichier_ réseau-routier )
//lire le fichier SVG correspondant au réseau routier et le stocker en
mémoire dans une structure DOM.JISVGDocument doc père=cJQadSV&(fichie réseau-routier)
II Afficher les éléments de la structure DOM sur le viewer.//
Viewer.Display(),
1
•>
1
l
SVGDocument loadSVG (fichier_ réseau-routier)
SVGDocument svgdocument = null;
Object obj = null,
// créer une URL
URL url = new URL ('fichier_ réseau-routier"),
//lire le flux
Obj= url.openStream(),
Si (fichier SVG compressé)
r
1
// Décompressé le fichier SVG
Obj= new GZIPInputStream(obj),
// parser le fichier et récupérer le document
correspondant
svgdocument = parse (obj)
return svgdocument,
Si Non
r
l
svgdocument = parse (obj)
return svgdocument
Figure 30: Description de la méthode Display_NR()
70
Quant à la méthode DisplayJayerQ, elle fait appel à la méthode InsertJayerQ pour l'insertion
de la couche à afficher dans la couche déjà affichée (Figure 31). Ensuite, elle permet d'afficher
les deux couches ensemble (par exemple l'affichage de la couche « RR+OED »,
« RR+OED+OR » ou « RR+OED+OR+OO »).
Displaylayer (fichier_oed)
x
II Insérer le document fils dans le document père
$nsert_layë%(fichier oed)
// AffîcheQes deux document ensemble
Viewerïii^playO,
\
Insertlayer {fichier_oed)
<
X
II Récupérer le nœud racine du document père :
noued_racineP=doc_pere. getnodeByld ('root')
//Lire le fichier fils dans une structure DOM
Document svgdocumentF = loadSVG (fichieoed),
//Récupérer le nœud racine du document SVG fils
correspondant au fichier fichier_oed
SVGNode nœud_racineF= svgdocumentF.getnodeByld ('root')
// Insérer le nœud fils dans le nœud racine
noeud racineP.addChild (nœud racineF),
}
Figure 31 : Description des méthodes Displaylayer () et InsertJayerQ.
Quant à la méthode Display_Desc(), elle permet l'affichage des données textuelles permettant
d'informer l'utilisateur du nom et de l'adresse de l'objet sélectionné. Pour ce faire, la méthode
Display_desc() fait appel à une autre méthode appelée Extract_desc () qui récupère les
identifiants et les descriptions (adresse et nom) de tous les objets géographiques de la couche
OED et les stocke dans un tableau (Figure 32). Ainsi, à chaque fois que l'utilisateur veut
71
s'informer sur un objet donné, la fonction Display_Desc() permet d'afficher sa description
(adresse et nom de l'objet).
Displydesc (objectID)
II Récupérer la description de l'objet.sélectionné stockée
dans un tableau par la fonction:j£xtract_desc ())
String description = récupérer_N&uedText (object_ID),
II Affichage de la description ap bas du Viewer
DisplayText (description),
Extractdesc ()
{
II Parser le fichier OED
Document svgdocumenti = loadSVG (fichier_oed),
II Récupérer tous les nœuds textes du document et les
stocker par Id dans un tableau
ExtractJTextNode (svgdocumenti,)
Figure 32 : Description des méthodes Disply_desc () et Extract_desc ()
72
4.5 Le prototype SIGERT-Mobile
Dans le développement du prototype SIGERT-Mobile, nous avons concentré nos efforts dans
le développement de l'application client web pour terminaux de type PDA : le développement
d'un viewer SVG Tiny appelé SIGERT-Mobile pour la visualisation progressive des
différentes couches d'intérêt sur un terminal mobile. L'application client web pour terminaux
mobiles que nous avons développée permet à l'utilisateur de sélectionner un rectangle qui
détermine la zone de recherche par le biais d'une carte d'orientation (Figure 33-a). Une fois la
zone de recherche sélectionnée, l'utilisateur sélectionne les objets à afficher sur la carte finale
en utilisant des cases à cocher (figure 33-b) et lance la recherche en appuyant sur le bouton
correspondant.
(a)
(b)
p Internet Explorer |!f «<~ 09:14
http://132.203,114,119/sigertmobil • m
I •I
Figure 33 : (a) Sélection de la zone de recherche, (b) Sélection des objets à afficher sur la
carte finale.
Une fois que les paramètres de recherche ont été validés, et que le système multiagent termine
la génération de la couche OED, cette dernière est transférée au client mobile. Pendant que le
système multiagent génère la couche OED, le viewer SIGERT-Mobile affiche la couche
73
réseau routier correspondant à la zone de recherche (figure 34-a). Une fois que la couche OED
est transférée sur le terminal mobile, elle est insérée dans la couche RR déjà affichée (figure
34-b). Le viewer SIGERT-Mobile offre plusieurs fonctionnalités telles que : la fonction «
Zoom avant » permettant d'agrandir la carte (figure 34-c), le « Zoom arrière » permettant de
réduire la carte et « Pan » ou translation simple permettant de tirer la carte dans la translation
voulue.
(a)
(b)
(c)
Figure 34 : (a) Affichage de la couche RR, (b) Affichage de la couche RR+OED,(c) Zoom sur
la couche RR+OED.
Une fois que le système multiagent génère la couche OR, elle est transférée sur le terminal
mobile, ensuite l'utilisateur peut l'insérer dans la couche (RR+OED) précédemment affichée
sur le terminal mobile (Figure 35-a). Ainsi pour la couche OO, dès son transfert sur le terminal
client, ce dernier peut l'afficher sur son terminal mobile (Figure 35-b).
Pour permettre à l'utilisateur de reconnaître les objets affichés sur la carte finale, nous avons
décidé d'associer à chaque objet un symbole et un identifiant numérique, de façon à l'identifier
plus facilement à la visualisation de la carte. Au moment où l'utilisateur sélectionne
l'identifiant d'un objet par le biais d'une liste de valeurs, des données textuelles s'affichent au
74
bas du viewer informant l'utilisateur du nom ou de l'adresse de l'objet auquel l'événement est
associé (Figure35-b). Nous avons opté pour l'affichage des données textuelles au bas du
viewer SIGERT-MOBILE au lieu de les afficher sur la carte dans le but de ne pas l'encombrer.
(a)
(b)
Figure 35 : (a) Affichage de la couche RR+OED+OR, (b) Affichage de la couche
RR+OED+OR+OO.
75
4.6 Discussion des avantages de l'approche utilisée
Dans le but de montrer l'intérêt de la génération et de la transmission progressive des cartes
dans un contexte mobile, nous avons utilisé le service SIGERT-MOBILE pour générer et
transférer progressivement une carte et nous avons calculé le temps associé à sa génération.
Ensuite nous avons calculé le temps associé à la génération de la même carte en utilisant une
version modifiée du SIGERT-MOBILE appelée génération globale permettant de générer la
carte sur le serveur, et de la transmettre en une seule fois au terminal mobile.
Le temps de génération de la carte finale dans le cas d'une approche de génération et
transmission progressive est égal à la somme du temps de génération des couches (OED, OR,
OO), du temps de transfert de ces couches, et du temps d'affichage de la couche OO.
Quant au temps de génération de la carte finale en utilisant une approche de génération
globale, il est égal à la somme du temps de génération des couches (OED, OR, OO), du temps
de transfert des couches (RR, OED, OR, OO) et du temps d'affichage des couches (RR, OED,
OR, OO).
La figure 36 présente la différence entre les deux approches selon le temps de génération.
Cette différence (environ 6 secondes) est due principalement aux points suivants: (i)
l'approche de génération et transmission progressive, nous permet d'économiser le temps
associé au transfert de la couche réseau routier (cette couche est stockée sur le terminal
client), qui est un temps non négligeable étant donnée la taille considérable de cette couche
(prés de 60 % de la taille de la carte finale), (ii) dans une approche de génération et
transmission progressive, l'affichage d'une couche s'effectue en même temps que la
génération de la couche suivante (l'affichage de la couche RR s'effectue en parallèle à la
génération de la couche OED). Ce qui permet d'économiser le temps associé à l'affichage des
couches (RR, OED, OR).
76
54
ati
3» 53
o 52-
sduia
5150C
49a»
a> 48•o
47464544Approche utilisée
génération globale
! génération progressive
Figure 36 : Comparaison entre les deux approches selon le temps de génération
La figure 37 présente une comparaison entre les deux approches selon le temps d'attente. Dans
une approche de génération globale, le temps d'attente de l'utilisateur correspond à la
somme du temps de génération des couches (OED, OR, OO), du temps de transfert des
couches (RR, OED, OR, OO) et du temps d'affichage des couches (RR, OED, OR, OO). Dans
l'exemple de la figure 36, le temps d'attente dans cette approche est de 53.6 seconde.
Par contre, dans une approche de génération et transmission progressive, le temps d'attente
correspond à la somme du temps associé à la génération de la première couche qui est la
couche OED, du temps du transfert de cette couche et du temps associé à son affichage. Dans
l'exemple de la figure, le temps d'attente en utilisant une approche de génération et
transmission progressive est de 5.5 secondes.
Non seulement, il y a un grand écart entre les temps d'attente en utilisant les deux approches
(environ 48 secondes), mais ce temps d'attente est d'une grande importance dans une approche
de génération et transmission progressive du moment que l'utilisateur peut l'exploiter pour
77
explorer davantage la couche déjà reçue en attendant la génération de la couche suivante, et
dans la plupart des cas l'utilisateur pourrait décider d'arrêter le téléchargement des couches
suivantes (OR, OO), ce qui lui permet d'économiser le coût de transfert associé.
601
«
50-K
404
30
20
10
.-"'
Approche utilisée
11 génération globale
Igénération progressive
Figure 37 : Comparaison entre les deux approches selon le temps d'attente
Nous avons vu précédemment (section 4-3-1) que pour simuler une connexion sans fil au
serveur SIGERT, nous utilisons une connexion Wireless LAN du réseau local sans fil de
l'université Laval offrant un débit théorique de UMbps. Donc le temps de génération et le
temps d'attente sont calculés en fonction de ce débit. Par ailleurs la différence entre les deux
approches peut être très significative si l'utilisateur mobile utilise une connexion de type
GPRS40 ou UMTS41 pour se connecter au serveur SIGERT.
.-..„ : le General Packet Radio Service est une norme pour la téléphonie mobile dérivée du GSM permettant
GPRS
un débit de données plus élevé (150 Kbit/s).
41
UMTS : l'Universal Mobile Télécommunications System est une norme de troisième génération, après le GSM
et le GPRS, pour les télécommunications numériques. Elle offrira des débits jusqu'à 2 Mbit/s permettant le
transfert rapide de données multimédia sur les mobiles.
La figure 38 présente quant à elle une comparaison des deux approches selon le coût de
transfert de la carte finale. Pour calculer le coût de transfert de la carte finale, nous avons
utilisé le prix de transfert moyen adopté par les opérateurs des réseaux mobiles qui est de 3
cent /Ko. Dans l'exemple de la figure 38, la taille de la carte finale est de 939 Ko dont 828 Ko
correspond à la taille de couche réseau routier (RR). Ainsi, dans une approche de génération et
transmission progressive, le volume des données transférées au client mobile est égal à (939828= 111 Ko) du moment que la couche réseau routier est stockée sur le terminal mobile.
Donc, le prix associé au transfert de ces données est égal à 0.37 $(111/3= 0.37$). Par contre
dans une approche de génération globale, la carte finale est transférée au client mobile (939
Ko), ce qui engendre un coût de 3.13$ ( 939/3 = 3.13 $). Ainsi, l'utilisation de l'approche de
génération et transmission progressive nous a permis d'économiser environ 2.7 Dollars en
terme de coût de transfert de la carte finale au client mobile.
approche utilisée
D génération globale
I génération progressive
Figure 38 : Comparaison des deux approches selon le coût de transfert de la carte
19
4.7 Conclusion
Ce chapitre a présenté le prototype du service SIGERT-Mobile, un service du système
SIGERT permettant la génération cartographique sur le Web pour des terminaux mobiles de
type PDA. Le développement de ce prototype nous a permis de valider l'approche adoptée
dans le cadre du projet SIGERT pour la génération, la transmission et la visualisation
progressive des cartes par couches d'intérêt dans un contexte mobile. Ainsi, l'analyse des
résultats en terme de temps et coût de génération de la carte finale nous a permis de montrer
l'intérêt d'une telle approche pour la génération des cartes dans un contexte mobile.
Chapitre V
Conclusion générale
81
Chapitre 5: Conclusion générale
5.1 Conclusion
La génération cartographique à la volée sur le Web dans un contexte mobile est un problème
vaste aux facettes multiples. Non seulement le temps de génération de la carte doit être le plus
court possible, mais il faut que la production de la carte finale puisse s'accommoder des
caractéristiques techniques plutôt limitées des terminaux mobiles (faiblesse et instabilité du
transfert de données, capacités réduites en termes de calcul, de stockage et surtout de surface
d'affichage).
La recherche entreprise dans ce mémoire s'inscrit dans le cadre du projet GEMURE. Ce projet
vise à fusionner plusieurs sources de données, essentiellement hétérogènes, dans un entrepôt
de données (Data Warehouse) qui sera exploité en spécialisant l'information qu'il contient
dans des bases de données pivots (Datamarts). Dans le cadre de ce projet, l'équipe dirigée par
M. Bernard
Moulin utilise un datamart du projet GEMURE dans le but de fournir un
ensemble de services touristiques et récréatifs aux utilisateurs. Ce paquet de services est
regroupé dans le cadre du système SIGERT (Système Intelligent pour la Gestion des Espaces
Récréatifs et Touristiques). Initialement le système SIGERT permettait la génération
automatique des services cartographiques sur le Web pour des ordinateurs de bureau. Le but
principal du présent travail était l'extension du système SIGERT pour qu'il supporte un
service cartographique multimodal automatique, soit un service permettant la production et la
livraison des cartes sur le Web pour des terminaux fixes et mobiles. Étant donné l'utilisation
de ce service dans un environnement Web mobile pour des différents types de terminaux,
l'utilisation du standard SVG mobile s'avère plus qu'indispensable.
L'approche adoptée dans le cadre du système SIGERT combine la généralisation
cartographique et la représentation multiple pour la génération automatique des cartes pour des
ordinateurs de bureau. Par ailleurs, dans un contexte de génération cartographique à la volée
sur le Web pour des terminaux mobiles, les deux concepts de généralisation à la volée et de
représentation multiple doivent être associés à une solution permettant d'adapter la carte finale
générée aux contraintes du contexte mobile (caractéristiques techniques limitées du terminal
82
mobile, faiblesse et instabilité de transfert de données, etc). Par conséquent, nous avons opté
pour une approche appelée « génération et transmission progressive des cartes par couches
d'intérêt ». Cette approche est basée sur l'utilisation d'une base de données à représentation
multiple et un Système multiagent pour la génération progressive des différentes couches
d'intérêt en résolvant les conflits spatiaux qui résultent du chevauchement des différents objets
de ces couches d'intérêt. De plus cette approche se base sur l'adaptation des différentes
couches d'intérêt en fonction des préférences des utilisateurs et des contraintes liées au
contexte mobile et les transmettre progressivement au client mobile. Cette approche permet
aussi la réutilisation de données déjà transmises au client mobile en lui permettant de
superposer les couches d'intérêt sur son terminal mobile. La réutilisation de données permet de
réduire la quantité de données transmise au client mobile et par conséquent le coût associé à
son transfert au client mobile.
Nous avons procédé à l'implantation du SIGERT-Mobile, un service du système SIGERT
permettant la génération automatique des cartes sur le Web pour des terminaux mobiles de
type PDA. Le système SIGERT-Mobile est constitué d'une application Web pour des
terminaux mobiles et d'un viewer SVG Tiny pour la visualisation progressive des différentes
couches d'intérêt sur le terminal mobile. Le développement du service SIGERT-Mobile nous
a permis de valider l'approche adoptée dans le cadre du projet SIGERT pour la génération, la
transmission et la visualisation progressive des cartes par couches d'intérêt dans un contexte
mobile. L'implantation avec succès de ce service nous a permis aussi de répondre à la
problématique abordée dans notre recherche et d'atteindre nos objectifs.
83
5.2 Travaux futurs
Après avoir terminé ces travaux de recherche en satisfaisant nos objectifs initiaux, nous
pensons que nous n'avons pas pu résoudre tous les problèmes reliés à notre contexte d'étude.
Il reste beaucoup de travail à faire et nous souhaiterions justement suggérer des travaux de
recherches futures, pour améliorer l'approche proposée et le système SIGERT.
En effet, la version actuelle du système SIGERT n'est certainement pas une version définitive
comme tout logiciel d'ailleurs. Le prototype actuel du système SIGERT est moyennement lent
et ceci est dû principalement à la plateforme Jade utilisée pour implanter le
Système
multiagent. Dans le but d'accélérer notre approche il serait judicieux d'utiliser le langage C++
à la place de Java pour implémenter le Système multiagent. De plus les performances de notre
système peuvent être améliorées par l'application de simplifications sur les objets spatiaux
bien avant leur intégration dans la base de données eXist.
Une autre amélioration importante pour augmenter l'utilité du système, qui fera partie d'une
phase future dans le développement de ce projet, est la prise en compte de la position GPS de
l'utilisateur durant le processus de sélection de la zone de recherche sur la carte d'orientation
dans le servie SIGERT-Mobile. Ainsi que le développement d'un module permettant d'accéder
au système SIGERT à partir de terminaux WAP.
Concernant la visualisation de données sur un terminal mobile, il serait très important de
mettre en évidence graphiquement les données les plus pertinentes pour l'utilisateur en
changeant leurs couleurs ou par des animations dans le but de se rapprocher de la perception
de l'utilisateur.
Un autre aspect qui pourrait être amélioré est la catégorisation des données durant le processus
de génération de la carte. La catégorisation actuelle (RR, OED, OR, OO) correspond au
contexte touristique, il serait très important d'identifier d'autres catégorisations de données en
fonction des différents contextes (domaine militaire, transport, etc.) dans le but de rendre notre
approche applicable dans ces contextes.
84
Dans ce mémoire, nous avons pu constater que la génération de cartes dans un contexte mobile
est un problème vaste aux facettes multiples. Durant ce processus il serait judicieux de tenir
compte non seulement des contraintes techniques (taille de l'écran, bande passante limitée)
mais il faudrait prendre en considération d'autres facteurs non techniques tels que : (i)
l'environnement de l'utilisation de la carte (l'utilisateur est à pied, en voiture, etc), (ii) la
période d'utilisation de la carte (nuit ou jour) et (iii) les connaissances de l'utilisateur (langue,
connaissance en cartographie, etc.). Ce qui nécessite une approche globale qui prend en
compte l'ensemble des caractéristiques des environnements hétérogènes et la diversité des
clients avec toutes leurs contraintes.
85
Bibliographie
* Publications référées
ARLETH M., 99. Problems in screen map design, Proceedings 19th International
Cartographie Confer ence (ICA 1999), Ottawa, August 14-21, 1999.
* AVELAR S., 02. Schematic Maps OnDemand: Design, Modeling and Visualization,
Dissertation, Institut fur Kartographie,Eidgenôsische Technische Hochschule Zurich.
BADARD T. and BRAUN A., 03. Oxygène: An Open Framework For the Deployment of
Géographie Web Services, Proceedings ICC 2003, Durban, South Africa, August 10-16,
2003.
* BARKOWSKY T., LATECKI L. and RICHTER K.F., 00. Schematizing Maps :
simplification in géographie shape by discrète curve évolution, in C.Freska, W.Brauer,
C.Hbel and K-F Wender (Eds), spatial Cognition II, LNAI 1849 Berlin ; Heidelberg :
Springer-verlag ,41-53.
* BELLIFEMINE F., AGNSTINO P. and GIOVANNI R., 01. JADE: A FIPA2000
Compliant Agent Development Environment. Proceedings of the International Conférence on
Autonomous Agent, Montréal, Canada, ACM, 2001.
BERNIER E., 02. Utilisation de la représentation multiple comme support à la génération
de vues de bases de données géospatiales dans un contexte SOLAP, Mémoire de maîtrise,
Université Laval, 2002.
* BERTIN J., 67. Sémiologie graphique. Les diagrammes, les Réseaux, les Cartes. GauthierVillars, Mouton, Paris, 1967.
* BERTOLOTTO M. and EGENHOFER M.J., 01. Progressive transmission of vector map
data over the world wild web. Geolnformatica, 5(4) :345-373, Décembre 2001.
* BOFFET A., 01. Méthode de création d'informations mulit-niveaux pour la généralisation
de l'urbain. Thèse de doctorat en sciences de l'information géographique, Université de
Marne-la-Vallée, Décembre 2001.
86
* BRENNER C. and SESTER M., 03. Continuous generalization for small mobile displays.
In International Conférence on Next Génération Geospatial Information, Octobre 2003.
BRÛHLMEIER T., 00. Interaktive Karten - adaptives Zoomen mit Scalable Vector
Graphics, Diplomarbeit, Geographisches Institut, Universitât Zurich.
BUCKLEY A.R., GAHEGAN M. and CLARKE K., 00. Géographie visualization as an
emerging research thème in GIScience, Research proposai, University Consortium for
géographie information Science. http://www.ucgis.org/priorities/research/researchwhite/
* BUTTENFIELD B., 02. Transmitting vector geospatial data across the internet. In
Proceedings of the Second International Conférence on Géographie Information Science,
pages 51-64, Boulder, Colorado (USA), Septembre 2002. Springer-Verlag
* BUTTENFIELD B., 99. Progressive transmission of vector data on the internet : A
cartographie solution. In Proceedings 18th International Cartographie Conférence, Ottawa
(Canada), 1999.
* CASAKIN H., BARKOWSKY T., KLIPPEL A. and FREKSA C , 00. Schematic
Maps as Wayfinding Aids, in C. Freksa, W. Brauer, C. Hbel and K. F. Wender (Eds.),
Spatial Cognitionll, LNAI 1849, Berlin; Heidelberg: Springer-Verlag, 54-71.
* CECCONI A. and GALANDA M., 02. Adaptive zooming in web cartography. In
Proceedings
of
SVG
Open
2002, pages
78-83,
Zurich
(Suisse),
Juillet
2002.
http://www.svgopen.org/papers/2002/.
CECCONI A., 03. Intégration of Cartographie Generalization and Multi-Scale Databases
for Enhanced Web Mapping, Dissertation,Geographisches Institut, Universitât Zurich.
CERAMI E., 02. Web Services Essentials, Sebastopol (CA): O'Reilly &Associates.
CHALMERS D., SLOMAN M. and DULAY N., 01. Map Adaptation for Users of
Mobile Systems, Proceedings WWW10, Hong Kong, May 2001.
* CHAUDRI A.B., RASHID A. and ZICARI R., 03. Xml Data Management : Native
XML and XML-Enabled Database Systems, Addison Wesley Professional, 2003.
CHAUDRI.A.B, RASHID.A, ZICARI.R 03, Xml Data Management: Native XML and
XML-Enabled Database Systems, Addison Wesley Professional, 2003
CHEVERST K., DAVIES N., MITCHELL K., FRIDAY A. and EFSTRATIOU C , 00.
Developing a Context-aware Electronic Tourist Guide:Some Issues and Expériences,
87
Proceedings
CHI
2000,
The
Hague,Netherlands,
April
2000,
17-24.
http://www.guide.lancs.ac.ulc/CHIpaper.pdf
* COSMA I., 04. Modèle de données pour la production cartographique sur le Web, mise en
œuvre des représentations multiples en GML, Mémoire de maîtrise, Université Laval, 2004.
* CSMG 01. Cambridge Stratégie Management Group, Location based Services, identifying
and capitalizing on service opportunies, April 2001.
* DEVOGELE T., 97. Processus d'intégration et d'appariement de Bases de données
géographiques. Application à une base de données routières multi-échelles. Thèse de doctorat
de méthodes informatiques, IGN - COGIT, Décembre 1997.
* DOUGLAS D. and PEUCKER T., 73. « Algorithms for the réduction of the number of
points required to represent a digitized Une or its caricature", the Canadian Cartographer,
10(2), p. 112-122.
* DUCHENE C , 04. Généralisation cartographique par agents communicants : Le modèle
CartACom - Application aux données topographiques en zone rural. Thèse de doctorat en
informatique, Paris 6 (Informatique), 2004.
EDWARDES
A.,
BURGHARDT
D.,
BOBZIEN
M.,
HARRIE
L.,
REICHENBACHER. T., SESTER M. and WEIBEL R., 03A. MapGeneralisation
Technology: Addressing the Need for a Common Research Platform, Proceedings 21st
International CartographicConfsrence, Durban, South Africa, August 10-16, 2003.
EDWARDES A., BURGHARDT D., WEIBEL R., 03B. WebPark -Location Based
Services for Species Search in Récréation Area, Proceedings 21st International Cartographie
Conférence, Durban, South Africa, August 10-16, 2003.
ELIAS B., 02. Automatic Dérivation of Location Maps, ProceedingsIAPRS Vol. 34, Part 4
Geospatial Theory, Processing and Applications,Ottawa, Canada.
* ESRI 96 : Automation of Map Generalization, the cutting-Edge Technology. ESRI White
Paper Séries.
FERRARA A., MACDONALD M., 02. Programming .NET Web Services, O'Reilly,
2002.
* FOLLIN J., 04. Gestion incrémentale de données multi-résolutions dans un système
mobile de visualisation d'informations géographiques. Thèse de doctorat en informatique,
université de la Rochelle, 2004.
GARTNER G. and UHLIRZ S., 01. Cartographie Concepts for Realizing a Location
Based UMTS Service: Vienna City Guide "Lol@", Proceedings 20th International
Cartographie Conférence, Beijing,China, August 6 - 10, 2001.
GARTNER G., 03. Pedestrian Navigation Services: A Multimedia Cartography Approach
To Mobile Internet Applications, Proceedings 2 ht International Cartographie Conférence,
Durban, South Africa, August 10-16, 2003.
GASENZER R., 01. Mobile Commerce und Location Based Services: Positionsbasierte
Leistungsangebote fur den mobilen Handel,/ZMD - Praxis der Wirtschaftsinformatik(8): 3751.
* GBEI E., MOULIN B., COSMA I., JABEUR N. and DEL VAL N., 03. Conception d'un
prototype de service web géolocalisé appliqué à l'industrie récréo-touristique, Revue
Internationale de Géomatique, Hermès Science Publications, Vol. 13, No.3 / 2003.
GIMODIG., 04. Geospatial info-Mobility service by real-time Data-integration and
généralisation, http://gimodig.fgi.fi/ (accédé en Novembre 2004), 2004.
* GIROW A., 03. Incrémental SVG mobility and update, Proceedings SVG Open 2003,
http : //www. svgopen. org/2003/papers/Incremental_S VGmobilityandupdate/
Vancouver, Canada
GOODCHILD M.F., 00. Cartographie Futures On A Digital Earth (Keynote Address,19th
International Cartographie Conférence 1999, Ottawa), cartographie perspectives 36(Spring).
GRAHAM C. and KJELDSKOV J., 03. Indexical Représentations for Context-Aware
Mobile Devices, Proceedings IADIS International Conférence on e-Society, Lisbon,
Portugal, June 3-6, 2003.
GRUBER
T.,
01. What
is
an ontology?
http://wwwksl.stanford.edu/kst/what-is-
anontology.html
HAMPE M., ANDERS K.H. and SESTER M., 03. MRDB Applications for Data
Revision and Real-Time Généralisation, Proceedings 2001
89
* HAN-SZE-CHUEN D., 02. Modélisation d'un cas réel de généralisation conceptuelle,
Mémoire de maîtrise, Université Laval, 2002.
* HARRIE L., SARJAKOSKI L. and LEHTO L., 02a. A varaible-scale map for smalldisplay cartography, Proceedings ISPRS Symposium on geospatial theory, processing, and
applications, Ottawa, Canada.
* HARRIE L., SARJAKOSKI T. and LETHO L., 02b. A mapping fonction for variablescale maps in small-display cartography. Journal of geospatial engineering, 4(2) :111-123,
2002.
* IGN, 04. Institut Géographique National et Ministère de l'Education Nationale : Serveur
Educatif dédié à l'Information Géographique. Accédé Juillet 2004. http://pse.ensg.ign.fr/.
* JABEUR N., MOULIN B. and GBEI E., 03. "Une approche par compétition d'agents
pour la résolution de l'encombrement spatial lors de la généralisation automatique des
cartes", JFSMA-2003. pages 161-173, Tunis, novembre 2003.
* JABEUR N., 03. Une approche par compétition d'agents pour la résolution de
l'encombrement spatial lors de la génération automatique d'une carte, Proposition de thèse
de doctorat en informatique, Université Laval, 2003.
* JABEUR N., 05. A Multi-Agent System for On-The-Fly Web Map Génération and Spatial
Conflict Resolution, Thèse de doctorat, Université Laval, 2005.
KILPELINEN T., 00. Knowledge Acquisition for Generalization Rules, cartography an
Géographie Information Science, Vol.27, No.l, pp.41-50.
LAGRANGE J.P., RUAS A. and BENDER L., 93. Rapport interne de l'institut
Géographique National de France 1993.
* LAMY S., RUAS A., DEMAZEU Y., JACKSON M., MACKANESS W. and WEIBEL
R., 99. "The application of Agents in Automated Map Généralisation". In proceeding of
19th ICA meeting. Ottawa, pages 160-169.
* LEHTO L. and KILPELÀINEN T., 01. Real-time généralisation of XML-encoded spatial
data on web. In D. B. Kidner and G. Higgs, editors, Proceedings of the GIS research UK, 9th
Annual Conférence GISRUK 2001, pages 182-184, University of Glamorgan, Wales (GrandeBretagne), Avril 2001.
90
* MACEARCHEN A.M. and KRAAK M.J 01. Research challenges in geovisualization.
Cartography and Geoinformation science journal, 28(1), 2001.
* MARTEL C ,
99. Développement d'un cadre théorique pour la gestion des
représentations multiples dans les bases de données spatiales, Mémoire de maîtrise,
Université Laval, 1999.
* NIVALA A.M and SARJAKOSKI L.T., 03. Need for context-aware topographie maps in
mobile devices. In K. Virrantaus and H. Tveite, editors, ScanGIS'2003 - Proceedings of the
9th Scandinavian Research Conférence on Geographical Information Science, pages 15-29,
Espoo (Finlande), Juin 2003. http://www.scangis.org/scangis2003/papers/.
*
OLE,
99.
OFFICE
DE
LA
LANGUE
FRANÇAISE,
Grand
dictionnaire
terminologique, Gouvernement
OOSTEROM P., 95. GIS and Generalization Methodology and practice, chapter The GAPTree, an approach to 'on-the-fly' map généralisation of an area partitioning, pages 120-132.
GISDATA1. Taylor & Francis, european science foundation édition, 1995.
* QUINQUETON J., 04. Outils logiciels des Systèmes Multi-Agents. Available at:
http://www.lirmm.fr/~iq/Cours/3cvcle/outilsSMA.pdf last access 23 Otober 2005.
* REICHENBACHER T., 03. Mobile Cartography-Adaptative Visualisation on Géographie
Information on Mobile devices . Thèse de doctorat en informatique. Université de Berlin,
2003.
* RUAS A. and BIANCHIN A., 02. Echelle et niveau de détail, dans : Ruas A. (sous la
direction de), Généralisation et représentation multiple, Paris, Hermès Science Publications,
2002a, p. 25-44.
SHEA K.S., 91. Design considération for an intelligent System, Map generalization, Edition
Longman Scientific & Technical
* SIEMENS, 05. UMTS Whitepaper, http://www.siemens.ie/mobile/UMTS/
* SWEDBERG G., 99. Ericsson's mobile location solution, Ericsson review(4) : 214-221.
* THIEMANN F. and SESTER M., 04. Segmentation of buildings for 3D généralisation. In
ICA Workshop on Généralisation and Multiple Représentation, Leicester (Grande-Bretagne),
2004. http://ica.ign.fr/.
91
* VANGENO.C 01, La multi-représentation dans les bases de données géographiques.
Thèse de doctorat n :2430, Ecole Polytechnique Fédérale de Lausanne, 2001.
* WEIBEL R. and DUTTON G., 99. Generalizing spatial data and dealing with multiple
représentation, Longley P.-A., Goodchild M.-F., Maguire D.-J-& Rhind D.-W. (éditeurs),
Geographical Information Systems: Principles and Technical Issues, John Wiley & sons,
Inc., Volume l,pp. 125-155.
* WEIBEL R., BERNIER E., BÉDARD Y. and CECCONI A., 02. La généralisation à
la volée, dans : Ruas A. (sous la direction de), Généralisation et représentation multiple,
Paris, Hermès Science Publications, 2002, p. 319-333.
*ZHOU X., PRASHER S., SUN S. and XU K., 04. Multiresolution spatial databases:
Making web-based spatial applications faster. In Proceedings of 6th Asia-Pacific Web
Conférence, volume 3007/2004, pages 36-47, Hangzhou (Chine), Avril 2004. Springer-Verlag
Heidelberg.
92
Annexes
Annexe A : Fragments du fichier XSLT qui sert à la
transformation des données de GML en SVG Tiny
93
<?xml version="l.0"?>
<xsl:stylesheet version="l.0" xmlns:xsl="http://www.w3.org/1999/
<xslroutput omit-xrnl-declaration="no"/>
Calcul des paramètres gui servent au changement de
système de coordonnées nécessaire pour la transformation
de GML en SVG :
<xsl:variable name="posvl">
<xsl:value-of sélect="string-length(substringbefore(//gml:coordinates[1],','))+1" />
</xsl:variable>
<xsl-.variable name="posv2">
<xsl:value-of select="string-length(substring-before
substring-after(//gml:coordinates[1],','),','))+$posvl+l" />
</xsl:variable>
<xsl:variable name="posel">
<xsl:value-of select="string-length(substring-before
(substring-after(//gml:coordinates[1],','),' '))+$posvl+l" />
</xsl:variable>
<xsl:variable name="xl">
<xsl:value-of select="number(substring
(//gml:coordinates[1],1,$posvl - 1))" />
</xsl:variable>
<xsl:variable name="yl">
<xsl:value-of select="substring(//gml:coordinates[1]
,$posvl+l,$posel - $posvl - 1 ) " />
</xsl:variable>
<xsl: variable name="x2">
<xsl:value-of select="number(substring(//gml:coordinates[1],$posel + 1,
$posv2 - $posel - 1))" />
</xsl:variable>
<xsl: variable name="y2">
<xsl:value-of select="number(substring(//gml:coordinates[1],
$posv2 + 1))" />
</xsl:variable>
<xsl:variable name="dim">
<xsl:choose>
<xsl:when test="$x2 - $xl > $y2 - $yl">
<xsl:value-of select="$x2 - $xl"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="$y2 - $yl"/>
</xsl:otherwise>
</xsl:choose>
</xsl:variable>
94
Création de l'élément racine
Hauteur et longueur de la
<xsl: élément name="svg">
carte
<xsl : a t t r i b u t e name= " id
<xsl : a t t r i b u t e name..="""width
<xsl : a t t r i b u t e name'ï».!.'.height " >6ciri.</xsl : attribute>
<xsl:attribute name="vièwBox"">b <xsl:value-of select="$yl - $y2"/>
<xsl:text> </xsl:textxxsl:value-of select="$x2 - $xl"/>
<xsl:text> </xsl : t e x t x x s l : value-of select="$y2 - $yl"/>
</xsl:attribute>
Création des éléments SVG représentant les objets
géographiques contenus dans le fichier GML
Groupe sémantique
<xsl:élément name="g">
<xsl : attribute name= " id'!;>Batiment<j7xsl : attribute>
<xsl : élément name="g">
['.'.'.'•'•'"••«..,
<xsl : attribute name="id" :».Hotel-:'"ifVn"l i attribute>
Sémantique de l'objet
<xsl: for-each select="//Geb"(3b'jectRepr">
<xsl:if test=".//semCategory[@level='3']='Hôtel'">
<xsl:call-template name="coord">
<xsl : with-param name= " sem.!!.>.$.desc</xsl : with-param>
<xsl : with-param_jaa«iefe^couleur lf> $couleur </xsl : with-param>
name="ÈltTë"">
<xsl:value-of select=".//semCategory[.='Hôtel']/@name"/>
</xsl:with-param>
<xsl : with-param name^'dës c^>
trn.nl. value-ul selecc= " i," / addr e s s "J >
Description de l'objet
</xsl:with-param>
Couleur de l'objet
</xsl:call-template>
</xsl:if>
Adresse de objet
</xsl:for-each>
</xsl:element>
<xsl:élément name="g">
<xsl:attribute name="id">Motel</xsl:attribute>
<xsl:for-each select="//GeoObjectRepr">
<xsl:if test=".//semCategory[@level='3']='Motel'">
<xsl:call-template name="coord">
<xsl:with-param name="sem">Motel</xsl:with-param>
<xsl:with-param name="couleur">rgb(173, 216, 230)
</xsl:with-param>
<xsl:with-param name="title">
<xsl:value-of select=".//semCategory[.='Motel']/@name"/>
</xsl:with-param>
<xsl:with-param name="desc">
<xsl:value-of select="./address"/>
</xsl:with-param>
</xsl:call-template>
</xsl: if>
</xsl:for-each>
</xsl:element>
... Même structure pour les éléments restants
95
Le patron de transformation coord
<xsl:template
<xsl:param
<xsl:param
<xsl :param
<xsl :param
name="coord" match="gml:coordinates">
name="sem">default</xsl:param>
name="couleur">default</xsl:param>
n a m e = " t i t l e " x / x s l :param>
n a m e = " d e s c " x / x s l :param>
<xsl:choose>
<xsl:when t e s t = " n a m e ( . / / g m l : c o o r d i n a t e s / . .
<xsl:élément name="g">
<xsl : attribut.e.....n.aroe.=.''.tranSf o r m n >
•::.•••'matrix ( 1 , 0 , 0 , - 1 , 0 , Ô]"<Axsl : a t t r i b u t e >
r
gml:LinearRing'
Changement entre le système de coordonnées géographiques et le système de coordonnées SVG
<xsl:élément name="g">
<xsl:attribute name="transform">translate(
<xsl:value-of select="-$xl"/>,
<xsl : value-of se.les.t="- $yl"/>) </xsl :attribute>
<xsl: élément name=="path">^|
<xsl : attribute nâm'ë='""d" >^h-<xsl : value-of
select="normalize-space(./7g«aJ:coordinates)
</xsl:attribute>
<xsl :attribute name="f ill"xxsl :<
select="$couleur"/x/xsl :attribute>
<xsl:if test="$title!='
Créer un élément <path> pour chaque objet
<xsl : élément name= " titl,e.">
<xsl:value-of select=?'$title
: element>
</xsl: if>
<xsl : if test=
Créer un élément <title> qui contient le nom de l'objet
<xsl:element name=^desc")>
c " / x / x s l : élément>
<xsl : value-of selëct"=
</xsl:if>
</xsl:element>
Créer un élément <desc> qui contient l'adresse de l'objet
</xsl:element>
</xsl:element>
96
Annexe B : Les symboles construits dans le cadre du SIGERT
pour des terminaux de type desktop
Web SIGCEiï : Icqcndc / Plan
.
-
•
•
•
Uv,
!«
:
•
i.
.
i
•
.
H
Mktosofl Internet Cxplcict
•
•
0 -rt
M.l-,
li
;
\
i
I
.
iPharmacws
:
•
.
.
,
•
H an»,
IntermrtiiTtaw
Ï1IB
i
i i 'iili WtiOCSi
Annexe C : Génération automatique des symboles 97
Pour des terminaux mobiles
<?xml version="l.0" encoding="utf-8"?><?xml-stylesheet
type="text/css"?>
<svg id="root" width="5cm" height="6cm"
viewBox="0 -200 400 200">
<g id="fils">
<g id="Hôtel">
<g transform="matrix(1,0,0,-1,0,0)">
<g transform="translate(-331517,-5186553)">
<path d="M 331737.8125 331745.5,5186794.75
331743.75,5186784 331737.8125,5186796.375 z>
fill="blue">
<title>Auberge l a R i p a i l l e < / t i t l e >
/ Symbole Hôtel
<desc>, rue de Buade</desc>
</path>
. . . . • • • •
• • •
^
x="331737" y="5186796" width="25"
••** stroke="rgb(0,0,0) " £ill="rgb(255, 255, 255)"
width="3">
*
«
\
</rect>
.*
*•« <text x="331637" y="5186696" font-family=»Arial" font.-»*
*si«aft="20" fill = »black">H</text>
••**
<path d= "M 33148Ï.'6VS•
331489.09375,
331484.875,5186762.875 z" fill="blue">
<title>Restaurant 'Le Baillairgé
<desc>57, rue Sainte-Anne</desc>
Symbole restaurant
</path>
^
•"
" y="5186762" width="25" *•••...
^.•***height=»25»stroke="rgb (0,0,0)» f ill = "rgb (255, 2*95.,,
.**
255)" stroke-width="3">
*
V
</rect>
^
***..# <text x="-28" y="-214" £ont-£amilyi="Arial" font.'»»**
''"&à,z$=<;20" fill="black">R</text>
...•••"****
<path d="
331651.5,5186769.5 331651.40625,5186770.625
331659.40625,5186768.75 z"
fill = "rgb(255, 255, 224) ">
<title>Musee de cire</title>
<desc>22, rue Sainte-Anne</desc>
</ p a t h > #....•••••"•""
"
""""•*"••••.«
<ç0ot**x=""331659» y="5186768" width=»25" height= ftl 2 l 3» t ... >
^••**stroke="rgb ( 0 , 0 , 0 ) " f i l l = " r g b (255, 2 5 5 , 2 5 5 ) " stroke-***%
/
width="3»x/rect>
*••, <text x=»331659» y="5186768" f o n t - f a m i l y = " A r i a l "
y
**»«flnt-size="20" £ i l l = "black">M</text>
*
</g>
</g>
< /g >
•••••••.....
. . . .
Symbole Musée
§n
98
Annexe D : Caractéristique technique du PDA utilisé
n i r i i i i v ^ r ^ i ! , , , il-» h555Q_
Intel PXA250 400 MHz
•
•
48 Mo
Processeur
ROM
.... .
ATticnage
|
3.8" matrice active TFT- transflectif -16 bits (64 000
résolution 240*320
cou|eurs)
Écran tactile, touche de navigation 5 directions, stylet
Interfaces
l'oii USlï, ' loi SI), puii itiirarnitn ,
L
Connectivité sans fil
rîrDÀTBiuetootli, IEEE 802.11b
Alimentation secteur 110/230 V ( 50/60 Hz ), deux
Alimentation
Système d'exploitation
Microsoft Windows Mobile 2003 pour Pocket PC
Applications et logiciels de
base
Pocket Internet Explorer, Pocket Excel, Pocket Word,
Solitaire, Infrared Beaming, Microsoft ActiveSync,
Windows Media Player for Pocket PC, Microsoft
Reader, etc.
Synchronisation
Câble USB pour la synchronisation (connexion avec un
PC)