Des 2006 Masters Thesis

Universit Libre de Bruxelles Facult des Sciences Appliques Service Informatique et Rseaux
Anne acadmique 2005-2006
Conception et ralisation d'une plateforme de dploiement de services golocaliss
Directeur de Mmoire : Esteban Zimnyi
Mmoire de n d'tudes prsent par Patrick DESSALLE en vue de l'obtention du grade d'Ingnieur Civil Informaticien.
Remerciements
Je remercie d'abord mon promoteur Esteban Zimnyi pour l'aide, le soutien et la disponibilit dont il a fait preuve tout au long de l'anne. Je tiens galement remercier Jean-Michel Dricot et Serge Boucher pour leurs conseils et leurs ides fournies au premier semestre. Je remercie nalement ma famille, mes amis et mon frre qui a pris le temps de relire et de me conseiller dans la rdaction de ce rapport.
Table des matires

Table des matires Table des gures 1 Introduction
1.1 1.2 1.3 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectifs du mmoire . . . . . . . . . . . . . . . . . . . . . . . Organisation du rapport de mmoire . . . . . . . . . . . . . .
ii v 1
1 1 2
2 Services golocaliss
2.1 2.2 2.3 2.4 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vue gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemples de services golocaliss 2.4.1 2.4.2 2.4.3 2.5 2.5.1 2.5.2 2.5.3 2.6 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7 2.7.1 2.7.2 2.7.3 2.7.4 2.7.5 . . . . . . . . . . . . . . . . Types de services . . . . . . . . . . . . . . . . . . . . . . . . . Push et Pull . . . . . . . . . . . . . . . . . . . . . . . . Positionnement de personnes et d'appareils . . . . . . Services dirents selon la position . . . . . . . . . . . Vie prive . . . . . . . . . . . . . . . . . . . . . . . . . Spamming . . . . . . . . . . . . . . . . . . . . . . . . . Surfacturation . . . . . . . . . . . . . . . . . . . . . .
3
3 3 5 6 6 7 7 7 7 8 8 8 8 10 13 14 15 15 16 16 17 17 17
Dangers et abus . . . . . . . . . . . . . . . . . . . . . . . . . .
Mthodes de positionnement . . . . . . . . . . . . . . . . . . . Positionnement satellitaire . . . . . . . . . . . . . . . . Rseaux cellulaires . . . . . . . . . . . . . . . . . . . . Positionnement indoor . . . . . . . . . . . . . . . . . . Positionnement par WiFi . . . . . . . . . . . . . . . . Positionnement sur Internet . . . . . . . . . . . . . . . Localisation par GSM - GeoMobile.be Localisation par WiFi - HereCast.com . . . . . . . . . . . . . . . . . . . . . . . . .
Etat de l'art . . . . . . . . . . . . . . . . . . . . . . . . . . . . Plateformes golocalises - RedSpider LOBOS . . . . . Localisation par IP - Windows Local Live
Qui seront les futurs acteurs ? . . . . . . . . . . . . . .
ii
TABLE DES MATIRES
2.8
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3 Les donnes spatiales

3.1 3.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reprsentation d'une position . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 3.2.3 3.3 3.3.1 3.3.2 3.4 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.5 3.6 Godsie . . . . . . . . . . . . . . . . . . . . . . . . . . Projections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Calcul de distance
20
20 21 21 23 25 26 26 30 31 31 35 35 35 36 36 36 36
Open Geospatial Consortium
Donnes spatiales : OGC . . . . . . . . . . . . . . . . . Autres recommandations de l'OGC . . . . . . . . . . . Structure OpenGIS . . . . . . . . . . . . . . . . . . . . MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . Oracle 10g . . . . . . . . . . . . . . . . . . . . . . . . . DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . Middleware . . . . . . . . . . . . . . . . . . . . . . . .
Les bases de donnes spatiales . . . . . . . . . . . . . . . . . .
Cration et manipulation de donnes spatiales . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Choix prliminaires
4.1 4.2 4.3 4.4 4.5 4.6 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scnario de base Spcications . . . . . . . . . . . . . . . . . . . . . . . . . Modlisation du scnario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Choix de l'architecture . . . . . . . . . . . . . . . . . . . . . . Technologies choisies . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 4.6.2 4.6.3 4.6.4 4.6.5 4.6.6 4.6.7 4.6.8 4.6.9 4.7 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . Java Standard Edition . . . . . . . . . . . . . . . . . . Java Enterprise Edition Serveurs applicatifs J2EE GeoTools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enterprise Java Bean . . . . . . . . . . . . . . . . . . . XDoclet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PostGIS . . . . . . . . . . . . . . . . . . . . . . . . . . Eclipse et JBoss IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
37 37 38 39 40 41 41 41 42 44 48 49 50 50 51 51 52
4.6.10 phpPgAdmin
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Implmentation
5.1 5.2 5.3 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . Suppositions . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jeu de donnes . . . . . . . . . . . . . . . . . . . . . . . . . .
54
54 55 56
iii
TABLE DES MATIRES
5.3.1 5.3.2 5.4 5.5
Le jeu de donnes Spearsh . . . . . . . . . . . . . . . Le jeu de donnes Frida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56 57 58 61 61 61 62 62 62 62 63 63 64 64 65 65 67 68 70 71 71 72 72 72 72 72
MapViewer 5.5.1 5.5.2
Vision gnrale
Client - Serveur . . . . . . . . . . . . . . . . . . . . . . Elments de la plateforme . . . . . . . . . . . . . . . . Session . . . . . . . . . . . . . . . . . . . . . . . . . . . Services avec ou sans identication . . . . . . . . . . . Souscription payante aux services . . . . . . . . . . . . Services en cascade . . . . . . . . . . . . . . . . . . . . La super-classe ServiceBean . . . . . . . . . . . . . . . HistoryBean . . . . . . . . . . . . . . . . . . . . . . . . Achage de cartes . . . . . . . . . . . . . . . . . . . . Structure du code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le package mfe.silas.lbs
5.6
Middleware J2EE . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 5.6.2 5.6.3 5.6.4 5.6.5 5.6.6 5.6.7 5.6.8 5.6.9
5.6.10 Le package mfe.silas.utils 5.7 Le client SilasTalker 5.7.1 5.7.2 5.7.3 5.8 5.9 couche logique
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
couche graphique . . . . . . . . . . . . . . . . . . . . . Le systme de plugins pour les services . . . . . . . . .
Packages pour dveloppeurs . . . . . . . . . . . . . . . . . . . Amliorations . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.9.1 5.9.2 5.9.3 Web Services Poisoning . . . . . . . . . . . . . . . . . . . . . . . Cartes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Ralisation du scnario
6.1 6.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . GeoMail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 6.2.2 6.2.3 6.3 6.4 PostMessage . . . . . . . . . . . . . . . . . . . . . . . GetMessage . . . . . . . . . . . . . . . . . . . . . . . . Client GeoMail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
74 74 74 75 75 75 76 76 76 77
FriendFinder 6.4.1 6.4.2
Exemples de code . . . . . . . . . . . . . . . . . . . . . . . . . Utiliser les mthodes de ServiceBean . . . . . . . . . . Crer une carte . . . . . . . . . . . . . . . . . . . . . .
6.5
Scnario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Conclusion Bibliographie
79 80
iv
TABLE DES MATIRES
Annexes
A Grammaires WKT
A.1 A.2 WKT pour les types spatiaux . . . . . . . . . . . . . . . . . . WKT pour les systmes de rfrences spatiaux . . . . . . . .
84
84
84 85
B Calcul de distance de Vincenty C Utilisation de PostGIS

C.1 C.2 C.3 C.4 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation de PostGIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . Crer une base de donnes spatiale C.4.1 C.4.2 Crer une table spatiale . . . . . . . . . . . . . . . . .
87 88
88 88 89 89 89 90
Crer une vue spatiale . . . . . . . . . . . . . . . . . .
D Eclipse et JBoss
D.1 D.2 JBoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
91 91
Table des gures

2.1 2.2 2.3 2.4 2.5 2.6 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 Architecture LBS. . . . . . . . . . . . . . . . . . . . . . . . . 4 10 11 12 13 14 21 22 23 24 25 25 26 26 27 27 28 29 32 38 45 46 51 52 57 58 59 60 Tlphone dans une cellule . . . . . . . . . . . . . . . . . . . . Positionnement par Timing Advance [22] . . . . . . . . . . . . Positionnement par Time of Arrival [22] . . . . . . . . . . . . Positionnement par Angle of Arrival [22] . . . . . . . . . . . . Positionnement par E-OTD [22] . . . . . . . . . . . . . . . . . Gode, sphre et ellipsode Datums locaux . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
Projection cylindrique rgulire, transverse et oblique [19]
Zones UTM de la France et de la Belgique . . . . . . . . . . . Projections coniques [19] . . . . . . . . . . . . . . . . . . . . . Projections pseudo-cylindrique interrompue [19] . . . . . . . . Projection azimuthale et de Winkel [19] . . . . . . . . . . . . Projection Armadillo sur un tore [19] . . . . . . . . . . . . . . LineString simple et ouverte ; LineString simple et ferme (LinearRing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10 LineString non simple et ouverte ; LineString non simple et ferme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11 Schma UML des donnes spatiales OGC . . . . . . . . . . . 3.12 Reprsentation WKT de la projection UTM 30 Nord avec un gode WGS 84 . . . . . . . . . . . . . . . . . . . . . . . . . . 3.13 Structure des tables SQL OGC 4.1 4.2 4.3 4.4 4.5 5.1 5.2 5.3 5.4 ShoutSpace . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Concurrence sans contrle . . . . . . . . . . . . . . . . . . . . Concurrence avec contrle . . . . . . . . . . . . . . . . . . . . Intgration de JBoss dans Eclipse (1) . . . . . . . . . . . . . . Intgration de JBoss dans Eclipse (2) . . . . . . . . . . . . . . Extrait du jeu de donnes Spearsh . . . . . . . . . . . . . . . Le jeu de donnes Frida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagramme UML simpli de MapViewer
Slection des couches dans MapViewer . . . . . . . . . . . . .
vi
TABLE DES FIGURES
5.5 5.6 5.7 5.8 5.9
Schma UML simpli de l'architecture de Silas . . . . . . . . Carte et position de l'utilisateur dans SilasTalker . . . . . . . Structure des packages du serveur Silas . . . . . . . . . . . . . Structure du package mfe.silas.lbs . . . . . . . . . . . . . . . . Diagramme UML du client SilasTalker . . . . . . . . . . . . .
61 64 65 66 69 73 77 78 78 78
5.10 Systme de dcoupage pour les cartes . . . . . . . . . . . . . . 6.1 6.2 6.3 6.4 Alice lance SilasTalker et se connecte . . . . . . . . . . . . . . Alice lance ServiceFinder et slectionne FriendFinder. . . . . Alice voit Bob et sa position et lui envoie un message . . . . . Bob reoit le message d'Alice. . . . . . . . . . . . . . . . . . .
vii
Chapitre 1
Introduction
1.1 Contexte
Depuis quelques annes, les appareils mobiles se multiplient et deviennent la fois plus lgers et plus puissants. Les GSM contiennent de plus en plus de possibilits multimdia (photo, son, vido, ...), augmentent leur capacit mmoire et leur puissance de calculs. Les PDA peuvent tre branchs des rcepteurs GPS ou contiennent directement la puce de rception GPS. Les voitures sont capables de capter les signaux GPS mais aussi d'accueillir des tlphones. Chacun de ces appareils a des caractristiques direntes que ce soit par la vitesse d'accs Internet, la capacit de mmoire et de calcul ou la prcision du positionnement. Mais on peut raisonnablement miser sur la gnralisation prochaine d'appareils connects un rseau (Internet, GSM, UMTS, WiFi, ...) capables de connatre leur position. L'expression services golocaliss (en anglais, LBS pour Location-Based Services ) regroupe l'ensemble des services bass sur la position gographique de l'utilisateur. Il existe plusieurs moyens de connatre, avec plus ou moins de prcision, la position d'un appareil. Cela peut se faire au moyen des satellites GPS qui gravitent autour de la Terre ou l'aide des cellules des rseaux GSM ou encore des points d'accs du WiFi. Cette prcision va en s'amliorant grce l'augmentation de la densit des rseaux cellulaires, le lancement de nouvelles constellations de satellites comme dans le projet Galileo et l'intgration de techniques de localisation dans les protocoles Internet. Tous ces systmes permettront tout un chacun de facilement connatre sa position et ainsi d'utiliser des services golocaliss.
1.2 Objectifs du mmoire

Dans ce mmoire, nous allons identier les dirents types de services qui peuvent tre dploys sur une plateforme golocalise. Nous allons analyser
CHAPITRE 1. INTRODUCTION
les besoins communs de ces services et dterminer un ensemble de composants rutilisables pour construire plus facilement de tels services. Un scnario sera ensuite choisi pour crer un premier service sur base de ces composants de base et d'outils supplmentaires. Par la suite, une plateforme sera dveloppe et on y dploiera le service correspondant au scnario an de valider la conception. Un client capable de dcouvrir les services, d'mettre des requtes et d'acher les rsultats sera galement dvelopp. La cration d'un ensemble de composants rutilisables du ct client et du ct serveur pour le dploiement de services golocaliss a pour but de simplier au maximum le travail des dveloppeurs de services.
1.3 Organisation du rapport de mmoire

Le rapport commence par une introduction aux direntes notions relatives aux services golocaliss. On y expose les direntes catgorisations possibles de ces services et on y donne des exemples de services existants ou imaginables. Direntes mthodes de positionnement d'un utilisateur sont galement introduites suivies par un tat de l'art montrant des exemples d'exploitation de ces techniques. Le chapitre 3 s'intresse la reprsentation des positions. Aprs une courte explication des modles de la Terre et des projections principalement utilises l'heure actuelle, nous introduisons le modle de donnes spatiales tabli par l'OGC. L'OGC ou Open Geospatial Consortium est une initiative internationale regroupant des agences gouvernementales, des entreprises prives et des universits pour tablir des standards sur les donnes spatiales et la communication entre applications exploitant ces donnes. Le modle de l'OGC spcique aux bases de donnes spatiales est ensuite prsent, suivi par une description des dirents acteurs sur le march des bases de donnes spatiales. Le chapitre 4 s'attarde plus particulirement sur les besoins technologiques des services golocaliss et les choix technologiques que nous avons pris. A ct de la justication des technologies, nous dtaillons les particularits utiles au dveloppement de notre plateforme. Le chapitre suivant contient les dtails des fonctionalits, de la conception et de l'implmentation du serveur, du client et du logiciel de visualisation des donnes. Les dtails de l'implmentation de notre scnario et des exemples de code permettant d'utiliser la plateforme sont exposes dans le chapitre 6. Pour nir, le chapitre 7 contient la conclusion de ce mmoire.
Chapitre 2
Services golocaliss
2.1 Introduction
Ce chapitre a pour but de donner une vision gnrale des services golocaliss (galement appels LBS pour
Location-Based Services ). On va commen-
cer par y dcrire l'architecture classique des LBS avec les dirents lments ncessaires an d'assurer leur bon fonctionnement. Ensuite, on va donner des exemples de services golocaliss, les direntes catgories dans lesquels on peut les classer et les besoins qui en dcoulent. Nous aborderons galement les ventuels abus relatifs une connaissance constante de la position des utilisateurs. Une solution ces abus doit tre trouve an de permettre au grand public de faire conance aux services golocalis. C'est probablement le principal obstacle pour l'adoption en masse de ces services. Nous allons ensuite lister les moyens les plus courants de positionner un appareil mobile. Cette connaissance peut tre du ct de l'appareil luimme ou bien tre uniquement connue du rseau auquel il est connect. Nous allons galement parler des techniques existantes pour amliorer la prcision du positionnement et aborderons les techniques de positionnement des ordinateurs bases sur leur adresse IP. Dirents services existants bass sur ces dirents moyens de localisation seront illustrs dans l'tat de l'art. Nous en proterons galement pour identier les probables futurs grands acteurs des services golocaliss.
2.2 Vue gnrale

L'infrastructure globale ncessaire pour le bon fonctionnement d'un service golocalis est compose de dirents lments : l'appareil de l'utilisateur, un lment de localisation, une plateforme, des bases de donnes et les services eux-mmes. Les utilisateurs utilisent un appareil (par exemple un tlphone mobile, un PDA, un ordinateur portable, . . .) an d'accder aux services proposs
CHAPITRE 2. SERVICES GOLOCALISS
Fig. 2.1 Architecture LBS.
par la plateforme de services golocaliss. La position de l'utilisateur est calcule au moyen d'un lment de localisation. Cet lment de localisation peut tre situ du ct client ou du ct du rseau. Du ct client, on retrouve par exemple les rcepteurs GPS, qui peuvent tre directement intgrs dans l'appareil. Du ct rseau, on retrouve entre autres les techniques de positionnement des GSM. En eet les GSM actuels peuvent tre approximativement localiss au moyen des stations de base du rseau GSM. L'utilisateur nal n'a alors pas connaissance de sa position. La plateforme est une application tournant sur un serveur et a pour but de faciliter l'accs aux donnes spatiales au travers de dirents outils. Elle permet galement de reprendre une partie de la complexit de la logique mtier du service golocalis. Globalement, la plateforme et le service golocalis travaillent ensemble an de simplier au maximum les besoins du ct client. Cela permet de diminuer la puissance de calcul ainsi que la bande passante ncessaire au bon fonctionnement du service. La plateforme permet de mettre disposition de l'utilisateur les services golocaliss situs sur la plateforme. Sur base de sa position et d'autres donnes annexes ventuellement ncessaires (direction, vitesse, lieu de destination, . . .), la plateforme communique avec des bases de donnes et ore des outils aux services golocaliss. Ceux-ci eectuent la logique mtier an de renvoyer l'utilisateur la rponse sa requte. Les donnes renvoyes par les services golocaliss peuvent tre de tout type : la liste des restaurants italiens les plus proches, une carte des rues avoisinantes, le meilleur itinraire pour rejoindre un autre endroit, un enregistrement audio ou vido d'informations touristiques sur l'endroit visit, . . . Le client communique avec le fournisseur de services au travers d'un rseau (Internet, rseaux GSM d'un oprateur, rseau WiFi dans une entre-
prise, . . .). Comme on peut le remarquer, dans ces dirents types de rseaux, les services golocaliss peuvent tre limits un certain groupe de personnes (les clients d'un oprateur GSM) ou aux personnes dans une rgion gographique limite (les employs dans un btiment ou dans une usine). On peut bien sr aussi dployer des services golocaliss l'chelle mondiale grce Internet ou nationale avec les oprateurs GSM.
2.3 Exemples de services golocaliss

Pour donner une ide plus claire de ce que l'on considre comme tant un service golocalis, nous allons introduire les grandes familles de services que l'on peut imaginer. Il faut noter que cette liste n'est pas exhaustive. Le tracking de marchandises, de ottes de camions, de taxis, . . .est gnralement considr comme une des applications majeures des services golocaliss car ils ont une utilit industrielle. En eet, ils peuvent amliorer les rendements en fournissant des informations comme l'avertissement de retards de livraison. Ils permettent aussi d'optimiser l'usage d'une otte de taxis. Ce genre de services est dj mis en uvre dans de nombreuses socits comme les Taxis Verts Bruxelles. On peut galement faire du tracking de personnes. Certains parents pourraient vouloir connatre tout moment o se trouve leur enfant ou tre avertis quand il quitte l'enceinte de l'cole. Le tracking de personnes soulve cependant des questions de respect de la vie prive. Les informations gnrales par rapport au lieu o l'on se trouve sont des services ayant une forte valeur ajoute. Dans cette catgorie on retrouve par exemple un service permettant de rechercher l'ensemble des restaurants selon des critres (prix, style, . . .) dans un rayon donn autour de l'utilisateur. Les services lis la scurit sont galement une application possible pour les services golocaliss. Certaines voitures pourraient tre quipes d'un systme de positionnement capable d'appeler une ambulance et de donner la position prcise du vhicule en cas de problme. Mais cette catgorie regroupe galement des informations d'intrt gnral, comme l'avertissement de personnes prsentes dans une certaine zone qu'ils doivent vacuer aprs un feu ou une explosion. Les services de communication sont une autre application des services golocaliss. Dans la ligne des services de messageries instantans, on localise et communique avec des connaissances situes dans une mme zone gographique. Les divertissements sont une des possibilits pour l'adoption massive des services golocaliss par le grand public. Des jeux grandeur nature comme des chasses au trsor peuvent tre mis en uvre l'aide de
services golocaliss. Finalement, la publicit est vue comme une des industries majeures pouvant tirer parti des services golocaliss. On pourrait demander la liste de magasins environnants qui font des promotions ou tre avertis des produits en promotion lorsque l'on rentre dans un magasin. En plus du tracking de marchandises, la localisation de tlphones mobiles est galement vue comme une des motivations dvelopper des services golocaliss. La Federal Communication Commission (l'organe amricain de rgulation des communications, un peu comme l'IBPT belge) a exig que les oprateurs de rseaux GSM amricains puissent positionner leurs utilisateurs dans un rayon de 125 mtres an de faciliter le travail des services d'urgence. Cette rgulation a pouss au dveloppement de ces systmes de localisation mais a fait galement rchir aux possibilits des services golocaliss. Dsormais, les tlphones cellulaires vendus aux USA ont un systme de localisation intgr que ce soit grce une puce GPS ou grce une des mthodes de positionnement expliques dans le point 2.6.
2.4 Types de services

2.4.1 Push et Pull
On peut classer les services golocaliss selon la manire d'accder l'information. Les applications de type pull qui, comme leur nom anglais l'indique, consistent rcuprer des informations golocalises depuis le serveur la demande du client. C'est donc l'utilisateur qui initie le transfert d'informations depuis le serveur. Les applications du type push envoient des informations au client sans qu'il en fasse la demande explicite, par exemple lorsqu'il arrive dans une certaine zone gographique. Cependant, dans les applications de type push, an que le serveur connaisse de manire constante la position de l'utilisateur, il est ncessaire que celui-ci mette rgulirement jour sa position. De plus, pour que tous les utilisateurs d'une rgion reoivent un message, il faut qu' intervalle de temps rgulier, le systme rcupre les utilisateurs dans une rgion et leur envoie un certain message. Les cots en bande passante (communications entre les clients ou entre la plateforme et les services) et en puissance de calcul (calcul rgulier de la distance des utilisateurs par rapport une certaine zone) sont plus importants que les services de type pull. C'est pourquoi, il n'est pas encore trs clair si ce genre de services est conomiquement rentables [18]. Parmi les exemples cits dans le point 2.3, les services du type push sont l'avertissement des enfants quittant leur cole, la publicit quand on rentre dans un magasin ou encore les alertes d'incendies.
2.4.2 Positionnement de personnes et d'appareils

Dans les services golocaliss, on peut vouloir localiser soit des objets, soit des personnes. La localisation d'un objet se fait en localisant un appareil golocalisable coupl l'objet. Par exemple dans le cas de tracking de marchandises, on ne s'intresse pas savoir o se trouve le chaueur mais bien o se trouve le camion puisque la personne qui conduit le camion n'est pas pertinent pour un tel systme. De manire similaire, dans un systme de localisation de voiture, gnralement utilis pour retrouver une voiture vole, ce n'est pas le conducteur dont on souhaite connatre la position mais bien le vhicule. La localisation d'un appareil peut correspondre une personne mais ce n'est pas une obligation. Dans le cas de la localisation de personnes, on souhaite connatre la position d'une personne en particulier et celle-ci garde gnralement un certain contrle sur cette localisation en ayant la possibilit de ne pas faire connatre sa position. Cette notion est galement utile si on imagine qu'une personne peut possder plusieurs appareils de positionnement et que par exemple, il en oublie un. Il faudra dans ce cas tre capable de localiser la personne et non pas les appareils qui donneront des localisations direntes.
2.4.3 Services dirents selon la position

Une utilit des services golocaliss est la capacit d'orir des services dirents en fonction de la position de l'utilisateur ou de lui fournir des donnes direntes en fonction de cette position. Dans une usine d'assemblage de voitures, la personne contrlant la qualit peut, grce de tels services golocaliss, obtenir automatiquement des statistiques sur les direntes tapes de la chane de production. Il ne doit pas prciser quelle tape il est en train d'inspecter puisque sa position dans l'usine permet de conclure ce qu'il inspecte. Dans un muse, un visiteur pourrait automatiquement recevoir des informations sur l'uvre d'art qu'il a devant soi.
2.5 Dangers et abus

2.5.1 Vie prive
Une des grandes craintes des services golocaliss est l'atteinte la vie prive. Le fait de communiquer sa position peut tre rutilis des ns commerciales ou dans un tat policier. An de limiter ce risque, il faut donner l'utilisateur un maximum de contrle sur la transmission de donnes ainsi que des garanties lgales par rapport l'utilisation, la manipulation et la revente des donnes stockes lors de l'utilisation de tels services.
2.5.2 Spamming
Une autre grande crainte des services golocaliss est l'apparition d'une nouvelle forme de spam. En eet, des messages publicitaires non sollicits pourraient tre envoys de manire intempestive aux utilisateurs lorsqu'ils arrivent dans une certaine zone. Si on imagine que dans une galerie commerante tous les magasins dcident d'avertir les passants des promotions en cours, on comprend facilement qu'il faut imposer une certaine forme de limitation. Ce problme est assez compliqu rsoudre comme on peut le remarquer avec Internet. L'idal serait probablement d'imposer l'opt-in c'est--dire l'autorisation pralable de l'utilisateur avant de lui envoyer un message ( l'exception de messages comme des avertissements d'incendie).
2.5.3 Surfacturation
La question de la facture reste ouverte. Chaque service et chaque fournisseur de plateforme golocalise sera probablement libre de facturer comme bon lui semble. En examinant la situation actuelle des services par SMS, on peut prdire qu'ici aussi il est possible d'avoir des problmes de surfacturation. Par exemple, des socits mal intentionnes pourraient envoyer des messages push payant non sollicits. Comme pour les services par SMS, la communication sur les tarifs de l'utilisation des dirents services doit tre claire an d'viter de mauvaises surprises lors de la rception de la facture.
2.6 Mthodes de positionnement

2.6.1 Positionnement satellitaire
Le systme GPS
Le systme GPS (Global Positionning System) est probablement le systme de localisation le plus connu et le plus utilis par le grand public. Dvelopp par le dpartement de la dfense amricain pour un usage exclusivement militaire, il utilise une constellation de 24 satellites en orbite autour de notre plante. Trois satellites supplmentaires sont prvus en cas de panne parmi les 24 principaux. En 1984, un avion de la compagnie nationale corenne s'est cras d l'imprcision des systmes de navigation. Pour viter qu'une telle catastrophe ne se reproduise, le prsident Reagan dcida d'ouvrir gratuitement le GPS des utilisations civiles avec une prcision limite par un brouillage du signal. En l'an 2000, le prsident Clinton a toutefois lev cette limitation, ce qui permet d'atteindre une prcision de 3 15 mtres. Il est tout de mme possible aux Amricains de ractiver le brouillage sur une rgion donne s'ils le jugent ncessaire.
Le principe d'un GPS [10] est le suivant : un code pseudo-alatoire est envoy par chaque satellite GPS. Le rcepteur GPS reoit un signal provenant de chaque satellite qu'il arrive percevoir et calcule la distance qui le spare de ces satellites. Chaque distance permet de placer le rcepteur sur une sphre centre sur le satellite. En utilisant trois satellites, on obtient ainsi deux points, dont un est limin car situ trop loin de la Terre ou se dplaant une vitesse irraliste. Pour connatre la position du satellite, chaque rcepteur GPS possde une table contenant la position des dirents satellites. An de pouvoir faire cette triangulation, il faut eectuer un calcul prcis de la distance entre le satellite et le rcepteur. Ce calcul est possible grce la mesure du temps que met le signal pour arriver au rcepteur GPS. Comme les ondes lectromagntique se dplacent la vitesse de la lumire, il est ncessaire d'avoir un signal d'horloge trs prcis. Chaque satellite GPS possde donc quatre horloges atomiques synchroniss un temps universel standard. L'information sur le temps ainsi qu'une correction de la position du satellite par rapport sa position thorique sont inclues dans chaque signal envoy par le satellite GPS. Un autre avantage est que ce signal peut-tre utilis par un rcepteur xe pour avoir une horloge de prcision atomique un cot rduit.
Systmes concurrents
D'autres nations ont dvelopp des systmes similaires. C'est le cas de l'Union Europenne avec le systme Galileo qui permettra d'obtenir une meilleur prcision (moins de 4 mtres) dans sa version gratuite. Des prcisions plus pousses sont possibles dans la version payante du service. La Russie possde GLONASS, un systme limit (8 satellites, prcision 70 mtres) et la Chine possde son propre systme restreint l'Asie.
Amliorations
La prcision des systmes de positionnement par satellites est dgrade par plusieurs facteurs comme les interfrences atmosphrique, le feuillage des arbres en fort dense ou encore les gratte-ciels qui gnent la rception des signaux. Pour compenser les interfrences de l'atmosphre et an d'amliorer la prcision des donnes reues par GPS, le systme DGPS (Dierential GPS) est utilis entre autre par les garde-ctes amricains [10]. Il consiste dployer des rcepteurs GPS xes des endroits dont la position exacte est connue. Ils peuvent ainsi calculer l'erreur entre leur position relle et la position calcule par leur rcepteur GPS et ensuite la diuser par ondes radios. Les signaux de correction sont gracieusement accessibles tous et utiliss, par exemple, par les bteaux s'approchant des ctes. Le Japon dveloppe de son ct Quasi-Zenith, un systme hybride qui a
Fig. 2.2 Tlphone dans une cellule
pour objectif de rpondre aux problmes de la visibilit des satellites GPS dans les villes comme Tokyo o les gratte-ciels gnent la visibilit en permettant de donner l'impression de constamment avoir les signaux venant verticalement (d'o le nom Quasi-Zenith).
2.6.2 Rseaux cellulaires

Le positionnement bas sur la tlphonie mobile a l'avantage du taux de pntration dj important des rseaux GSM. Presque tout le monde possde dj un GSM et est donc potentiellement capable d'accder des services golocaliss bass sur leur GSM. De plus, les rseaux GSM recouvrent la majorit des zones du globe o les services golocaliss sont utiles (c'est-dire principalement les zones forte densit de population). Finalement, les GSM sont peu coteux et la plupart des systmes de positionnement de tlphones mobiles ne ncessitent aucune adaptation du ct du client puisqu'ils sont exclusivement raliss par le rseau. On peut donc dployer un systme golocalis partir de n'importe quel appareil connect au rseau GSM, mme un appareil ancien. Cette section est principalement base sur [22] et [10].
Cell ID
Les rseaux cellulaires comme ceux utiliss par le GSM ou l'UMTS utilisent un maillage compos d'un ensemble de cellules au centre desquelles
10
Fig. 2.3 Positionnement par Timing Advance [22]
sont places les antennes GSM (ou UMTS). La taille de ces cellules dpend de la densit des utilisateurs et de leur besoin de communiquer. Moins il y a d'abonns en train d'appeler par
km2 ,
moins il faut d'antennes pour cou-
vrir une zone. La cellule sera alors trs grande. Si le nombre d'abonns est grand, ce qui est le cas typique des zones urbaines, on retrouvera un grand nombre d'antennes GSM et les cellules seront typiquement plus petites. Ce systme manque donc de prcision dans les zones rurales (jusqu' 35 kilomtres) et n'atteint par la prcision du GPS dans les zones urbaines (au mieux 200 mtres). Cependant, il a un certain nombre d'avantages. Premirement, la cellule GSM dans laquelle se trouve un appareil mobile est une information qui est dj stocke pour assurer le bon fonctionnement d'un rseau GSM. Pour connatre la cellule, il sut donc d'aller consulter la base de donne centrale du rseau. Ce qui implique que sa mise en place n'est pas coteuse. Le rseau GSM voluant constamment, de nouvelles antennes GSM sont rgulirement installes pour absorber l'augmentation du trac GSM. La prcision va donc en augmentant. Les rseaux UMTS utilisent une architecture en cellules similaire mais possdent des cellules plus petites ce qui permet une prcision accrue. Dj dploys dans certaines zones urbaines, ils ne seront toutefois disponibles partout en Belgique que dans quelques annes.
Timing Advance
Cette technique permet, en combinaison avec le Cell ID, d'amlioration la prcision de la localisation. En calculant le temps ncessaire au signal pour atteindre l'antenne GSM
1 la plus proche, on peut positionner le tlphone
Les antennes GSM sont parfois appelles stations de base ou Base Station
11
Fig. 2.4 Positionnement par Time of Arrival [22]
l'intrieur d'un anneau autour de l'antenne. La rsolution ainsi obtenue est de l'ordre de 500 mtres, ce qui rend cette technique plutt utile dans les zones rurales. On ne peut pas positionner exactement le mobile sur un cercle car les ondes ne sont pas assures d'atteindre le mobile en ligne droite, sans obstacle sur son chemin. L'utilisation de cette technique ne ncessite aucune modication dans le GSM ou dans l'infrastructure du rseau mais il est ncessaire d'ajouter une application software dans le rseau.
Time of Arrival (TOA)

Chaque mobile dans un rseau cellulaire est capable de recevoir des signaux provenant de direntes antennes GSM et inversment, plusieurs antennes GSM sont capables de recevoir les informations d'un mobile. Cela est utile lorsque l'utilisateur se dplace et que le rseau doit valuer s'il est ncessaire de faire basculer un utilisateur d'une antenne une autre. En calculant le temps ncessaire un mme signal pour arriver trois ou plus antennes GSM et sachant que les ondes lectromagntiques voyagent la vitesse de la lumire, il est possible de dterminer la position du mobile par triangulation. Les stations de base doivent tre synchronises au moyen d'un signal d'horloge (par exemple grce au GPS) pour un calcul prcis des distances. Les mobiles ne doivent pas tre modis. Ce systme permet d'atteindre des rsolutions de 125 mtres.
Angle of Arrival (AOA)

Cette technique est similaire au TOA mais utilise cette fois la dirence de phase des signaux reus pour calculer l'angle entre l'antenne et le mobile.
12
Fig. 2.5 Positionnement par Angle of Arrival [22]
Un rteau d'antennes spars, par exemple, par une demi-longueur de l'onde utilise par le GSM doit tre install chaque station de base. En comparant les phases reues par les direntes antennes sur le rateau, on peut calculer l'angle d'incidence de l'onde. La prcision ainsi obtenue est de l'ordre de 125 mtres.
E-OTD
Cette technique est similaire au DGPS mais dans les rseaux cellulaires. Un signal est envoy par les stations de base et est reu par le mobile mais aussi par une antenne spciale (LMU) situe une distance xe et connue de chaque station de base. On utilise une des techniques prcdentes (par exemple TOA) entre les stations de base et la LMU pour calculer la distance par triangulation et en tirer un facteur de correction bas sur la distance relle. Le mobile calcule galement sa position par triangulation et amliore la prcision grce au calcul eectu par le LMU. La prcision peut atteindre 25 mtres. Cela ncessite de lourds investissements d'installation de LMU et une modication software des mobiles.
2.6.3 Positionnement indoor

Le positionnement indoor ( l'intrieur des btiments) est utilis pour se positionner l'intrieur des btiments et ncessite une grande prcision. Une des applications est, par exemple, le positionnement l'intrieur d'un muse ou d'un supermarch. Les satellites GPS ne sont gnralement pas visibles l'intrieur des btiments et la prcision du positionnement des rseaux cellulaires n'est pas susante pour positionner un visiteur dans une salle o
13
Fig. 2.6 Positionnement par E-OTD [22]
les uvres sont spares de quelques mtres. D'autres technologies existent pour ce type d'application. Nous pouvons citer des techniques bases sur l'infrarouge (gnralement bloqu par les murs), les ondes radios, l'ultrason (qui a l'avantage de se dplacer moins vite que les ondes lectromagntiques) ou encore le WiFi. Nous n'entrerons pas dans les dtails de ces direntes techniques. Le lecteur intress pourra se rfrer [12] et [18].
2.6.4 Positionnement par WiFi

Le WiFi est une solution qui peut tre utilise pour du positionnement l'intrieur et l'extrieur des btiments. Les Access Point (AP) WiFi
peuvent tre vus comme les antennes du rseau GSM et tout appareil capable de capter le signal d'un Access Point se trouve dans sa cellule. Les techniques du point 2.6.2 peuvent donc tre appliques. L'avantage principal du positionnement par WiFi est qu'il y a dj beaucoup d'AP dans les zones habites, des socits comme Belgacom ou Telenet dploient des hotspots
3 dans les gares, les restaurants ou les stations-service
et il possible de voir les AP de particuliers dans les rues. Si en plus, on a le droit d'utiliser l'Access Point, on peut communiquer avec un rseau et donc utiliser des services golocaliss. La prcision par identication des Access Point connat cependant les mme limitations que le Cell ID (prcision moins bonne que le GPS en ville, prcision mauvaise en campagne). Il faut noter que cette technique ne ncessite pas spcialement d'accder un Ac-
2 3
L'Access Point est l'appareil qui relie les appareils WiFi pour former un rseau sans-l Un hotspot est la zone couverte par un Access Point.
qui peut ensuite tre connect d'autres rseaux comme Internet.
14
cess Point, il sut de pouvoir le reconnatre et de retrouver l'identit unique de l'AP dans une base de donnes.
2.6.5 Positionnement sur Internet

Une autre technique utilise depuis longtemps pour obtenir un positionnement approximatif consiste donner une position aux routeurs Internet. Lorsqu'un paquet IP se dplace entre les routeurs constituant Internet, on peut supposer que le premier routeur par lequel il passe est gographiquement proche de l'utilisateur. L'IETF a propos en 1996 [9] dans le RFC1876 d'ajouter des informations de golocalisation dans les donnes transportes par les mises jour DNS. A partir de telles informations, il est possible d'identier le pays ou la ville pour les adresses IP sur Internet. Une autre technique consiste demander des visiteurs de sites Web de donner leur localisation et, partir de l, d'analyser les adresse IP et essayer de faire un lien entre les groupes d'adresse IP et les pays ou les villes. C'est l'approche choisie par le logiciel GeoIP dit par la socit MaxWind
4 qui
croise direntes bases de donnes. Les rsultats ainsi obtenus sont assez prcis et peuvent aller jusqu' la commune de l'utilisateur. Une dmonstration est disponible sur la page
http://www.maxmind.com/app/locate_my_ip.
Un certain nombre de programmes utilisent de telles informations an de faire des reprsentations gographiques du dplacement de paquets sur Internet. Un de ces programmes est Xtraceroute sur Linux qui permet de visualiser sur un globe en 3D les routeurs par lesquels passe une commande traceroute . Windows Local Live , le service de cartes de Microsoft permet galement de situer un utilisateur partir de son adresse IP lorsqu'on clique sur Locate Me. Les outils d'analyse de trac sur les sites Web utilisent galement ce genre d'informations. Finalement, l'IPv6 intgre une gestion de la mobilit en cours de nalisation. Le lecteur intress peut se rfrer [6].
2.7 Etat de l'art

Dans cette section nous n'allons pas lister l'ensemble des acteurs du march. En eet, les services golocaliss et les systmes de plateforme existant pour dvelopper des services golocaliss sont nombreux et varis, chacun pour des applications limites. Dans le cas de produits similaires, nous avons choisi de privilgier des solutions disponibles en Belgique
4 5 6
http://www.maxmind.com/app/ip_location
traceroute est un outil d'analyse de rseau qui sert dterminer le chemin pris par
un paquet IP
http://local.live.com
15
2.7.1 Localisation par GSM - GeoMobile.be

GeoMobile.be est un service dit par la PME belge NETiKA Internet & Mobile Solutions [20]. Cette solution se base sur le positionnement des GSM l'aide des Cell ID des rseaux Proximus et Mobistar. GeoMobile est un service destin uniquement aux entreprises, typiquement pour la gestion de ottes de vhicules ou de personnel mobile. Pour viter les problmes d'atteinte de la vie prive exposs au point 2.4.3, le service exige l'autorisation de l'abonn pour que sa position soit consultable. Ce n'est pas un service de LBS qui permet aux utilisateurs des GSM d'obtenir des services mais l'employeur de grer ses employs mobiles. Les principales fonctionnalits de GeoMobile sont de localiser et visualiser la position actuelle et l'historique d'un GSM, calculer des distances, trouver les GSM les plus proches d'un lieu donn et envoyer et recevoir des SMS depuis l'application. Le service est relativement cher, entre autre car, comme dans toute application passant par les oprateurs GSM, ceux-ci en protent pour prendre une commition non ngligeable. Le logiciel cote 250 euros, auxquels il faut ajouter 10 euros mensuel par numro de GSM que l'on souhaite localiser et ensuite environ 30 centimes d'euros par localisation. Un de leurs clients sont les Taxis Verts Bruxelles.
2.7.2 Plateformes golocalises - RedSpider LOBOS

LOBOS est un logiciel dvelopp par la socit Ionic Software base Lige et en Virginie (USA). Il permet de dvelopper des services golocaliss en Java en se basant exclusivement sur les standards de l'OGC (Open Gis Consortium, dcrit plus en dtails au point 3.2.3), le Java et l'XML. Le logiciel inclut un moteur de recherche de lieux, la gnration de cartes, le calcul d'itinraire ainsi qu'une API
7 pour dvelopper des services golocaliss. Pour
dvelopper des clients capables de communiquer avec Lobos, on peut utiliser le logiciel RedSpider StudioLS. Ionic Software arme dvelopper avec LOBOS, l'unique solution respectant totalement l'OLS (OpenGIS Location Service) de l'OGC. Il faut noter qu'Ionic Software fait partie des onze socits ayant rdig les spcications de l'OLG et qu'une partie des autres participants sont des fournisseurs de donnes ou des oprateurs de tlphonie mobile. Il existe galement d'autres socits qui dveloppent des services similaires. On peut citer entre autre le franais Webraska, galement participant la rdaction de l'OLS, qui arme avoir t dploy cinq fois plus que son concurrent le plus proche (qu'il ne cite pas). Il a install ses solutions et
Application Program Interface, c'est dire un ensemble de mthodes rutilisables an
de faciliter le dveloppement de nouveaux logiciels
16
des services (itinraires, recherche des restaurants avoisinants, . . .) sur les smartphones
8 Orange et Vodaphone.
La grande dirence entre Ionic Software et Webraska est qu'Ionic se concentre plutt sur le march des entreprises, la gestion de leurs donnes spatiales et l'interaction entre dirents logiciels tandis que Webraska vise plus les utilisateurs naux en dployant des services en partenariat avec les oprateurs de tlphonie mobile.
2.7.3 Localisation par WiFi - HereCast.com

HereCast est une application de services golocaliss base sur les routeurs WiFi les plus proches. Chaque routeur WiFi met un numro d'identication unique. Comme les Access Point (AP) sont gnralement xes, le logiciel est capable de donner la position approximative de l'utilisateur. La base de donnes des AP est mise jour par les utilisateurs du logiciel. La position n'est pas donne sous forme de coordonnes gographique mais sous forme d'une information textuelle comme par exemple Grand-Place de Bruxelles. L'avantage est que ce type de donnes est plus adapt une utilisation humaine mais il ne permet pas d'avoir des calculs de distance entre les utilisateurs. Au mieux, ce logiciel est capable de dire qu'un autre utilisateur se trouve dans le mme hotspot mais sans pouvoir donner ensuite d'instructions d'itinraire. C'est assez problmatique dans des larges zones couvertes par un seul hotspot mais galement s'il y a de nombreux hotspot qui couvrent de trs petite zones car deux utilisateurs trs proches mais voyant deux AP dirents ne sauront pas se retrouver.
2.7.4 Localisation par IP - Windows Local Live

Windows Local Live est un service de cartes sur Internet dvelopp par Microsoft. Il possde un bouton Locate Me qui peut essayer de trouver la position d'un utilisateur partir d'une liste d'Access Point (comme HereCast) ou bien partir de son adresse IP (avec des bases similaires ce que dveloppe MaxWind). La carte est alors zoome autour de la position de l'utilisateur. Le site tant en version beta, la plupart des fonctionnalits ne sont pas encore au point : Locate Me partir de l'adresse IP ne donne que des rsultats approximatifs ou parfois incorrects pour l'Europe.
2.7.5 Qui seront les futurs acteurs ?

Il est intressant de se poser la question des futurs grands noms des services golocaliss. Il y a plusieurs moyens de devenir un acteur important
Un smartphone est un tlphone mobile possdant des capacits supplmentaires per-
mettant d'avoir tous types de logiciels : calendrier, client e-mail, navigateur Web, jeux, lecteur MP3 et de vidos, . . .
17
dans ce domaine, que ce soit en ayant une position forte sur Internet, dans la tlphonie mobile ou bien en possdant des cartes golocalises dtailles qui sont les donnes incontournables pour dvelopper des services golocaliss.
Fournisseurs de cartes : Navteq, TeleAtlas, . . .
Il existe seule-
ment quelques grandes socits qui possdent des cartes dtailles des grandes villes du monde. Ces donnes sont vitales an de fournir les cartes aux utilisateurs mais cotent trs cher : TeleAtlas a investi 600 millions d'euros en 20 ans [5]. Cependant, aucune de ces socits ne donne l'impression de vouloir jouer un autre rle que celui de fournisseur de donnes. Cela se comprend car la collecte et l'exploitation de ces donnes sont deux domaines sans relle synergie et ils sont srs de proter du boom des services golocaliss sans devoir prendre le risque de dvelopper les services eux-mmes.
Equipementiers GSM : Nokia, Siemens, . . . Les quipementiers

de la tlphonie mobile, que ce soit les constructeurs de terminaux ou les socits qui construisent les infrastructures, peuvent en installant leurs systmes de services golocaliss devenir des acteurs de premier plan.
Les Oprateurs GSM. Beaucoup d'oprateurs de tlphonie mobile

comme Orange, Vodaphone, NTT Docomo, . . .possdent dj quelques services golocaliss. Avec l'arrive de l'UMTS, il faudra fournir toujours plus de services et les services golocaliss font partie des services en cours de dveloppement.
Yahoo !, Google, Microsoft. Les trois grandes socits de l'Internet

ont dj compris l'intrt stratgique de la golocalisation. Chacune a son service de cartes sur Internet et tente d'y intgrer le calcul d'itinraire et la recherche de commerants dans les environs de l'utilisateur. Ils ne semblent cependant pas s'intresser pour l'instant au dveloppement d'applications du type Friend Finder mais il semblerait plus logique pour eux, d'intgrer ce genre de services l'intrieur de leurs clients de messagerie instantane respectifs (Yahoo ! Messenger, Google Talk et Microsoft Live Messenger).
Les PME. Il reste encore de la place pour des socits comme Ionic
Software ou d'autres qui arriveront dvelopper des plateformes et des services de qualit. La complexit et le cot du dveloppement va probablement permettre l'existence de socits spcialises dans ce domaine en tant que sous-traitant de grands groupes ayant un accs direct aux utilisateurs.
2.8 Conclusion
Dans ce chapitre, nous avons expos l'architecture gnrale compose du terminal, de l'lment de localisation, de la plateforme, des services et des
18
bases de donnes. Nous avons montr que les services golocaliss peuvent tre utiliss dans des contextes dirents, que ce soit par le grand public ou dans le cadre d'une entreprise. Nous avons galement abord les dirents types et catgories de services golocaliss existants et imaginables ainsi que quelques grands risques et abus qui leur sont lis. Ensuite, les techniques de positionnement existantes ont t prsentes. Ces direntes technologies peuvent tre utilises de manire combine an d'obtenir une meilleure prcision globale. Les deux moyens de positionnement actuellement les plus utiliss sont le GPS et Cell ID. Le premier car la qualit des rsultats est bonne et son usage est rpandu dans les ordinateurs de bord des voitures. Le second a l'avantage de se baser sur des informations dj stockes dans les rseaux cellulaires existants et sur le fait que presque tout le monde possde un tlphone mobile. Le lancement de Galileo, l'arrive de l'UMTS (qui possde des cellules plus petites et donc un positionnement par Cell ID plus prcis) et la multiplication des Access Point WiFi devraient permettre d'atteindre la couverture, la prcision et le faible cot ncessaires une adoption par le grand public. Dans l'tat de l'art, nous avons vu qu'il existe dj de nombreuses initiatives de services golocaliss mais limits un certain type de clientle, se basant sur une seule technique de localisation et permettant rarement l'intraction entre les utilisateurs.
19
Chapitre 3
Les donnes spatiales

3.1 Introduction
Au l du temps, de nombreuses initiatives ont t lances an de reprsenter les donnes gographiques, gnralement dans l'optique d'une utilisation spcique (cartographie gologique, cartographique maritime, . . .) chacune avec des particularits spciques un domaine donn. Cette reprsentation est divise en la modlisation du globe terrestre et la mthode de projection de ce globe sur un plan. La Terre n'est pas ronde, elle est en fait plus proche d'une ellipse que d'une sphre. Du ct de la projection, l'impossibilit de conserver toutes les proprits gomtriques (comme les aires, les distances, les azimuts, . . .) lors de la projection de la surface du globe sur un plan a engendr direntes mthodes de projection conservant chacune une ou plusieurs de ces proprits. Le choix des proprits importantes pour la projection dpend de l'application utilise par la carte. plusieurs axes de coordonnes ont t construits au l du temps, certains gocentriques mais d'autres ont t dvelopps par des pays dirents an de mieux optimiser l'espace occup par la reprsentation de leur pays sur une carte plane. Ces projections ne sont pas capables de conserver toutes les proprits que l'on retrouve sur la surface du globe (comme les distances, les aires, les azimuts, . . .) mais se concentrent sur l'un ou l'autre aspect en fonction de leur domaine d'application. Les applications informatiques communiquent de plus en plus entre elles, il a donc t ncessaire de dvelopper une reprsentation commune des donnes spatiales pour les direntes applications informatiques utilisant des reprsentations spatiales. Ce travail est eectu par l'Open Geospatial Consortium (OGC) qui dnit galement un ensemble de recommandations pour tout ce qui gravite autour des donnes spatiales. Ce chapitre aborde nalement dirents moteurs de bases de donnes relationnelles qui supportent les donnes spatiales, leurs points forts et leurs
20
CHAPITRE 3. LES DONNES SPATIALES
limitations respectives.
3.2 Reprsentation d'une position

3.2.1 Godsie
La godsie est la discipline qui a pour but de dcrire la forme et les dimensions du globe terrestre. La forme exacte de la Terre est dpendante de nombreux facteurs comme le mouvement des plaques tectoniques, sa rotation autour de son axe, le champ gravitationnel, . . .Ces facteurs impliquent notamment que le niveau de la mer n'est pas constant aux dirents points du globe.
Fig. 3.1 Gode, sphre et ellipsode
La reprsentation de la surface de la Terre partir du niveau de la mer s'appelle un gode. Il correspond une reprsentation de la surface de Terre si l'on prolongeait le niveau de la mer sur les continents sans tenir compte de la pression de l'air et des courants, . . .Le gode est donc une surface quipotentielle thorique correspondant la mer calme, aprs avoir retir l'eet des continents et des montagnes. Le gode ainsi obtenu n'est pas symtrique du fait de la rpartition non uniforme des masses (les rgions froides concentrant la masse). Les connaissances sur la surface de la Terre et ses dimensions voluent avec le temps, principalement grce la multiplication de satellites d'observations. Par consquent, le gode est devenu de plus en plus prcis au fur et mesure de la multiplication de ces connaissances. Il faut galement tenir compte de dirents facteurs comme l'rosion, la drive des continents, . . .qui fait que le modle, aussi prcis soit-il, doit tre corrig dans le temps.
21
Ce gode tant irrgulier, on utilise un ellipsode de rvolution de mme volume pour les modles mathmatiques. Le modle du gode irrgulier est trop complexe pour tre utilis directement en cartographie et sert principalement contrler le modle ellipsodal. Cet ellipsode est parfois aussi appel Datum. A ce Datum correspond galement un systme d'axe, une position et une orientation de l'ellipsode dans l'espace.
WGS 84
Le modle retenu actuellement pour une reprsentation totale du globe est le
WGS 84 pour World Geodesic System 1984, qui a t revu en 2004
et dont la validit court jusqu'en 2010. Ce modle a remplac le WGS 72 et a prot d'avances technologiques importantes dans le domaine des mesures par satellites. C'est un modle gocentrique, c'est dire que le centre de l'ellipsode correspond (environ) au centre de masse de la Terre. Les valeurs des semi-axes sont de 6 378 137.000 et 6 356 752.314 mtres. C'est ce modle du globe qui est utilis dans le GPS.
Autres modles
Il existe encore de nombreux modles, principalement utiliss pour des reprsentations de zones restreintes et des applications ncessitant une prcision locale meilleure que celle fournie par le WGS 84. C'est le cas par exemple du RGF 93 utilis pour des applications prcises en France ; le modle pour les applications courantes restant le WGS 84 [3]. D'autres modles sont encore fort utiliss pour des raisons historiques comme le ED 50 (European Datum 50) dans les cartes marines europennes.
Fig. 3.2 Datums locaux
22
3.2.2 Projections
Une fois que l'on possde un modle du globe terrestre, pour la plupart des applications, il est ncessaire de le projeter sur un plan deux dimensions an de le visualiser sur une carte ou sur un cran d'ordinateur. Ici aussi, il existe de nombreuses techniques qui ont chacune pour but de respecter certaines proprits prsentes la surface de la Terre. On parle de projections conformes si les angles sont prservs, de projections quivalentes si elles conservent les surfaces, de projections quidistantes si elles conservent les distances sur les mridiens. Si aucune de ces proprits est respecte, on parle de projections aphylactiques. Il faut souligner qu'une projection est indpendante d'un modle godsique de la Terre. Chaque projection peut tre utilise en combinaison avec n'importe quel modle de la Terre et inversment.
Projections cylindriques
Les projections cylindriques consistent projeter le globe sur un cylindre le contenant. Elles sont principalement utilises pour reprsenter le monde dans sa globalit ou des rgions le long d'un parallle, un mridien ou une ligne oblique.
Fig. 3.3 Projection cylindrique rgulire, transverse et oblique [19]
Les projections les plus connues sont la projection plan carrs o les mridiens et les parallles restent parallles et forment des carrs entre eux et la projection conforme de Mercator qui possde de grande distortions des aires aux alentours des ples. Dans la projection de Mercator, le Groenland semble avoir une taille similaire celle de l'Amrique du Sud alors qu'en ralit, sa surface n'est qu'un septime de celle de l'Amrique du Sud. La projection la plus utilise avec le modle WGS 84 est la projection UTM pour Universal Transversal Mercator. La surface de la Terre est divise en 60 fuseaux de 6 degrs, formant ainsi 120 zones (en sparant le Nord et le Sud). La Belgique est cheval sur la zone UTM 30 Nord (de 0 6 degrs Est) et UTM 31 Nord (6 12 degrs Est) (gure 3.4). Chaque zone possde ensuite un point de rfrence virtuel partir duquel les points de la zone sont rfrencs. Pour viter d'utiliser des chires ngatifs,
23
Fig. 3.4 Zones UTM de la France et de la Belgique
le point de rfrence est situ 500 km l'ouest du mridien central. Pour les zones de l'hmisphre Sud, le point de rfrence est situ 500 km l'ouest et 10 000 km au Sud de l'quateur. L'unit de base de la projection est le mtre. Cette projection permet de facilement faire des calculs assez prcis de distances l'intrieur d'une zone. Cependant, le calcul de la distance entre des points de zones direntes n'est pas aussi direct. C'est pourquoi, sur des cartes reprsentant une zone cheval entre deux zones, les deux systmes de coordonnes sont reprsents.
Projections coniques
Dans les zones tempres principalement tendues d'est en Ouest (cartes des Etats-Unis, de l'Europe ou de l'Australie), les projections coniques sont prfrables au projections cylindriques [19]. La projection la plus utilise est la projection de Lambert au centre de la gure 3.5.
Autres projections
Il existe encore direntes projections comme les projections pseudocylindriques qui ont, comme les projections cylindriques, les lignes de latitudes parallles et les lignes de longitude espaces de manire gale. Cependant, uniquement le mridien central est droit, les autres sont courbs. Cer-
24
Fig. 3.5 Projections coniques [19]
Fig. 3.6 Projections pseudo-cylindrique interrompue [19]
taines projections sont interrompues pour diminuer les problmes de courbure des mridiens (gure 3.6) [19] . Les projections azimuthales sont des projections sur un plan tangent au globe. Les projections de l'entiret du monde utilisent souvent la projection azimuthale de Winkel. Il existe encore de nombreuses projections comme les projections sur des tores visibles sur la gure 3.8.
3.2.3 Calcul de distance

Le calcul de grandes distances dans le modle ellipsodal WGS 84 se fait gnralement avec la formule de Thaddeus Vincenty [23]. Cette formule a t rcemment valide par des chercheurs australiens [21] qui ont montr qu'elle tait prcise 0,115 mm - ce qui est plutt prcis. Cette formule s'adapte
25
Fig. 3.7 Projection azimuthale et de Winkel [19]
Fig. 3.8 Projection Armadillo sur un tore [19]
la plupart des modles godsiques de la Terre en modiant les paramtres de base. Le dtail de l'algorithme se trouve dans l'annexe B, page 87.
3.3 Open Geospatial Consortium

Pour que les applications informatiques puissent communiquer plus facilement, il a t ncessaire de crer un standard informatique pour les reprsentation de donnes gographiques. C'est le travail auquel s'attle l'OGC (Open Geospatial Consortium, autrefois appel OpenGIS Consortium) qui regroupe des grands noms de l'industrie (Oracle, AutoDesk, Google, NTT, . . .), des agences gouvernementales (ESA, NASA, USGS, OTAN, . . .) et des universits (EPFL, MIT, Harvard, . . .). Ce consortium rige un certain nombre de rgles dans des domaines divers lis la reprsentation gographique, allant des types de donnes jusqu'au moyen de communiquer entre dirents services de cartographie.
3.3.1 Donnes spatiales : OGC

L'OGC a dni des recommandations pour la reprsentation de donnes spatiales. A chaque classe (qui hrite de la classe abstraite pond un systme de rfrence spatial (ex : WGS 84, UTM 12, . . .) compos typiquement des informations caractrisant l'ellipsode, son systme de coordonnes, l'unit utilise ainsi que les facteurs particuliers la projection si le systme de rfrence est une projection. Le systme de rfrence spatial est gnralement abrvi par SRID (Spatial Reference IDentication).
Geometry ) corres-
26
Il y a quatre grands types de donnes dnis par l'OGC : Point : le point reprsente un simple point. Il peut tre deux ou trois dimensions.
Fig. 3.9 LineString simple et ouverte ; LineString simple et ferme (Li-
nearRing)
Fig. 3.10 LineString non simple et ouverte ; LineString non simple et ferme
Curve :
la classe abstraite
Curve
reprsente un ensemble de points. En
pratique, la seule classe qui en hrite est la classe
LineString
reprsen-
tant une ligne brise. Chaque paire de points conscutifs dnissant
LineString dni donc un segment de droite de la ligne brise. La classe Line qui hrite de LineString est un segment de droite,
d-
termin par les deux paires de coordonnes des points ses extrmits.
27
La classe
neString
LinearRing
(gure 3.9b) hritant de
LineString
est un
Li-
qui est ferm et simple. Par ferm, on entend le fait que le
premier point du
LinearRing
est confondu avec son dernier point et
par simple, on entend que l'objet gomtrique n'a pas d'intersection avec lui-mme (gures 3.9 et 3.10). Surface : la classe abstraite
Surface
reprsente un objet deux dimen-
sions compos d'un bord extrieur et de un ou plusieurs bords intrieurs. Pour crer des surfaces trois dimensions, il faut assembler des surfaces deux dimensions. GeometryCollection : Chacun de ces trois types de donnes peuvent tre assembls et former des collections (
GeometryCollection ).
Il est intressant de remarquer qu'il n'y a pas de moyen simple de reprsenter un cercle. OpenGIS ne dnissant que des segments de droite ou des lignes brises, le seul moyen de reprsenter un cercle est en fait de construire un polygone avec un nombre lev de cts. Cette limitation peut parfois tre drangeante mais peut tre gnralement contourne.
Fig. 3.11 Schma UML des donnes spatiales OGC
Les attributs et les mthodes pour ces direntes classes ont galement t dtermines dans [8]. Les mthodes contenues dans la classe peuvent tre regroupes de la manire suivante : Les mthodes basiques (Dimension(), GeometryType(), SRID(), . . .) qui permettent d'obtenir des informations gnrales sur l'objet comme sa dimension, son type, son systme de rfrence, ses limites ou encore le rectangle minimal qui contient tout l'objet. L'export de donnes en format binaire ou textuel.
Geometry
28
Les mthodes de relations avec d'autre objets spatiaux : Equals(), Intersects(), Contains(), Distance(), . . . Chaque classe qui hrite de les extrmits d'un tivement triviales : rcupration des coordonnes d'un
Point, la longueur et LineString, la centrode d'une Surface, . . .
Geometry
possde galement des mthodes rela-
Les donnes peuvent tre reprsentes de deux faons, d'une manire textuelle (WKT ou Well Know Text), facilement comprhensible pour un tre humain et en binaire (WKB ou Well Know Binary) plus compact et plus utile pour la sauvegarde dans des chiers ou le transfert entre applications. Par exemple, l'criture d'un point situ x=100 et y=200 en WKT est POINT(100 200) Une collection d'objets gomtriques compose du mme point ainsi que d'une ligne dtermine par trois point s'crit : GEOMETRYCOLLECTION (POINT(100 200), LINESTRING(10 30, 40 25, 70 90)) Il existe galement du WKT pour dnir les systmes de rfrences spatiales (SRID) (gure 3.12). Le dtail de la grammaire utilise est reprise dans l'annexe A.
PROJCS["WGS 84 / UTM zone 30N", GEOGCS["WGS 84", DATUM["WGS\_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]], UNIT["degree",0.01745329251994328, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4326"]], PROJECTION["Transverse\_Mercator"], PARAMETER["latitude\_of\_origin",0], PARAMETER["central\_meridian",-3], PARAMETER["scale\_factor",0.9996], PARAMETER["false\_easting",500000], PARAMETER["false\_northing",0], UNIT["metre",1,AUTHORITY["EPSG","9001"]], AUTHORITY["EPSG","32630"]]
Fig. 3.12 Reprsentation WKT de la projection UTM 30 Nord avec un
gode WGS 84
29
La structure du WKT pour les SRID est susamment complte que pour facilement intgrer des projections exotiques ou les volutions futures du WGS 84. Cependant, la dnition d'un systme de rfrence tant assez volumineux (une bonne dizaine de lignes au minimum comme sur la gure 3.12), la plupart des implmentations de l'OpenGIS ont prcod les systmes de rfrence les plus courants dans des variables statiques. C'est gnralement la reprsentation textuelle qui sera utilise pour la manipulation manuelle des bases de donnes. Nous n'entrerons pas dans le dtail de la reprsentation binaire, le lecteur intress peut se rfrer [7]. Toute implmentation de l'OpenGIS se doit d'inclure ces dirents types de donnes ainsi que les mthodes et les attributs dnis par le consortium.
3.3.2 Autres recommandations de l'OGC

Nous allons rapidement passer en revue certaines des recommandations de l'OGC. Nous n'allons pas dtailler la plupart de celles-ci principalement car, bien que dicte par un consortium reconnu, elles ne sont pas des standards de fait. Pour transfrer les donnes spatiales, l'OGC recommande d'utiliser le GML, une grammaire XML pour le transport et le stockage des donnes spatiales. Dans sa troisime mouture, le GML supporte des donnes 3D et des proprits temporelles. Le GML ne contient que les donnes spatiales et aucune information quant leur reprsentation. Ce travail est laiss au SVG (images vectorielles en XML), au X3D (images 3D en XML) ou n'importe quel autre programme de visualisation capable de lire des donnes GML. Les avantages principaux du GML par rapport ses concurrents comme le ShapeFile (shp) sont les avantages du XML [13] : il est textuel et donc facilement lisible et ditable par tous, il permet de proter de la vrication de l'intgrit des donnes intgr XML (GML DTD). De par l'universalit du XML, il peut tre mlang avec d'autres langages XML. Finalement, le XML peut facilement tre transform au moyen de l'XSLT. C'est utile pour transformer le GML en SVG mais cela ouvre aussi les possibilits de bases de donnes GML. Cependant, le GML n'est pas universellement adopt. Google, qui fait pourtant partie de l'OGC, utilise pour Google Earth son propre format le KML (Keyhole Markup Language), bas en partie sur le GML mais qui intgre en plus des informations concernant l'achage des donnes (le style). Ce format gagne en popularit, en partie car il est plus facile utiliser que le GML qui est plus complet mais aussi plus complexe. L'OGC dnit galement un ensemble de protocoles de communication (WMS : Web Map Service, Web Feature Service : WFS et Web Coverage Service : WCS) entre serveurs de donnes. Cela permet de dcouvrir les possibilits d'un serveur de donnes compatible OGC. Ainsi, les informations renvoyes contiennent la zone de couverture des cartes ou encore le type de
30
formats d'images supports par le serveur (principalement aux formats GIF, PNG et SVG qui supportent la transparence et sont donc superposables). En utilisant dirents serveurs, les donnes peuvent tre mlanges avant d'tre utilises dans les applications. Le transfert de donnes se fait soit sous la forme d'images soit en GML si l'on souhaite connatre les donnes spatiales an de les manipuler.
3.4 Les bases de donnes spatiales

Les bases de donnes spatiales ont t dveloppes dans les annes 70 an de stocker les donnes cartographiques. On appelle un GIS (Geographic Information System) une base de donnes qui permet de stocker et de consulter des informations ayant un ou plusieurs attributs spatiaux tels que la taille, la forme ou la position. Typiquement, toute application utilisant des adresses ou des cartes peuvent tirer avantage de ce type de bases de donnes. An de manipuler ce type de donnes, un certain nombre de primitives ont t dnies comme les points, les arcs, les polygones (vecteurs) ou des maillages (raster). On peut ensuite ajouter un certain nombre de caractristiques ces donnes. Il est galement possible d'introduire une notion de temps et les bases de donnes de ce type sont alors qualies de spatiotemporelles. Les GIS sont capables de manipuler plusieurs types de donnes, dans les bases de donnes populaires, ces types de donnes suivent les recommandations de l'OpenGIS [2]. Les donnes attributaires correspondent aux attributs d'un objet gographique (nom d'une route ou d'un btiment, type de fort ou de culture d'un champs, . . .) et permettent de les qualier. Les objets gographiques sont organiss en couches relatives un domaine particulier (les routes, les rivires, . . .). De cette manire, les cartes sont composes d'un ensemble de ces couches. Prciser des donnes supplmentaires ou retirer des donnes inintressantes pour une application se fait simplement en supprimant ou en rajoutant une couche de donnes. Les mtadonnes sont le regroupement de donnes spatiales et de donnes supplmentaires an de dcrire la donne, sa qualit (date de saisie, prcision, . . .) ou des informations de gestion interne (responsable, date d'acquisition, dernire mise jour, . . .)
3.4.1 Structure OpenGIS

Comme prcis dans le point sur l'OGC la page 28, les bases de donnes suivant les recommandations de l'OGC implmentent un certain nombre de mthodes sur les classes mais galement des mthodes plus spciques aux bases de donnes [17].
31
Fig. 3.13 Structure des tables SQL OGC
Le document [7] dcrit la gestion des donnes spatiales et la structure des tables utiliser dans le moteur de la base de donnes. Les tables de donnes sont les tables classiques d'une base de donnes mais qui peuvent contenir, parmi leurs attributs, des attributs de type spatial. La table GEOMETRY_TABLE contient les objets spatiaux qui peuvent tre dcrits sous une forme textuelle (normalise) ou binaire. La table GEOMETRY_COLUMNS dcrit les tables de donnes existantes et les proprits spatiales qui y correspondent. La table SPATIAL_REF_SYS dcrit les systmes de coordonnes et les transformations possibles des donnes spatiales. Chaque table est susceptible d'accueillir une colonne spatiale. Il n'y a aucune obligation quant la position de cette colonne l'intrieur de la table. La colonne est rfrence au moyen d'un numro (GID = Geographical IDentication). Chaque colonne est galement reprise dans la table GEOMETRY_COLUMNS, l'intrt est de pouvoir facilement retrouver les attributs spatiaux de la base de donnes et d'y attacher des informations supplmentaires (comme les dimensions, le type de l'attribut, son systme de rfrence, . . .). Les donnes spatiales sont rellement stockes dans la table GEOMETRY_TABLE (voir tableau 3.1, page 34). A chaque objet correspond une
32
cl (GID) et consiste en un ou plusieurs lments primitifs ordonnancs par un numro de squence (ESEQ). Un lment primitif est insr dans la table au moyen d'une ou plusieurs lignes, identies par un type (ETYPE : 1 pour 3 pour
Polygon
Point,
2 pour
LineString,
[11]), un numro de squence (SEQ) et un ensemble de co-
ordonnes. Le numro de squence permet de connatre l'ordre des lments composant l'objet. Ce nombre de coordonnes est une valeur prxe dtermine par le gestionnaire de la base de donnes. Si l'lment primitif est compos de moins de coordonnes que de colonnes prvues cet eet, les coordonnes seront remplies par la valeur
null.
Si l'lment a besoin de plus de coordonnes, il
est insr au moyen de direntes lignes. Dans l'exemple du tableau 3.1, nous avons un objet du type
MultiPolygon
(GID = 1) compos de deux polygones (ETYPE = 3) : un carr et un hexagone. La table GEOMETRY_TABLE est capable de contenir cinq paires de coordonnes par ligne. Les polygones sont exprims au moyen de leur contour ferm, le premier et le dernier point de ce contour devant correspondre. Le carr (ESEQ 1) a ainsi besoin de cinq coordonnes (0,0), (0, 50), (50, 50), (0, 50) et (0, 0) et peut tre not sur une seule ligne. Cette ligne contient un numro interne la squence (SEQ), le numro 1. L'hexagone (ESEQ 2) a besoin de 7 coordonnes pour exprimer son contour. C'est plus que le nombre de coordonnes pouvant tre exprims sur une seule ligne. Le contour de l'hexagone sera par consquent divis en deux lignes. La premire ligne (SEQ 1) contient les cinq premires coordonnes : (70, 0), (120, 0), (120, 50), (95, 50) et (95, 75). La deuxime ligne (SEQ 2) doit avoir, pour premire coordonne, la dernire coordonne de la ligne qui la prcde. Par consquent, les coordonnes inscrites sont (95, 75), (70, 75) et (70, 0). Comme il n'y a plus de coordonnes restantes, on remplit le reste de la ligne par la valeur
null.
Pour rsumer, chaque objet gomtrique est exprim au moyen d'un numro (GID) et des dirents lments qui le composent dont le type est donn par ETYPE et l'ordre par ESEQ. Chacun de ses lments est exprim sur une ou plusieurs lignes en fonction du nombre de colonnes prsentes dans la table GEOMETRY_TABLE. Pour conserver l'ordre de ces lignes, un numro de squence (SEQ) est utilis. La rptition des coordonnes lorsque l'objet est exprim sur plusieurs lignes permet d'avoir une vrication supplmentaire La table SPATIAL_REF_SYS contient les informations relatives au systme de rfrence spatial : un numro d'identication (SRID), le nom de l'autorit qui dnit ce systme de rfrence (AUTH_NAME), le numro interne cette autorit (AUTH_SRID) et une reprsentation en WKT du systme de rfrence (SRTEXT) (voir l'annexe A.1). An de garantir que cette structure soit respecte, l'OGC a dni deux mthodes sur les tables pour ajouter et supprimer les colonnes spatiales [7] :
33
GID 1 1 1
ETYPE 3 3 3
ESEQ 1 2 2
SEQ 1 1 2
X0 0 70 95
Y0 0 120 75
X1 0 120 70
Y1 50 0 75
X2 50 120 70
Y2 50 50 0
X3 0
Y3 50
X4 0
Y4 0
null
95
null
50
null
95
null
75
Tab. 3.1 GEOMETRY_TABLE contenant un objet compos de deux
polygones
AddGeometryColumn()
La mthode AddGeometryColumn(F_TABLE-
_CATALOG, F_TABLE_SCHEMA, F_TABLE_NAME, G_COLUMN_NAME, SRID)] s'assure que le numro SRID existe bien dans la table SPATIAL_REF_SYS, ajoute la nouvelle colonne dans la table G_COLUMNS, modie la table au moyen de la fonction ALTER_TABLE de SQL et enn, ajoute les contraintes d'intgrit la base pour s'assurer que les ajouts la base respecteront bien le SRID.
DropGeometryColumn()
La mthode DropGeometryColumn(F_TABLE-
_CATALOG, F_TABLE_SCHEMA, F_TABLE_NAME, G_COLUMN_NAME)] va enlever la contrainte d'intgrit spatiale, enlever l'entre dans G_COLUMNS et nalement enlever la colonne dans la table en question (F_TABLE_NAME). Nous allons vous prsenter quelques moteurs de base de donnes spatiales
34
existants.
3.4.2 MySQL
MySQL est un moteur de base de donnes Open Source sous licence GPL
qui a connu une croissance fulgurante ces dernires annes. Sa simplicit, son volution rapide et ses performances honorables en ont rapidement fait un systme de base de donnes trs populaire avec une estimation 6 millions d'installations. Depuis la version 4.1, MySQL est dot de fonctionalits spatiales simples qui seront compltes dans la 5
me mouture du serveur de bases de donnes.
Le dveloppement respecte les recommandations de l'OpenGIS mais n'implmente pas encore la vue geometry_columns qui a pour but de reprendre l'ensemble de colonnes ayant des attributs gomtriques ce qui permet de standardiser la recherche d'attributs graphiques par des applications tierces. Les limitations sont assez fortes : les objets gographiques ne peuvent pas avoir plus de deux dimensions et les fonctions primplmentes sont peu nombreuses. Le calcul de distance ou la modication du systme de coordonnes n'est pas possible avec MySQL.
3.4.3 PostgreSQL
PostgreSQL (aussi connu sous le nom de Postgres) est un projet de base de donnes sous licence BSD tmes de base de donnes PostgreSQL est fait au moyen du projet PostGIS [17], lui-mme sous licence GPL.
2 dbut en 1986. Le support spatial aux sys-
3.4.4 Oracle 10g

Oracle est la rfrence dans les bases de donnes spatiales avec son produit Oracle Spatial. La licence d'utilisation d'Oracle est payante. Il existe cependant une version gratuite et redistribuable (mais pas libre) d'Oracle appele Oracle XE (mais qui ne supporte pas les donnes spatiales), une version d'Oracle limit un utilisateur (Oracle Light) et une licence gratuite d'utilisation d'Oracle limite la conception de prototypes. Oracle inclut diffrents outils de manipulation des donnes spatiales ainsi que des mthodes supplmentaires celles proposes par l'OGC.
GPL est la GNU General Public Licence, une licence de logiciel libre. Tout le monde
a le droit de lire, modier, redistribuer et d'utiliser le programme tant que le programme et ses modications sont publies sous la mme licence. Du code GPL ne peut pas tre utilis dans des logiciels n'ayant pas la licence GPL.
La licence BSD est une licence de logiciel libre. Sa principale dirence avec la licence
GPL est que le code peut tre rutilis par n'importe qui pour n'importe quelle utilisation, commerciale ou non condition de reconnatre les auteurs du code originel. Mac OS X et la couche IP de Windows sont drivs de logiciels sous licence BSD.
35
3.4.5 DB2
DB2 est la base de donnes dveloppe par IBM. Le support des donnes spatiales se fait au moyen de l'extension DB2 Spatial Extender qui respecte aussi les standards dicts par l'OGC.
3.4.6 Middleware
La socit ESRI dite ArcSDE (Arc Spatial Database Extension). C'est une couche logicielle (middleware) qui s'intgre entre les bases de donnes et les applications ayant besoin de donnes spatiales. Son but est de fournir une interface unique aux programmes quel que soit le systme de bases de donnes en dessous du middleware. ArcSDE supporte actuellement Microsoft SQL Server, Oracle Database, DB2 et Informix. Ce middleware optimise le stockage des donnes spatiales en fonction de la base de donnes sous-jacente et le dveloppeur de l'application utilisant ArcSDE ne doit pas se soucier des spcicits de l'architecture de la base de donnes. MapInfo, un autre grand nom des socits GIS, dveloppe SpatialWare qui est destin tre utilise avec Microsoft SQL Server et Informix d'IBM.
3.5 Cration et manipulation de donnes spatiales

Les donnes spatiales tant fortement visuelles, il est naturel de dvelopper des logiciels graphiques an de crer, visualiser et manipuler ces donnes. Un de ces logiciels est ArcGIS, dit par ESRI. Cette suite logicielle est compose entre autres de
ArcReader ArcView
ArcReader est gratuit et permet de faire des requtes et d'a-
cher des cartes dveloppes par d'autre produits de la suite Arc. Ce logiciel a pour but d'analyser, grer et de visualiser des don-
nes gographiques.
ArcEditor
est un diteur de cartes gographiques.
3.6 Conclusion
Dans ce chapitre, nous avons expos le modle de la Terre WGS 84 utilis dans le systme GPS. Nous avons galement touch un mot propos des direntes techniques de projection de ce modle sur une surface plane. Le systme principalement utilis avec le WGS 84 est la projection UTM. Nous avons ensuite expos les initiatives de l'Open Geospatial Consortium, les types de donnes dnies par cet organisme an de standardiser les programmes utilisant des donnes spatiales parmi lesquels se trouvent les bases de donnes.
36
Chapitre 4
Choix prliminaires
4.1 Introduction
Dans ce chapitre, nous allons exposer un scnario de service golocalis. A partir de celui-ci, nous allons identier les besoins de ce scnario et choisir les technologies utilises dans le cadre de ce mmoire. Les besoins pour les clients, le serveur, les bases de donnes et le moyen de communication entre ces dirents lments ont t pris en compte en tablissant ces choix. Ensuite, il sera ncessaire de slectionner des outils an de faciliter le dveloppement de notre plateforme. Les direntes alternatives, les choix que nous avons faits et leurs particularits sont dtaills dans ce chapitre.
4.2 Scnario de base

L'ide de ce scnario est inspire du projet ShoutSpace
1 dvelopp de-
puis 2004 par trois chercheurs l'Ecole Polytechnique Fdrale de Lausanne (EPFL). ShoutSpace permet aux utilisateurs d'ordinateurs portables sur le campus de l'EPFL de voir leur position et de laisser des messages aux autres utilisateurs. Une carte du campus permet de visualiser sa position et les messages (voir gure 4.1). Notre scnario est relativement similaire. Deux services ont t crs sur notre plateforme que nous avons nomm Silas. GeoMail est un systme de messagerie gographique. Une personne peut crire un message un autre utilisateur un lieu gographique donn. Lorsque le destinataire s'approche de la position en question, il reoit le message sur son cran. L'autre service est FriendFinder qui permet un utilisateur de la plateforme Silas de dnir ses connaissances et d'acher les positions gographiques de ses amis sur une carte. La gnration de la carte est aide par des services internes Silas qui fournissent des outils aux services golocaliss disponibles sur la plateforme.
http://craftsrv1.epfl.ch/research/shoutspace/
37
CHAPITRE 4. CHOIX PRLIMINAIRES
Fig. 4.1 ShoutSpace
Alice est quipe d'un PDA muni d'un rcepteur GPS et est tranquillement chez elle. Bob, un ami d'Alice, est aussi quip d'une PDA avec rcepteur GPS mais est distant de quelques kilomtres et se dplace en voiture. Aucun des deux ne connat la position de l'autre. Tous les deux ont leur PDA teint. Alice allume son PDA, s'identie sur le systme Silas et lance FriendFinder qui n'ache que sa position car aucun connaissance n'est connecte au service. Quelques minutes plus tard, Bob allume galement son PDA et lance FriendFinder. Alice et Bob voient dsormais une carte reprsentant la zone o ils se trouvent ainsi que leurs positions sur cette carte. Alice dcide d'envoyer Bob le message Si tu as le temps, passe chez moi, j'ai quelque chose te montrer avec un rayon de validit d'un kilomtre. Bob continue avancer, s'approche de la maison d'Alice et, lorsqu'il est moins d'un kilomtre de la maison d'Alice, reoit le message et dcide de passer chez Alice.
4.3 Modlisation du scnario

Pour modliser le scnario, nous allons reprsenter les appareils mobiles au moyen de direntes instances d'une mme application client. Les clients
38
communiquent, au travers d'un rseau, avec un serveur en utilisant le protocole TCP/IP. Pour la modlisation des communications rseau, nous allons utiliser la boucle locale de la couche TCP/IP. Dans les ordinateurs disposant d'une pile TCP/IP (c'est le cas de la plupart des machines connectes un rseau), l'IP 127.0.0.1 et le nom de domaine
localhost
pointent vers la machine locale.
Cela permet de simuler le fonctionnement d'un rseau, en passant par les direntes couches TCP/IP, avec la mme machine faisant oce de serveur et de client. La transposition une architecture o le serveur et le client seront placs sur des machines direntes se fait simplement en changeant l'adresse IP du serveur dans le client (c'est dire remplacer l'IP 127.0.0.1 par l'IP de la machine ou bien son nom de domaine par le nom de la machine). D'une manire similaire, les bases de donnes sont places sur la mme machine, mais on s'adresse eux en utilisant leur adresse IP ou le nom de domaine correspondant. Les requtes mises par le client sont interceptes par un serveur qui, ventuellement en communiquant avec des bases de donnes, va rpondre au client.
4.4 Spcications
Pour construire une plateforme de services golocaliss raliste et modulable, il faut respecter un certain nombre de contraintes : Les bases de donnes supportes doivent tre nombreuses. Le concepteur d'un service doit avoir le choix de la base de donnes qu'il souhaite utiliser. Grce la spcication JDBC, les programmes crits en Java sont capables de communiquer avec la quasi totalit des bases de donnes existantes. La plateforme, ct client et ct serveur, doit reprendre un maximum du travail commun aux applications golocalises et fournir l'accs une API golocalise. Ceci an de permettre au concepteur de services de se concentrer sur les spcicits de son service. La communication au travers du rseau doit tre minimise. Les modes d'accs sont multiples et certains sont plus lents ou coteux que d'autres. Il est donc intressant dans le cas des tlphones mobiles de diminuer au maximum le besoin en bande passante lors des communications entre le serveur et les clients. Les services golocaliss pouvant tre dvelopps par des personnes diffrentes, ils peuvent tre placs sur des serveurs dirents et utiliser chacun une base de donnes spcique. Les applications situes sur des serveurs dirents doivent pouvoir communiquer avec le serveur central pour y rcuprer les donnes qui y sont stockes (position de l'utilisateur, ...)
39
La plateforme doit intgrer un systme d'identication et d'authentication des utilisateurs an de fournir des services bass sur cette identit, de limiter certains services certains utilisateurs ou de laisser la possibilit de facturer certains services.
4.5 Choix de l'architecture

L'appareil de l'utilisateur tant gnralement un appareil mobile (PDA, GSM, ...), l'application client sera programme en Java, qui a l'avantage d'tre un langage de programmation populaire, portable et disponible sur la majorit des matriels cibles existants (du GSM l'ordinateur portable). Le langage Java possde des libraires spciques prenant en charge les communications rseau. De plus, direntes librairies supplmentaires sont dveloppes par les utilisateurs de Java. La librairie spatiale GeoTools spcique aux donnes spatiales et qui a t utilise dans le cadre de ce mmoire est dtaille au point 4.6.7. L'application serveur, de son ct, doit avoir les capacits de communiquer avec des bases de donnes et avec le client. L'application serveur d'une plateforme de services golocaliss a pour but de faire tourner certaines applications (les services) qui rpondent aux requtes des utilisateurs. Il existe sur le march des
serveurs applicatifs qui incluent une partie de la complexit
du dveloppement de ces plateformes. De nombreuses technologies existent (.NET de Microsoft, J2EE de Sun Microsystems, Zope, ...) mais les serveurs applicatifs les plus populaires sont ceux qui respectent les recommandations J2EE de Sun qui sont programms en Java, ce qui a l'avantage de nous permettre d'utiliser le mme langage de programmation pour le client et le serveur. Les spcicits des serveurs J2EE sont exposes au point 4.6.3. La communication entre le serveur et les clients peut se faire de direntes faons. Corba est une technologie de communication entre langages entirement indpendante des langages utiliss. Il permet ainsi des changes entre, par exemple, des programmes en C et en Java. Cependant, Corba n'est plus trs populaire suite l'apparition du protocole SOAP utilisant le XML qui permet globalement de faire la mme chose mais plus beaucoup plus simplement. Il existe galement RMI qui est uniquement destin aux communications entre applications Java. Du ct de la programmation, RMI et SOAP se valent. Cependant, SOAP utilise plus de bande passante que RMI (qui est directement cod en binaire) et le XML de SOAP doit tre pars ct client et ct serveur ce qui peut tre problmatique pour des terminaux mobiles peu puissants. Mais SOAP est plus universel car RMI est limit Java. Nous avons fait le choix d'utiliser RMI. Dans l'optique d'tendre les possibilit de l'architecture, il est cependant possible sous J2EE de gnrer des Web
40
Services en SOAP sans modier le code des EJB. Pour les bases de donnes, du ct des solutions propritaires, la version gratuite d'Oracle (Oracle XE) n'a pas le support des donnes spatiales et les solutions payantes exposes au point 3.4 sont trop chres pour le cadre d'un mmoire. Du ct Open Source, MySQL, dans sa version stable, n'a pas encore implment l'entiret des spcications de l'OGC et ne possde pas encore susamment de mthodes pour la manipulation des donnes. PostGreSQL est complet, libre et gratuit et possde au total plus de 300 mthodes de manipulation de donnes, codes en SQL
2 (le standard de fait des
langages de requtes de bases de donnes), en PL/pgSQL (SQL procdural de PostGreSQL) ou directement en C (plus rapide). Il est possible d'ajouter soi-mme des mthodes supplmentaires. Nous avons ds lors choisi d'utiliser PostGIS, l'extension spatiale de la base de donnes PostGreSQL.
4.6 Technologies choisies

4.6.1 Java
La famille des langages Java (Java Micro Edition, Java Standard Edition et Java Enterprise Edition) tourne sur une machine virtuelle Java. Elle permet de faire abstraction de l'architecture relle et de donner l'illusion d'une architecture constante quel que soit le systme rel sur lequel tourne l'application Java. C'est la machine virtuelle qui interprte et excute le forme ce
bytecode
gnr la compilation d'un programme Java. La machine virtuelle trans-
bytecode
en code machine rellement exploitable par l'ordinateur.
Pour porter n'importe quelle application Java sur direntes architectures, il faut juste dvelopper une autre machine virtuelle qui permettra d'interprter le mme bytecode en code machine adapt au processeur et l'architecture de l'ordinateur. Des machines virtuelles existent pour la plupart des systmes d'exploitations, des processeurs, tlphones mobiles, PDA et appareils mobiles existants.
4.6.2 Java Standard Edition

Le choix du langage de programmation pour le client s'est port sur Java qui combine dirents avantages :
simple :
Java est un langage simple et rapide programmer. La gestion
des erreurs, la prsence d'un garbage collector en font un outil puissant pour le dveloppement d'applications diverses. De nombreux outils et environnement de programmation existent pour acclrer encore le dveloppement.
Structured Query Language
41
multi plateformes :
Java est disponible sur de multiples plateformes. Cela
inclut entre autres tous les systmes d'exploitation d'ordinateurs et les serveurs de type Linux, Unix et Windows. C'est galement le langage le plus populaire sur les appareils mobiles.
orient objet :
couches.
La puissance de l'orient-objet est utile pour le dvelop-
pement d'une plateforme. Cela permet de faciliter la rutilisation des objets entre les dirents services et de sparer la programmation en
susamment performant :
Java est rgulirement critiqu pour sa vi-
tesse d'excution, car il gnre du bytecode qui est ensuite interprt par la machine virtuelle. Cependant, les applications ct client doivent tre relativement simples puisque la plupart des appareils mobiles ne sont pas trs puissants.
gratuit :
la machine virtuelle Java est disponible gratuitement sur le site
de Sun (http://java.sun.com). Il existe de nombreuses API gratuites
(ou libres) et des environnements de dveloppement puissants (comme Eclipse d'IBM) sont disponibles gratuitement.
communication native avec J2EE :

tions au travers du rseau.
Les applications savent communi-
quer directement avec des applications J2EE au moyen de l'API RMI. Cela permet de diminuer le travail de traduction lors des communica-
Une partie des appareils mobiles (principalement les GSM et les PDA moins puissants) ne sont pas capables de faire tourner J2SE. Sun a ds lors dni J2ME (Java Micro Edition). Il existe deux sous-catgories de J2ME : une version contenant le strict minimum pour faire tourner une machine virtuelle (CLDC) et une version (CDC) regroupant toutes les possibilits de J2SE except ce qui touche l'interface graphique. Le passage de J2SE J2ME ne ncessite gnralement que l'adaptation de l'interface graphique l'ergonomie de l'appareil utilis. Nous avons choisi dans notre implmentation de sparer la gestion de l'interface graphique et des fonctionnalits du client pour permettre de facilement utiliser une autre interface graphique spcique un certain type d'appareil mobile.
4.6.3 Java Enterprise Edition

J2EE (ou Java EE : Java Enterprise Edition) est une plateforme de dveloppement Java spcialement destine aux applications de type serveur. J2EE est une spcication dveloppe par Sun Microsystems qui dnit des API . Pour tre certi J2EE, un serveur applicatif doit respecter les spcications de Sun. Une application respectant totalement les standards J2EE
Application Programming Interface : librairie d'objets et de mthodes permettant
d'tendre les possibilits du langage Java
42
pourra tre dploye sur n'importe quel serveur applicatif certi J2EE. Cependant, la plupart des serveurs applicatifs sur le march ajoutent un certain nombre de composants spciques an de rpondre plus de besoins que ceux couverts par le J2EE standard. J2EE contient direntes spcications, comme JDBC (Java DataBase Connectivity) pour la communication avec les bases de donnes, les applets pour faire des pages Web, les communications distance RPC (Remote Procedure Call), Corba et RMI (Java Remote Method Invocation) entre applications. Depuis J2EE 1.4, les web services font galement partie des spcications ocielles de J2EE. De plus, les serveurs applicatifs J2EE ont t penss pour pouvoir tre distribus sur une architecture compose de plusieurs serveurs. Les programmes J2EE utilisent des EJB. Un EJB (Enterprise Java Bean) est un programme Java eectuant la logique mtier sur le serveur. Les EJB sont invoqus par d'autres EJB ou des applications clients au travers d'interfaces Java. Les EJB et leur interfaces sont regroups dans ce qu'on appelle un conteneur EJB. Cette notion de conteneur EJB est dtaille la section 4.6.4. Les dtails de la spcication des EJB et les avantages sont expliqus la section 4.6.4. J2EE dnit en plus un ensemble d'API qui tendent Java SE (Standard Edition) :
javax.ejb
L'API Enterprise Java Beans (EJB) dnit un ensemble de m-
thode qu'un conteneur d'objet distribu doit fournir pour permettre la persistance, la communication distance, le contrle de concurrence et l'accs des objets multiples. L'API EJB sera dcrite plus en dtails dans la section 4.6.4.
javax.servlet et javax.servlet.jsp
sur des pages Web.
dnissent un ensemble d'API an de
permettre la communication entre un conteneur web et des servlets ou JSP (Java Servlet Page) qui permettent de gnrer ou d'tre aches
java.sql et javax.sql
permettent la communication avec des bases de don-
nes l'aide de connecteurs JDBC. Cela permet Java de se connecter toutes les bases de donnes qui supportent ODBC (Open Database Connectivity). La liste des bases de donnes supportes contient entre autres Oracle, DB2, Microsoft SQL Server, Sybase, MySQL, PostgreSQL ou Microsoft Access [1].
javax.naming
est une API pour trouver les donnes et les objets sur un
rseau au moyen d'un nom et de l'adresse du serveur. Son implmentation est indpendante de l'architecture qui fait tourner la machine virtuelle. Cette API est utilise par RMI.
autres :
D'autre API font galement partie de J2EE : JTA (Java Tran-
saction API) qui permet de standardiser les transactions ; Java Mes-
43
sage Service qui permet la communication asynchrone entre composants Java ; JAXP qui permet de lire des chiers XML.
4.6.4 Enterprise Java Bean

Les EJB (Enterprise Java Bean) sont la vritable particularit du dveloppement J2EE. Dans la suite de ce texte, nous utiliserons les termes Bean et EJB pour dsigner un EJB. La spcication des EJB dtaille ce que le serveur applicatif fournit. Ces fonctions tant gres par le serveur applicatif, le concepteur des EJB ne doit pas s'en soucier. 1. La persistance : les donnes contenues dans les EJB peuvent tre sauves la vole par le serveur applicatif. En cas de problme avec celui-ci (coupure de courant, panne du systme, ...), l'tat courant des EJB qui ont activ la persistance n'est pas perdu. En choisissant correctement les EJB utilisant la persistance, le systme peut redmarrer dans son tat avant le problme. 2. Le contrle des transactions permet de s'assurer qu'un ensemble d'oprations devant s'excuter ensemble se droulent correctement. Faute de quoi, l'ensemble des oprations qui composent la transaction est annules. Le transfert d'argent entre deux comptes est un exemple classique de transaction : si 100 euros doivent aller du compte A au compte B, il faut dbiter le compte A et crditer le compte B. Ces deux oprations font partie d'une mme transaction, si une de ces deux oprations choue, la transaction complte doit tre annule pour garantir l'intgrit du systme. 3. Le contrle de la concurrence permet de s'assurer que plusieurs objets Java (une application client, un autre EJB, ...) n'accdent pas en mme temps un mme EJB. S'il n'y a aucune contrle sur la concurrence d'vnements, il est possible que les modications appliques par le premier objet soient crases par les modications apportes par le deuxime objet. Il faut donc appliquer un contrle de ces accs concurrents pour garantir la consistance des donnes. Imaginons un systme o plusieurs objets essaient d'incrmenter la variable x conserve dans un EJB. Dans la gure 4.3, il y a contrle de la concurrence, un scnario o deux objets incrmentent la variable x=3 mne une situation nale o x vaut 5. Dans la gure 4.2, il n'y a pas de contrle de la concurrence, la variable x vaut 4 alors qu'elle devrait valoir 5. Les deux objets ont incrment en interne la variable mais n'ont pas tenu compte des modications opres par l'autre objet. Pour assurer la consistance des donnes, il faut qu'un objet risquant de modier les valeurs d'un autre objet soit le seul y avoir accs pendant la priode o il risque de modier ces valeurs.
44
Fig. 4.2 Concurrence sans contrle
4. Les vnements peuvent tre utiliss, grce Java Message Service (JMS), pour envoyer, de manire asynchrone, des messages entre des clients (composs d'objets Java). 5. La communication distance avec des applications est supporte grce RMI et Corba.
Types d'EJB
Il existe plusieurs grandes classes de beans : les EJB de session, les EJB entit et les EJB Message Driven. Ces derniers tant moins important, nous n'en parlerons pas. Le lecteur intress pourra se rfrer [4]. L'EJB le plus courant est le bean de session. C'est lui qui eectue les tches demandes par le client. La relation entre le client et le bean consiste en une session interactive avec son client. Chaque bean de session est utilis par un seul client la fois jusqu' la n de sa session et il n'est pas persistant (dans le sens qu'il n'est pas stock dans la base de donnes). Cela veut donc dire que s'il y a un problme avec le serveur (panne, coupure, ...) les sessions en cours sont perdues. Puisque les beans de session ne sont utilises que par un utilisateur en mme temps, il n'y a jamais de problme de concurrence. Les EJB de session sont crs au lancement du serveur et sont dans un tat passif. Lorsqu'une requte arrive, ils passent dans un tat actif, r-
45
Fig. 4.3 Concurrence avec contrle
pondent la requte et une fois la session nie, repassent dans un tat passif. Les EJB passifs sont placs dans un pool consitu d'un nombre prdni d'EJB. L'avantage de crer les EJB au lancement du serveur applicatif vient du fait que la cration d'un objet en Java est relativement lente alors que la rponse une requte doit tre la plus rapide possible. Le fait d'avoir des EJB prts rpondre aux requtes permet de diminuer le temps de rponse.
Stateful Session Bean.
Dans ce type de bean, l'EJB est capable de
conserver l'tat entre les mthodes voques par le client. C'est dire que les variables sont conserves entre deux appels de mthodes. Comme un bean ne peut pas tre utilis par deux clients en mme temps, le bean est bloqu durant toute la session.
Stateless Session Bean.
Ce type de bean ne conserve pas la session entre
deux appels de mthode. Pour retrouver les donnes utiles la session, il faudra lui donner un moyen de retrouver ces donnes. Dans notre plateforme, nous utilisons le nom d'utilisateur et la cl de session an que le bean soit capable de rcuprer les ventuelles donnes utiles son bon fonctionnement comme par exemple la dernire position connue de l'utilisateur. Les beans avec tat ont l'avantage de demander moins de ressources rseau puisqu'il ne faut pas repasser le contexte chaque appel de mthode.
46
Cependant, le fait que les beans soient bloqus pendant toute la session implique que le nombre de clients pouvant tre servis en mme temps est plus limit. De plus, les beans sans tat ne doivent conserver aucune donne entre les appels de mthode. Cela induit le fait qu'ils ne perdent aucune donne en cas de panne du serveur applicatif. Nous avons ds lors opt de privilgier les beans de session sans tat.
Entity Bean.
Les beans d'entit correspondent aux donnes persistantes,
c'est--dire stockes dans une base de donnes. En cas de coupure du serveur, les donnes des beans d'entit ne sont pas perdues car elles sont constamment copies dans une base de donnes. La structure d'un bean entit (c'est-dire ses attributs) correspond aux attributs stocks dans la table de la base de donnes. Une instance d'un bean entit correspond une ligne de la table laquelle se rfre le bean. Les beans entit ont donc beaucoup de points communs avec les tables d'une base de donnes : ils possdent une cl primaire permettant de facilement les identier et les retrouver, ils peuvent tre lis d'autres beans d'entit tout comme une table peut tre lie une autre table au moyen de cls trangres. Un EJB d'entit ne contient les donnes d'une ligne d'une table que pendant qu'il est actif. Ds qu'on ne l'utilise plus, il retourne dans une pool o il est vide et attend d'tre utilis pour rpondre une autre requte. On ne peut donc pas passer un pointeur vers un EJB d'entit pour faire rfrence ses donnes. En eet, il est possible qu'entre le moment o l'EJB a t activ et le moment o un autre objet souhaite rcuprer ses donnes, l'EJB soit inactif ou contienne les donnes d'une autre requte. De plus, le nombre d'EJB tant limit, l'ide de vouloir bloquer un EJB pour ne pas aller rechercher deux fois les donnes dans la table diminue les performances globales du systme. Les beans entit peuvent tre utiliss par plusieurs clients. C'est dans ce cas-ci que les problmes de concurrence doivent tre pris en compte. Un autre aspect important gr par J2EE est la transaction exposes la page 44 Les donnes d'un bean entit peuvent tre stockes de manire automatique (sans une seule ligne de SQL) par J2EE si l'on utilise l'approche CMP (Container Managed Persistance). On peut galement choisir l'optique BMP (Bean Managed Persistance) o le crateur du bean inclura lui-mme le code ncessaire la persistance. Le CMP ne ncessite aucune ligne de code pour conserver les donnes, le BMP permet d'optimiser ou de distribuer les donnes sauvegarder sur plusieurs bases de donnes. Dans notre plateforme, nous utiliserons un mlange des deux approches, l'ensemble des donnes d'identication des utilisateurs seront conserves grce au CMP alors que les donnes spatiales sont sauves par du code SQL spcique.
47
Conteneurs EJB
Les Beans ne sont jamais accessibles directement par les applications clients. Ils sont toujours intgrs des conteneurs EJB. Ceux-ci contiennent, en plus donc des EJB, des interfaces Java qui permettent aux clients d'appeler les mthodes. Il existe deux types d'interfaces : remote pour les clients situs sur une autre machine virtuelle et local pour les clients situs sur la mme machine virtuelle. Cependant, rien n'empche d'accder de manire remote des EJB situs sur la mme machine virtuelle. Il est galement possible de dnir les deux types d'interfaces pour un mme EJB. Une interface remote est typiquement utilises dans une optique clientserveur. Dans notre cas, les clients situs sur les tlphones mobiles tant situs sur des machines direntes de celle o se trouvent les EJB, on utilisera principalement des interfaces remote. Pour trouver l'EJB, le client devra connatre le nom du serveur ainsi que le nom de l'EJB dni dans l'interface. La dcouverte de l'EJB est gre par JNDI (Java Naming and Directory Interface). Les interfaces local sont gnralement utilises par des EJB situs sur un mme serveur. Cela leur permet de communiquer entre eux sans passer par le rseau. Par exemple, le serveur Web Tomcat est intgr au serveur applicatif JBoss et permet de gnrer des pages Web au moyen de servlet qui communiquent avec les EJB au moyen de l'interface local.
4.6.5 Serveurs applicatifs J2EE

Plusieurs constructeurs dveloppent des serveurs applicatifs compatibles J2EE. Si le serveur applicatif suit les recommandations J2EE 1.4 dictes par Sun, il obtient la certication J2EE 1.4. Le nombre de serveurs applicatifs ainsi certis est relativement limit. Nous pouvons citer Sun JSAS (Sun Microsystems), WebSphere AS (IBM), WebLogic (BEA), Oracle AS (Oracle), JOnAS (ObjectWeb), JBoss (JBoss Inc.), Geronimo (ASF), ... Les trois derniers sont Open Source alors que les quatre premiers sont des solutions propritaires. Le choix s'est pos sur JBoss qui est le leader avec plus d'un tiers de parts de march selon BZ Media [14]. JBoss est rput pour sa qualit, le support d'XDoclet (voir point 4.6.6), la facilit de dploiement des EJB (ce qui est important lors du dveloppement) et l'intgration de nombreux outils supplmentaires qui tendent les possibilits de la spcication J2EE [15]. Les points ngatifs concernent la conguration manuelle d'un grand nombre de chiers et des paramtres par dfaut peu adapts la plupart des applications [15].
48
4.6.6 XDoclet
XDoclet est un moteur de gnration de code pour J2EE. A partir d'attributs crits sous un format spcique (JavaDoc), XDoclet parcourt le code source Java et cre d'autres chiers. Ces chiers peuvent tre du code Java, des chiers XML ou encore des chiers HTML. C'est ce qu'on appelle l'
Attribute-Oriented Programming.
L'avantage est que XDoclet permet de manipuler moins de chiers Java, augmentant ainsi la productivit du dveloppeur. Au dpart, principalement destin J2EE (qui utilise beaucoup d'interfaces Java pour accder aux EJB), XDoclet a volu en un outil gnraliste. Voici un exemple qui montre que la gnration des interfaces est grandement facilit en utilisant XDoclet. En eet, la cration des interfaces est un travail relativement trivial. En prcisant les bons paramtres XDoclet, il est capable de les gnrer automatiquement. Au dbut de la dclaration de l'EJB, on introduit les commandes XDoclet suivantes qui permettent de dnir le nom du bean, sa description, son type et le type d'accs :
@ejb . bean /
name="Gate" d i s p l a y name=" S i l a s main a c c e s s Gate" d e s c r i p t i o n =" S i l a s a u t h e n t i f i c a t i o n " j n d i name=" e j b /Gate" t y p e=" S t a t e l e s s " view t y p e="remote "
Chaque mthode remote ou local doit galement tre signale pour tre intgre par XDoclet dans l'interface correspondante :
B u s in e s s method @ejb . i n t e r f a c e method /
view t y p e = ' ' remote ' '
En voyant ces deux bouts de code JavaDoc, XDoclet sait qu'il doit gnrer une interface pour l'EJB GateBean. A parti de l'attribut ejb.bean name, XDoclet connat le nom utiliser (dans notre exemple : Gate). Cela consiste crer plusieurs interfaces Java. Si l'EJB est de type remote, on cre deux interfaces. La premire est GateHome.java qui contient le nom du composant pour JNDI et la signature de la mthode create() permettant de crer une instance de l'EJB. Une interface nomme Gate.java qui contient les signatures des mthodes correspondante est galement cre. Si l'EJB contient des mthodes de type local, c'est un chier GateLocalHome.java et GateLocal.java qui sont crs. Chacun de ces chiers contient l'quivalent des chiers crs pour les EJB remote.
49
4.6.7 GeoTools
GeoTools
4 est une API en Java pour la manipulation de donnes spa-
tiales. GeoTools fournit une implmentation des recommandations de l'OGC au fur et mesure de leur dveloppement. Les fondateurs du projet travaillent pour un membre de l'OGC. GeoTools est organis en modules fournissant chacun dirents aspects des GIS (Geographic Information System). Le module
main
contient la base ncessaire au dveloppement utilisant
GIS. Il contient les reprsentations des objets gographiques selon les standards de l'OGC (chapitre 3.2.3) et des objets permettant de crer et manipuler des collections de donnes spatiales. Ces collections de donnes, appeles Features, sont utilises pour gnrer des cartes. Le contenu des Features peut tre cre par l'utilisateur, import depuis des bases de donnes ou depuis des chiers GML. Les donnes supportent les ltres au moyen du package org.geotools.lter. Des modules spciques ont t dvelopps an de rcuprer les donnes depuis des sources diverses : bases de donnes Oracle, DB2, PostGreSQL, MySQL, HyperSonic, ... ; les systmes supports par l'OGC : WMS, WFS ; des donnes spciques dirents programmes : SHP (ArcSDE), VPF (Dpartement amricain de la dfense), MIF (MapInfo), ... Des objets Swing permettant de crer des outils de visualisation sont galement proposs.
4.6.8 PostGIS
Dans le cadre de ce mmoire, au vu des besoins relativement limits (nous n'avons pas de cartes dtailles pour la Terre entire, le systme n'accueillera pas simultanment des millions d'utilisateurs), Oracle et PostGreSQL se valent. Nous avons ds lors choisi d'utiliser PostGreSQL et son extension spatiale PostGIS. Cependant, chaque concepteur de service golocalis doit avoir la possibilit d'utiliser la base de donne qui lui convient et ce choix ne doit pas tre dpendant de la base de donnes choisie pour l'architecture de la plateforme centrale. Puisque notre plateforme s'appuie sur GeoTools et JDBC pour l'utilisation des bases de donnes, n'importe quel format support par une de ces deux API peut tre facilement manipul. Les dtails pratiques de l'utilisation de PostGIS dans ce mmoire sont exposs dans l'annexe C. On y dcrit la procdure d'installation sous Debian GNU/Linux, la cration de tables et de vues an qu'elles puissent tre utilises en combinaison avec l'API GeoTools.
www.geotools.org
50
4.6.9 Eclipse et JBoss IDE
Fig. 4.4 Intgration de JBoss dans Eclipse (1)
Eclipse est un environnement de dveloppement modulable dvelopp par IBM. Il n'est pas li un langage particulier et est capable d'accueillir dirents types de plugin an d'tendre ses possibilits.
JBoss IDE
est un
plugin pour JBoss dit par la socit JBoss Inc qui rend le lancement de leur serveur applicatif et le dploiement des EJB directement accessible depuis l'interface d'Eclipse (gures 4.4, 4.5). Le plugin JBoss IDE permet d'intgrer direntes fonctionnalits de JBoss : la cration des dirents types d'EJB, le lancement et l'arrt du serveur applicatif ou encore la gnration de mthodes J2EE et des tags XDoclet partir d'une interface graphique.
4.6.10 phpPgAdmin
phpPgAdmin est un outil d'administration de bases de donnes PostGreSQL crit en PHP et tournant sur un serveur Web. Il est capable de grer les utilisateurs, les groupes, les vues, les schmas, les triggers, les fonctions, les squences et les objets avancs. phpPgAdmin ne supporte pas les donnes spatiales dans son interface graphique mais la possibilit de taper directement des requtes SQL ne fait pas de cette limitation un handicap. phpPgAdmin est l'origine bas sur phpMyAdmin, un outil d'administration de bases de donnes MySQL et supporte les particularits de PostGreSQL.
51
Fig. 4.5 Intgration de JBoss dans Eclipse (2)
4.7 Conclusion
Nous avons donc dcid d'utiliser un serveur applicatif J2EE, JBoss en particulier pour ses possibilits tendues et sa popularit. Les clients sont programms en J2SE qui est portable et disponible sur de nombreuses architectures d'appareils mobiles. La communication entre ces lments se fait en RMI, limit au langage Java mais plus conome en bande passante et en CPU car il ne demande pas tre pars. J2EE dnissant des standards pour les services Web, il est possible de fournir, ct de la communication en RMI, de la communication en SOAP (XML). L'API utilise est GeoTools, entirement en Java, gratuite, libre et qui respecte les standards de l'OGC. GeoTools jouit de plus d'une communaut active de dveloppeurs.
52
Pour la programmation, nous avons dcid d'utiliser Eclipse et le plugin JBoss IDE ainsi que les fonctionnalits d'XDoclet pour faciliter la programmation J2EE.
53
Chapitre 5
Implmentation
5.1 Introduction
Nous allons prsenter l'implmentation de notre solution de plateforme. Le code se divise en trois parties : la plateforme (Silas) pour le serveur (en J2EE) ; le client (SilasTalker) permettant de se connecter au serveur (en J2SE) et un logiciel de visualisation de donnes spatiales (MapViewer) an d'acher les direntes donnes spatiales de notre plateforme. Nous expliquons galement les facilits proposes par notre plateforme Silas pour le dploiement des services golocaliss et la conception des clients. Nous allons commencer par dnir les termes dsignant les dirents lments de la plateforme utiliss dans la suite de ce chapitre.
Serveur applicatif Plate-forme Silas
est un serveur applicatif de type J2EE install sur une
machine et sur lequel est dploy des EJB. reprsente le cur des services golocaliss. La plate-
forme est compose des lments (EJB) grant les utilisateurs, l'historique de leurs positions, la dcouverte de services et dirents outils pour la cration de services. La plateforme Silas est dploye sur un serveur applicatif JBoss.
Service
reprsente un service utilisant la plateforme Silas mais pas spcia-
lement situ sur le mme serveur applicatif.
Serveur Silas
est le terme dsignant la plateforme Silas et les services qui
sont construits sur la plateforme. Malgr le fait qu'on parle du serveur Silas, il est en ralit possible que la plateforme et les services soient situs sur plusieurs serveurs applicatifs.
Client ou SilasTalker
menus, . . .
reprsente la base de l'application client : connexion
avec la plateforme Silas, gestion des erreurs, achage des fentres,
Client de service ou plugin
est un plugin spcique un service capable
54
CHAPITRE 5. IMPLMENTATION
de communiquer avec ce service et de crer un JPanel par SilasTalker.
1 qui sera ach
5.2 Suppositions
1. Il existe de multiples manires pour un appareil de connatre sa position. Parfois elle est connue directement (GPS), parfois c'est un lment de l'oprateur tlcom qui permet de faire ce calcul. On peut imaginer qu'un utilisateur de GSM puisse faire une demande au LBS sans devoir connatre sa position. C'est alors la plateforme de faire la demande l'oprateur tlcom. Dans des soucis de simplicit, nous avons suppos dans notre scnario que l'utilisateur connat sa position et que c'est lui qui fait directement la demande de service au LBS. Nous n'avons cependant pas exclu de notre modle de plateforme la possibilit d'utiliser le rseau pour localiser l'utilisateur. Pour cela, nous avons en eet intgr un EJB (CellularNetworkBean) pouvant tre interrog si ncessaire. 2. Le concept de push qui suppose que l'appareil reoit du LBS une information quand il arrive dans une certaine zone sera modlis par du polling : l'appareil envoie de manire rgulire (tous les x minutes ou tous les x mtres) sa position au serveur qui dtermine alors s'il est ncessaire de lui envoyer une information en retour. Cette technique n'est bien sr pas trs raliste puisqu'au vu du nombre d'utilisateurs, elle impliquerait que le rseau soit engorg par les messages de polling. On peut cependant imaginer que l'information de position soit intgre dans les communications de base entre les antennes GSM et les appareils. Cependant grce l'UMTS et l'avnement de protocoles comme SIP [16], un vritable push sera possible. 3. Les services peuvent tre dvelopps par plusieurs personnes. Par consquent, l'ensemble des services ne seront pas placs sur le mme serveur applicatif. Nous avons donc fait le choix de favoriser les interfaces du type remote permettant aux programmes Java situs sur des machines distantes de se connecter aux services. Les services situs sur le mme serveur applicatif peuvent galement utiliser ces interfaces, le ct ngatif tant qu'ils doivent passer par l'ensemble des couches d'une communication rseau. Cependant, cela induit une architecture plus souple car les dirents composants situs sur un mme serveur peuvent plus facilement tre spars sur des serveurs applicatifs dirents. Cette possibilit permet d'augmenter l'adaptabilit de la plateforme, en cas de surcharge, le nombre de serveurs applicatifs utiliss pour absorber les requtes peut facilement tre augment.
Un JPanel est un composant graphique "blanc" qu'on surcharge pour dessiner des
composants graphiques.
55
4. Dans la mme optique que le point prcdant, les dirents concepteurs de services peuvent choisir d'autres types de bases de donnes. L'accs direntes architectures de bases de donnes est permise par l'API GeoTools et plus gnralement par JDBC (points 4.6.7 et 4.6.3). 5. Pour augmenter viter les abus, l'ensemble des bases de donnes contenant les donnes sensibles des utilisateurs comme les mots de passe ou l'historique des positions ne sont totalement accessibles qu'au cur de la plateforme. 6. Certains services peuvent ncessiter de connatre l'identit de l'utilisateur et ventuellement tre payants. D'autres peuvent tre gnriques et n'ont donc pas besoin de systme d'identication. 7. L'identication et l'authentication des utilisateurs doit galement tre gr par la plateforme. Pour viter des abus comme la surfacturation ou l'intrusion dans la vie prive des utilisateurs, les services ne pourront rcuprer des donnes sensibles depuis la plateforme qu' condition qu'ils en aient reu l'autorisation des utilisateurs. Cette autorisation est limite dans le temps et lie la session de l'utilisateur qui a la possibilit de fermer sa session tout moment. 8. Les communications mobiles sont par dnition de nature instable. La perte de connexion peut arriver et ne doit pas signier la n d'une session. 9. Les outils d'internationalisation de Java qui permettent de supporter plusieurs langues et les particularits rgionales ont t intgrs l'application client.
5.3 Jeu de donnes

Pour utiliser un service golocalis, il est intressant d'avoir sa disposition un jeu de donnes dans un format OGC qui pourra tre stock dans une base de donnes an d'tre manipul et ach.
5.3.1 Le jeu de donnes Spearsh

Le jeu de donnes Spearsh a t cr l'origine par Larry Batten lorsqu'il travaillait pour l'U. S. Geological Survey. Les donnes ont ensuite t amliores par l'USA/CERL (U. S. Army Corps of Engineers' Construction Engineering Research Laboratory). La zone reprsente s'tend sur environ 180 km
2 et est situe au nord de Black Hills au Dakota du Sud (USA).
La version utilise dans ce mmoire est compose des couches suivantes : La table
TRING TRING
roads
est compose de 825 lments du type est compose de 116 lments du type
MULTILINESMULTILINES-
et reprsente les routes de la zone couverte.
La table
streams
et reprsente les cours d'eau.
56
Fig. 5.1 Extrait du jeu de donnes Spearsh
La table
archsites est l'emplacement de 25 lieux archologiques (POINT ). La table bugsites regroupant des lieux o des insectes ont t retrouvs (POINT ). La table rstrct contient des zones interdites d'accs (rserves naturelles, ...) (MULTIPOLYGON ).
5.3.2 Le jeu de donnes Frida

Frida
2 (gure 5.2) est un jeu de donnes reprsentant la ville d'Osnabrck
dans le Nord-ouest de l'Allemagne. Le projet a pour but de promouvoir la mise disposition de donnes gographiques sous licence libre (Free Software). La version utilise dans ce mmoire est compose des couches suivantes : La table
TRING
rues
est compose de 12 323 lments du type
MULTILINES-
et reprsente les rues.
La table
MULTILINESTRING ). La table planseau contient les objets de type MULTIPOLYGON

passent dans la ville ( posants les plans d'eau.
rivieres
contient 57 lments composants les cours d'eau qui com-
http://frida.intevation.org
57
Fig. 5.2 Le jeu de donnes Frida
La table La table (
espacesverts
contient les objets de type
MULTIPOLYGON
composants les zones vertes.
poi POINT ).
est un ensemble de 268 lieux touristiques dans la ville
5.4 MapViewer
Le premier logiciel que nous avons conu est MapViewer. C'est une simple application permettant l'utilisateur de choisir les donnes de notre base de donnes au format PostGIS. MapViewer (gure 5.3) utilise l'API GeoTools pour gnrer les cartes acher. Une carte est reprsente par l'objet
MapContext et est constitue de
direntes couches contenant chacune un type d'information, par exemple les routes ou les lieux touristiques. Les couches sont reprsentes par les objets
FeatureSource
de GeoTools.
tore. DataStore
Les objets de la classe
FeatureSource
sont gnrs au moyen des
DataS-
est une classe abstraite qui reprsente les dpts de donnes
spatiales pouvant venir de sources aussi diverses que du GML, des bases de donnes spatiales ou des chiers propritaires comme les ShapeFile de la socit ESRI. Direntes classes hritent de
DataStore
et contiennent le
code spcique la lecture et l'interaction avec ces direntes sources de
58
Fig. 5.3 Diagramme UML simpli de MapViewer
donnes. Il est donc possible de mlanger des donnes provenant de sources direntes. Le style graphique est dtermin au moyen d'un objet de la classe
Style
qui permet par exemple de reprsenter un point sur la carte au moyen d'un rond rouge ou bien les lments de la couche plans d'eau" par un polygone bleu clair. Il est galement possible d'acher un texte ct des lments, typiquement la description de l'objet spatial. Les informations ncessaires pour rcuprer et reprsenter chaque couche sont stockes dans un objet de la classe
FeatureInfos.
Chaque couche pos-
sde une description textuelle utilise dans l'interface graphique. Les donnes spatiales de la couche sont rcupres au moyen de la classe d'un objet du type
DataStore
de
GeoTools. La slection des donnes rcuprer peut tre ltre au moyen
Filter.
59
Fig. 5.4 Slection des couches dans MapViewer
Une fois les donnes rcupres, les direntes couches sont assembles dans l'objet
MapContext
qui est pass un objet
StyledMapPane
capable
d'acher la carte et intgrant des outils permettant de zoomer, de se dplacer dans la carte ou d'eectuer des rotations de celle-ci. Nous avons tendu
StyledMapPane
au moyen de
StyledMapPaneFX
ajoutant des eets visuels
supplmentaires comme un zoom progressif sur la carte. MapViewer est une application qui utilise la plupart des possibilits offertes par l'API GeoTools : la rcupration des donnes au moyen des
taStore,
le stockage en mmoire de celles-ci dans
sentation de ces donnes dans un
FeatureSource StyledMapPane.
Da-
et la repr-
StyledMapPane, sont les eets visuels de StyledMapPaneFX, la possibilit de

slectionner les couches acher (gure 5.4 par rapport la gure 5.2) ainsi que les paramtres pour rcuprer les donnes de ces direntes couches. MapViewer permet galement de sauvegarder les cartes visualises sous les formats d'image SVG, PNG et JPG. Les gures 5.2 et 5.1 ont t gnres directement depuis MapViewer.
Les fonctionnalits de l'application, ct des possibilits oertes par
60
Fig. 5.5 Schma UML simpli de l'architecture de Silas
5.5 Vision gnrale

5.5.1 Client - Serveur
L'architecture est divise en deux grandes parties. D'un ct l'ensemble des programmes sur le client (GSM, PDA, ...) et d'un autre ct les programmes hbergs sur le (ou les) serveur(s) applicatif(s). La communication entre le client et le serveur se fait au travers du rseau par le protocole RMI spcique au langage Java. Il a l'avantage d'tre concis (conomie en bande passante) et natif Java (conomie de CPU).
5.5.2 Elments de la plateforme

Les dirents lments de Silas sont le client SilasTalker (dtaill au point 5.7) qui communique avec les services (point 5.6). Les services sont capables de communiquer avec le cur de la plateforme pour l'authentication des utilisateurs ou les outils de gnration des cartes. Chaque concepteur de service doit crire le code des EJB de son service ainsi que les classes Java utilises dans le client pour accder son service. La partie client se limite uniquement la logique et l'achage graphique ncessaire au service. Les services sont en fait des plugins ajouts SilasTalker et ne doivent pas tenir compte de la gestion des erreurs de communication, l'identication des utilisateurs, le lancement des services, . . .
61
5.6 Middleware J2EE

Nous allons d'abord introduire les fonctionnalits de la plateforme avant de prsenter le code de manire plus technique.
5.6.1 Session
Le fonctionnement des sessions est similaire au fonctionnement de sessions sur les sites Web. Aprs s'tre identi sur la plateforme au moyen de leur nom d'utilisateur et leur mot de passe, les utilisateurs reoivent une cl de session gnre par la plateforme. Cette cl est stocke dans la base de donnes de Silas et, chez le client, dans un objet similaire un cookie. Le mot de passe n'est ainsi transmis qu'une seule fois par session sur le systme. Les services ayant par la suite besoin d'authentier un utilisateur recevront de celui-ci son nom d'utilisateur (
login ) et sa cl de session.
La validit de la session s'arrte soit lorsque l'utilisateur se dconnecte soit lorsqu'une priode de temps prdnie est coule (
timeout ).
5.6.2 Services avec ou sans identication

Deux types de services peuvent tre proposs l'utilisateur : les services avec authentication qui ncessite que l'utilisateur communique son n'importe quel utilisateur. Les services avec authentication ne recevant que la cl de session et le nom de l'utilisateur doivent faire appel au cur de la plateforme an de vrier la validit de la session.
login
et sa cl de session et les services sans authentication capables de servir
5.6.3 Souscription payante aux services

La souscription payante aux services est un problme compliqu. Dirents modes de facturation existent, l'abonnement, l'utilisation ou encore au nombre d'octets transfrs. Les modles tant multiples et l'intrt d'intgrer un de ces modles de manire pousse tant relativement faible nous avons dcid de ne pas inclure de systme de souscription. Cependant, voici comment l'on pourrait construire des services payants partir de la plateforme actuelle. Des services base d'abonnement peuvent facilement tre grs partir de l'identication. Il leur sut de conserver la liste de leurs abonns et ainsi ne rpondre qu'aux requtes des utilisateurs ayant pay. Les services souhaitant utiliser le paiement l'utilisation pourraient, avant de rpondre la requte de l'utilisateur, faire appel un service de facturation indpendant des dirents services. Ce service aurait pour tche de limiter les abus, par exemple en ayant pour chaque utilisateur une liste de services pouvant et ne pouvant pas facturer. Ce qui revient imposer de
62
l'opt-in. Le service de facturation pourrait galement avoir, pour chaque utilisateur, un montant maximal mensuel an d'viter les mauvaises surprises en n de mois. Le paiement au nombre d'octets transfrs est plus compliqu grer, notre plateforme n'a aucune mthode prvue pour compter le volume des communications gnres par l'utilisation des services.
5.6.4 Services en cascade

Un service (service appelant) ayant reu le nom d'un utilisateur et sa cl de session peut utiliser ces donnes pour faire appel un autre service (service appel) et ainsi tendre ses possibilits. Le service appelant fait appel au service appel et peut obtenir de celui-ci les donnes relatives l'utilisateur. Par exemple, un service de calcul d'itinraire peut faire appel un service de cartographie an d'obtenir une carte de la zone de l'utilisateur et superposer le calcul d'itinraire cette carte. Le client n'eectue qu'une requte au service d'itinraire qui lui-mme fera appel au service de cartographie. Les communications entre les clients et le service sont ainsi limites. Cela engendre cependant du trac entre les dirents serveurs hbergeant les services mais ces connexions sont laires et haute capacit ce qui rend leur cot moindre par rapport au cot des communications entre le service et l'appareil mobile du client.
5.6.5 La super-classe ServiceBean

Les services peuvent tendre la super-classe abstraite gestion des utilisateurs : 1. checkUser(String username) permet de vrier que l'utilisateur existe bien. 2. checkSession(String username, String sessionKey) permet de vrier que la session de l'utilisateur est valide. 3. getLastPos(String username, String sessionKey) permet de rcuprer la dernire position d'un utilisateur. 4. isLogged(String username) permet de vrier qu'une session est en cours pour l'utilisateur. 5. getDescription() est une mthode abstraite que la sous-classe doit rednir et qui renvoie une description du service. Nous voyons que pour rcuprer la dernire position d'un utilisateur, le service doit avoir reu la dernire cl de session de cet utilisateur. Cela l'empche donc d'avoir accs aux donnes de l'utilisateur aprs qu'il aie ferm sa session.
ServiceBean
qui est
capable de communiquer avec la plateforme Silas et appeler les mthodes de
63
Il faut noter que bien que son nom contienne le mot Bean,
ServiceBean
n'est en fait pas un EJB. En eet, les EJB doivent pouvoir tre instancis et eectuer une certaine logique mtier, ce qui n'est pas le cas ici puisque nous avons aaire une classe abstraite. Les EJB des services devront implmenter l'interface
SessionBean
de J2EE comme pour tout EJB de session classique.
5.6.6 HistoryBean
La position des utilisateurs doit tre sauvegarde dans les bases de donnes de la plateforme Silas. Rgulirement, le client informe la plateforme de sa nouvelle position, HistoryBean reoit cette position et la stocke dans une table prvue cet eet. En plus de la position et du nom de l'utilisateur, la table contient galement l'instant o cette position a t reue par la plateforme Silas. Cela permet de conserver un historique complet d'un utilisateur et de fournir des services qui seraient bass sur plus que la dernire position de l'utilisateur. Pour faciliter l'accs la dernire position d'un utilisateur, une vue a t cre ne contenant que la dernire position de chaque utilisateur (voir C.4.2 la page 90). Les positions sont galement utilises pour simuler des services de type push.
5.6.7 Achage de cartes
Fig. 5.6 Carte et position de l'utilisateur dans SilasTalker
64
Le serveur de Silas est capable, grce l'API GeoTools, de manipuler de nombreuses sources de donnes spatiales an de gnrer des cartes sur lesquelles d'autres services peuvent ajouter des donnes. Une image est ensuite gnre (sous un format compress pour diminuer le volume de donnes faire transiter par le rseau) et transfre l'utilisateur au moyen d'une liste d'octets. Pour illustrer ceci, nous avons cr l'EJB gure 5.6).
MapperBean
et un plugin
achant la carte de Spearsh qui est une image reue au format PNG (voir
5.6.8 Structure du code
Fig. 5.7 Structure des packages du serveur Silas
La plateforme Silas est compose de quatre packages : le package
lbs
qui contient les EJB ncessaires aux fonctionnalits de base : identication, authentication, historique, dcouverte de services et achage de cartes ; le package avec les EJB du package
ServiceBean
interfaces contenant les interfaces permettant de communiquer lbs, le package service contenant la classe abstraite
tendue par les services dploys sur la plateforme et le package
utils comprenant les classes reprsentant les exceptions gnres par Silas,
les classes communes avec le client, les classes permettant de gnrer les cartes et les classes capables de gnrer des images partir des cartes.
5.6.9 Le package mfe.silas.lbs

Ce paquet est principalement compos des classes suivantes :
UserInfosBean :
c'est un EJB entit contenant les informations des utili-
sateurs. Les informations conserves sont le nom de l'utilisateur (login), son mot de passe (password), la cl de session gnre au dbut de la
65
Fig. 5.8 Structure du package mfe.silas.lbs
66
session (sessionKey), l'heure et la date du dbut de cette session (lastLogin) et une valeur boolenne indiquant si l'utilisateur est connect ou non (isLogged).
UserLoginBean :
cet EJB utilise
UserInfosBean
et gre les connexions
(login, logout) et les inscriptions (signin). C'est galement dans cette classe que la cl de session est gnre (generateSessionKey), sauvegarde dans UserInfosBean et renvoye l'utilisateur dans un objet
Session.
Cet EJB contient les mthodes appeles par
UserServiceBean :
checkSession, checkUser, isLogged et getPosition.
GateBean :
cet EJB sert dcouvrir les services, il se connecte une base
de donnes pour rcuprer les services disponibles pour un utilisateur sa position actuelle. Ensuite, l'utilisateur peut slectionner le service et ventuellement tlcharger le plugin pour le client s'il ne le possde pas encore.
HistoryBean : MapperBean :
c'est l'EJB expliqu plus haut qui gre l'historique des
positions des utilisateurs. cet EJB est un service relativement simple qui ache la
position d'un utilisateur sur une carte. Il renvoie une image (PNG, JPEG, SVG, ...) ce qui a l'avantage d'tre plus compact et donc de consommer moins de bande passante que d'envoyer l'ensemble des informations sous forme vectorielle.
5.6.10 Le package mfe.silas.utils

Les exceptions
Un ensemble d'exceptions peuvent tre envoyes au client en cas d'erreur. Le client doit tre capable de grer ces exceptions lorsqu'elles surviennent. Cependant, certaines de ces erreurs sont prises en charge par les services de la plateforme (par exemple les erreurs de connexion aux bases de donnes).
AlreadyExistingUserException
indique que le nom d'utilisateur existe
dj lorsqu'on essaie de crer un compte avec un login dj utilis.
ExpiredException indique que la session a expir. UnexistingUserException indique que l'utilisateur n'existe pas, par exemple
lorsqu'on essaie de s'identier avec un login inexistant.
UnloggedException
teur.
indique qu'aucune session n'est active pour l'utilisa-
ConnectionException indique qu'il y a eu un problme de connexion. UnknownPositionException survient lorsque la position de l'utilisateur
est inconnue.
67
Classes en commun avec le client

Les classes suivantes sont utilises par le serveur et par le client :
GPSPosition
reprsente une position de l'utilisateur et est compos des
coordonnes et de la prcision en mtres de cette position.
ServiceDescription
contient les informations reues par l'application client
propos d'un service : une description textuelle du service, le numro de la version du service, l'URL du chier JAR lancer l'interface graphique du plugin. Les interfaces clients et la structure des plugins sont dtaills la section 5.7.3
3 tlcharger pour ac-
tiver le service et le nom de la classe Java principale du service pour
Donnes de la carte
Pour faciliter la gnration de carte, la classe
SilasMap
permet de rcu-
prer les couches de la carte Spearsh et des styles standards utilisables pour acher ces couches (rivires en bleu, routes en jaune avec bord orange, zone restreinte en gris transparent, ronds rouges, triangle avec texte, ...). Rien n'empche bien sr de dnir ses propres styles.
Gnration d'images Le package mfe.silas.utils.image

nrer, partir d'une carte (classe format SVG, JPG et PNG.
MapContext
contient des classes capables de gde GeoTools) des images au
5.7 Le client SilasTalker

Le client est compos de deux couches : la couche de prsentation, en Swing, qui permet d'acher les services et la couche de logique qui gre la connexion, rcupre et envoie les informations depuis la plateforme Silas. La couche de prsentation permet simplement d'acher les fentres, les menus et les boutons pour l'utilisateur. Cette couche fait appel aux fonctions de la couche logique qui va rellement eectuer les actions demandes par l'utilisateur. Pour garder la vision traditionnelle des trois couches, on peut dire que la couche de prsentation est l'interface graphique, que la couche logique est partage entre les services sur le serveur applicatif et la couche logique du plugin et que la couche de donnes est compose des bases de donnes accessibles depuis les services.
chier compress contenant des classes Java
68
Fig. 5.9 Diagramme UML du client SilasTalker
69
Chaque couche utilise un ensemble de fonctions des autres couches pour communiquer avec elles. Prenons l'exemple d'une identication russie d'un utilisateur. Au dbut, l'utilisateur voit devant lui une fentre graphique en Java avec deux champs nom d'utilisateur et mot de passe ainsi qu'un bouton Login. Aprs avoir rentr ces informations et que l'utilisateur appuie sur le bouton Login, la couche graphique va passer ces donnes la couche logique du plugin qui va aller communiquer avec la couche logique de la plateforme Silas an que celle-ci valide le couple (nom d'utilisateur, mot de passe) en vriant les donnes dans les bases de donnes (couches de donnes). La plateforme Silas rpond (de manire positive) et gnre une cl temporaire, valide pour la dure de la session de l'utilisateur. C'est la couche logique du client qui reoit ces donnes, les stocke pour une utilisation future dans un cookie et renvoie la couche graphique un signal pour lui indiquer que tout s'est bien droul. L'avantage d'une telle approche est que les couches sont spares et peuvent donc tre modies sans inuencer les autres couches. Par exemple, si l'on dcide de changer les bases de donnes, grce l'utilisation d'interfaces standard de communication avec ces bases de donnes, la couche logique ne devra pas tre modie. De la mme manire, on peut rcrire la couche graphique pour par exemple crer un client en J2ME spcique un modle de tlphone.
5.7.1 couche graphique

La couche graphique tourne autour des classes ClientGUI et ClientGUIManager. ClientGUI, qui hrite d'un JFrame4 , est la base de la couche graphique prsente l'utilisateur : elle gre l'achage des menus ainsi que les JPanel spciques aux services ou Silas. Les JPanel de Silas sont les panels d'identication, d'enregistrement, de choix de services, . . .Les JPanel spciques aux services sont, par exemple, pour un systme FriendFinder, une carte de la zone o l'on se trouve avec des points reprsentant soi-mme et ses amis. Chaque service dnit un JPanel qui sera excut par La classe
ClientGUIManager
ClientGUI.
a pour tche principale de grer les excep-
tions que le plugin n'a pas grer (problmes de dconnexion, utilisateur non identi, ...) au moyen de la mthode manageException(). A ct de cela,
ClientGUIManager
est galement connu des services lancs et permet
ceux-ci d'ajouter un menu l'interface graphique le JPanel ach et d'accder la couche logique.
ClientGUI
et de changer
Fentre graphique en Java, issue de la librairie Swing pouvant contenir de JPanel,
JMenu, . . .
70
5.7.2 couche logique

La couche logique permet de grer les communications avec la plateforme Silas. Sa classe principale est
ClientCommon
qui regroupe l'ensemble
des fonctions de bases permettant de communiquer avec le serveur applicatif, de grer l'enregistrement et l'authentication de l'utilisateur ainsi que de connatre la position la plus prcise de l'appareil. La position des utilisateurs est connue au moyen d'un (ou plusieurs) objet du type gr par un
PositionnerManager
Positionner,
qui a pour but de slectionner l'lment de
localisation le plus prcis. Rgulirement, la position est communique au serveur Silas an d'tre utilise dans les services ou bien pour tre utilise dans des services du type push qui ont besoin de connatre rgulirement les utilisateurs entrant dans leur zone.
5.7.3 Le systme de plugins pour les services

Lorsqu'un utilisateur souhaite lancer un service, il doit possder le code ncessaire au fonctionnement de ces services, c'est dire la couche logique correspondante et l'interface graphique du service. Pour permettre aux dveloppeurs de services de se concentrer uniquement sur leurs services, nous avons dcid d'utiliser un systme de plugin. Le client SilasTalker n'intgre pas le code des dirents services la premire fois qu'il est lanc. Lorsqu'un utilisateur souhaite utiliser un service, il cherche des services depuis le menu du client (ServiceFinder) . Il reoit alors une liste de services disponibles sa position actuelle qu'il peut lancer. Pour qu'un service puisse tre lanc depuis l'application client, il faut deux choses : 1. Crer un chier JAR qui contient une classe hritant de
ServiceClient
ServiceClient.
est une classe dnissant uniquement un constructeur
auquel on passe comme paramtre un
ClientGUIManager. Cela permet
au service d'avoir accs la couche logique du client de base, d'ajouter des menus au client ou encore de changer le JPanel ach. Le chier JAR sera tlcharg par le client. 2. Faire connatre le nom de la classe hritant de ServiceClient. Pour cela, il s'inscrit dans la base de donnes gre par le serveur Silas. Lorsque l'utilisateur lance ServiceFinder, le client SilasTalker communique avec le serveur Silas qui lui renvoit des objets du type
viceDescription
client.
Ser-
contenant entre autres l'URL du JAR et le nom de la
classe (voir point 5.6.10). C'est cette classe qui est alors lance par le
71
5.8 Packages pour dveloppeurs

Pour permettre le dveloppement des services, nous avons besoin de crer de fournir deux chiers JAR (chier compress contenant des classes Java) : 1.
SilasTalkerClient.jar contient la classe ServiceClient (dont hrite les

JPanel des services) et les classes utilises par
2.
SilasService.jar contient la classe

et les outils du package utils.
ServiceClient. ServiceBean (dont hrite
les EJB
des services), les interfaces pour accder au cur de la plateforme Silas
Ensuite, il faut inscrire le service dans la base de donnes que consulte ServiceFinder pour que les utilisateurs puissent trouver le service. Cependant, on peut crer un service pour une utilisation restreinte et donc sans s'inscrire sur ServiceFinder (par exemple lors de la phase de dveloppement), il sut pour cela d'avoir le chier JAR du plugin et de connatre le nom de la classe qui hrite de plugin.
ServiceClient
pour que SilasTalker puisse lancer le
5.9 Amliorations
5.9.1 Web Services
A ct des communications en RMI, on peut tendre les possibilits de la plateforme en utilisant les services web. J2EE en version 1.4 propose une architecture standard implmente par un plugin de JBoss. Ensuite, il faudrait adapter le client actuel pour qu'il parse le code XML gnr ou mieux, crer un client dans un autre langage que Java qui serait capable de communiquer avec la plateforme Silas.
5.9.2 Cartes
Il y a un embryon de systme dcoupant les cartes en un quadrillage compos de morceaux de cartes. Lorsqu'on souhaite se dplacer sur une carte, il serait intressant de ne pas devoir retlcharger l'entiret de la carte mais uniquement les nouvelles zones apparues. Par exemple en divisant la carte ache en neufs rectangles et lorsqu'on souhaite acher ce qu'il y a droite de la zone actuellement visualise, il ne faudra tlcharger que les 3 rectangles droite des 9 dj visibles. Ainsi on diminue les volumes transitant par le rseau. Ce systme est dj mis en place sur la plupart des services de cartographies sur le Web.
5.9.3 Poisoning
Les services voluent dans le temps, il pourrait tre intressant d'intgrer un systme de poisoning, c'est--dire de supprimer sous certaines conditions
72
Fig. 5.10 Systme de dcoupage pour les cartes
les JAR des services tlchargs an qu'ils se mettent jour. Un tel systme permettrait galement, si l'on sort de la zone de couverture d'un service, de supprimer le JAR devenu inutile.
73
Chapitre 6
Ralisation du scnario
6.1 Introduction
Notre scnario expos au point 4.2 demande la construction de deux services : GeoMail pour envoyer et recevoir des messages un lieu donn et FriendFinder pour acher la position de ses amis. Nous allons montrer comment on peut utiliser la plateforme dveloppe pour raliser ces deux services. Des morceaux de code Java montrent ensuite l'utilisation en pratique de la plateforme.
6.2 GeoMail
Pour GeoMail, il nous faut d'abord avoir une base de donnes capable de stocker les messages des utilisateurs. Nous avons opt pour une table contenant les champs (Date),
message
from
(String) et
SessionBean message
et
Il faut ensuite crer un
to (String), precision (int), timestamp the_geom (Point). Bean, qui tend ServiceBean et qui implmente
(String), contenant la valeur des champs
contenant deux mthodes : GetMessage() et PostMessage().
Pour faire transiter les messages entre le client et le service, on utilise une classe srialisable,
where.
GeoMessage,
from, to,
6.2.1 PostMessage
Le code est relativement simple : 1. On vrie la session de l'utilisateur avec checkSession() hrit depuis
ServiceBean. ServiceBean.
2. On vrier que le destinataire existe avec checkUser() hrit depuis
3. On se connecte la base de donnes avec JDBC. 4. On insre les donnes avec JDBC.
74
CHAPITRE 6. RALISATION DU SCNARIO
6.2.2 GetMessage
La rception d'un message est galement simple : 1. On vrie la session de l'utilisateur avec checkSession(). 2. On se connecte la base de donnes avec JDBC. 3. On eectue une requte SQL permettant de rcuprer les messages qui sont destins l'utilisateur en tenant compte de la zone de validit du message. 4. On met la liste des messages dans un Vector qu'on renvoie au client.
6.2.3 Client GeoMail

Le client GeoMail est compos d'une classe capable de communiquer avec l'EJB au travers de RMI et d'une interface graphique qui tend ServiceClient. L'interface graphique permet de poster et de recevoir des messages (gures 6.3 et 6.4).
6.3 FriendFinder
Le service FriendFinder est lgrement plus compliqu car il utilise les outils de gnration de cartes et prend donc beaucoup de lignes pour dnir les couches de la carte superposer et le style de ces couches. Du point de vue bases de donnes, on a besoin de conserver qui est l'ami de qui ainsi que les cls de session des personnes connectes au service pour pouvoir demander leur dernire position la plateforme Silas. On cre deux mthodes dans l'EJB : getFriends() et getFriendsName() permettant de rcuprer les positions et les noms des amis d'un utilisateur depuis la base de donnes. Ensuite, on utilise les classes dans le package utils de la plateforme Silas pour rcuprer les couches des cartes correspondant aux routes et aux cours d'eau. A ces deux couches, on ajoute la couche des amis reprsents par un carr vert et leur nom d'utilisateur et la couche contenant la position de l'utilisateur (rond rouge). On zoome la carte sur la zone contenant les deux utilisateurs (avec un espace de bordure), on gnre l'image (au format PNG) qu'on envoie sous forme d'octets au client. Celui-ci rcupre les octets, en gnre une image (classe ImageIcon) et la place sur un JPanel qui est ach par SilasTalker (voir gure 6.3). Le code crire pour le client prend moins de 100 lignes, en comptant le code permettant de se connecter au service. Le code crire pour l'EJB du service prend environ 250 lignes, une grande partie servant rcuprer les donnes de la base de donnes, les placer sur une couche compatible avec l'API GeoTools et spcier le style de ces couches (par exemple carr vert avec texte pour les amis).
75
6.4 Exemples de code

Voici quelques exemples de code montrant comment utiliser les outils proposs par la plateforme Silas.
6.4.1 Utiliser les mthodes de ServiceBean

Voici un bout du code de GeoMailBean. Les variables to, from et sessionKey correspondent l'expditeur, le destinataire et la cl de session de l'expditeur :
try
// V r i f i e l a s e s s i o n
c h e c k S e s s i o n ( from , sessionKey ) ;
// V r i f i e que l e d e s t i n a t a i r e e x i s t e
checkUser ( to ) ;
// Rcupre l a d e r n i r e p o s i t i o n
} } } }
catch catch catch
GPSPosition
pos = g e t L a s t P o s ( from ) ; e) {
// U t i l i s a t e u r from non l o g g // U t i l i s a t e u r from ou t o i n e x i s t a n t // Erreur l a c o n n e c t i o n s avec l a p l a t e f o r m e

( ConnectionException e) { ( UnexistingUserException e) {
( UnloggedException
6.4.2 Crer une carte

Pour crer une carte, il faut d'abord crer un
MapContext,
lui ajouter
des couches, leur appliquer un style et puis en faire une image. SilasMap fournit des styles standards (rivires en bleu, routes jaunes, ...) et l'accs aux couches de la carte Spearsh. MapContext map = SilasMap
silasmap =
new D e f a u l t M a p C o n t e x t ( ) ; new S i l a s M a p ( ) ;
silasmap . getRoadsStyle ( ) ) ; silasmap . getStreamsStyle ( ) ) ;
//On a j o u t e l e s r o u t e e t l e s r i v i r e s
map . a d d L a y e r ( s i l a s m a p . g e t F s R o a d s ( ) , map . a d d L a y e r ( s i l a s m a p . g e t F s S t r e a m s ( ) ,
//On c r e l a bordure de l ' image ( e n v e l o p p e ) // i c i c ' e s t l e s b o r d s de l a c a r t e S p e a r f i s h

Enveloppe e n v = map . g e t L a y e r B o u n d s ( ) ;
76
//On t r a n s f o r m e l a c a r t e en image , on s l e c t i o n n e j u s t e l ' e n v e l o p p e

MaptoImage
//On d f i n i t l a t a i l l e de l ' image de s o r t i e
m2i =
new
MaptoImage ( map ,
env ) ;
m2i . s e t C a n v a s S i z e (
new
j a v a . awt . D i m e n s i o n ( 3 0 0 , output =
200));
try
} }
ByteArrayOutputStream {
new
ByteArrayOutputStream ( ) ;
//On sauve en PNG

m2i . toPNG ( o u t p u t ) ;
catch
// Erreur l a g n r a t i o n de l ' image
( IOException
ioe )
// o u t p u t c o n t i e n t l e s o c t e t s de l a c a r t e en PNG
6.5 Scnario
Pour illustrer le fonctionnement du scnario, voici le droulement de celuici : Alice lance SilasTalker, s'identie sur le systme (gure 6.1) et lance FriendFinder dans la liste propose par ServiceFinder (gure 6.2). Comme aucun de ses amis n'est connect, une carte gnrale de la zone est ache avec le rond rouge la reprsentant. Bob se connecte ce moment ; sur l'cran d'Alice, Bob apparat (gure 6.3). Elle dcide de lui envoyer un message (gure 6.3 droite) qui est reu par Bob (gure 6.4).
Fig. 6.1 Alice lance SilasTalker et se connecte
77
Fig. 6.2 Alice lance ServiceFinder et slectionne FriendFinder.
Fig. 6.3 Alice voit Bob et sa position et lui envoie un message
Fig. 6.4 Bob reoit le message d'Alice.
78
Chapitre 7
Conclusion
Les objectifs de ce mmoire taient 1. D'identier les direntes catgories de services golocaliss, d'en tirer les besoins pour une plateforme capable d'accueillir ces services et de crer un scnario utilisant les services golocaliss. 2. De concevoir et raliser une plateforme de services golocalis et un client capable de communiquer avec celui-ci. 3. De s'assurer que la plateforme conue fournisse les outils ncessaires pour facilement crer les services, ct serveur et ct client en ralisant notre scnario. Nous nous sommes donc intresss aux services golocaliss et aux domaines connexes celui-ci comme la cartographie et les projections sur des plans deux dimensions. Ensuite, nous avons tudi les moyens de reprsenter ces donnes spatiales et plus particulirement l'initiative de l'Open Geospatial Consortium. Puisque ces donnes doivent tre manipules dans notre plateforme, les bases de donnes spatiales et leur mode de fonctionnement ont t tudis. Par la suite, nous avons abord la programmation, le choix du langage pour le client, le serveur et la communication entre ces lments. Le choix s'est pos sur la famille Java pour ses avantages multiples. Pour le client, Java est puissant et disponible sur la majorit des architectures et ne ncessite pas ou peu de modications pour tre adapt la plupart des appareils mobiles allant du GSM l'ordinateur portable. Pour le serveur, c'est la spcication J2EE, le standard de fait des serveurs applicatifs, qui a t retenue. Son utilisation est assez complique au dbut mais sa puissance se rvle au fur et mesure qu'on l'utilise. A partir d'un scnario, nous avons identi les dirents besoins de la plateforme que nous avons ensuite implmente. La cration eective de services a t ralise pour le scnario et longuement teste. La conception d'un service au moyen de la plateforme Silas est assez aise pour une personne connaissant Java et ayant des notions de J2EE.
79
CHAPITRE 7. CONCLUSION
Pour conclure, ce mmoire m'a permis d'apprendre beaucoup de choses et de m'initier aux services golocaliss qui feront bientt partie de la vie quotidienne de tout un chacun.
80
Bibliographie
[1] Wikipedia : the free encyclopedy. open database connectivity, avril 2006.
http://en.wikipedia.org/wiki/ODBC.
[2] Wikipedia : the free encyclopedy. systme d'information gographique, avril 2006.
http://fr.wikipedia.org/wiki/GIS.
[3] Wikipedia : the free encyclopedy. systmes godsiques, avril 2006.
http://fr.wikipedia.org/wiki/Systme_godsique.
[4] Eric Armstrong. June 2005.
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/.
The J2EET M 1.4 Tutorial.
Sun Microsystems Inc.,
[5] Patrick Van Campenhout. Belge et gant de la cartographie numrique.
La Libre Belgique, 2005. http://www.lalibre.be/article.phtml?id=

3&subid=152&art_id=226098. http://livre.point6.net/index.php/Accueil.
[6] Gisle Cizault. 2005.
IPv6 thorie et pratique.
Editions O'Reilly, Novembre
[7] Open GIS Consortium.
OpenGIS Implementation Specication for Geographic information - Simple feature access - Part 2 : SQL option. Open
GIS Consortium, revision 1.1 edition, May 1999.
[8] Open GIS Consortium.
OpenGIS Implementation Specication for Geographic information - Simple feature access - Part 1 : Common architecture. Open GIS Consortium, revision 1.1 edition, Novembre 2005.
sing location information in the domain name system, January 1996.
[9] C. Davis, P. Vixie, T. Goodwin, and I. Dickinson. A means for expres-
http://www.ietf.org/rfc/rfc1876.txt.
[10] T D'Roza and G Bilchev. An overview of location-based services.
[11]
arcsde/9.0/.
BT Technology Journal, 21(1) :2027, January 2003. ESRI. ArcSDE v9.0 Developer Help. http://edndoc.esri.com/
[12] George M. Giaglis, Ada Pateli, Kostas Fouskas, Panos Kourouthanassis, and Agrgiris Tsamakos. On the potential use of mobile positioning In technologies in indoor environments.
eEconomy, pages 413429, 2002.
eReality : Construction the
81
BIBLIOGRAPHIE
[13] Ron Lake.
Introduction to gml, 2000.
posdep/GMLIntroduction.html.
http://www.w3.org/Mobile/
[14] BZ Media. Fourth annual java use and awareness study, novembre 2004. [15] Aaron Mulder. Jboss application server, 2005. [16] Gnther Pospischil, Johannes Stadler, and Igor Miladinovic. A locationbased push architecture using sip. In
[17]
4th International Symposium on Wireless Personal Multimedia Communications, 2001. Refractions Research. PostGIS Manual, mars 2006. http://postgis.
refractions.net/docs/.
[18] Jochen Schiller and Ags Voisard. San Francisco, 2004. [19] 3-D Software.
Location-Base Services.
The Morgan
Kaufmann Series in Data Management Systems. Morgan Kaufmann,
Map projections.
Site Web, 2005.
3dsoftware.com/Cartography/USGS/MapProjections/.
[20] NETiKA Internet & Mobile Solutions, Mai 2004. [21] C. M. Thomas and W. E. Featherstone. formula. 2005. [22] Ministerie mobiele van Verkeer en Waterstaat. Site
http://www.
www.geomobile.be.
Validation of vincenty's for131(1) :2026, February
mulas for the geodesic using a new fourth-order extension of kivioja's
Journal of Surveying Engineering,
Plaatsbepaling Web, mars
in
communicatie
netwerken.
2005.
http://www.minvenw.nl/dgg/crn/NavSystemen/Terrestrische_ systemen/gsmumts/index.aspx.
[23] Thaddeus Vincenty. Direct and inverse solutions of geodesics on the ellipsoid with application of nested equations. 93, April 1975.
Survey Review, 23(176) :88
82
Annexes
83
Annexe A
Grammaires WKT
A.1 WKT pour les types spatiaux
<Geometry Tagged Text> := <Point Tagged Text> | <LineString Tagged Text> | <Polygon Tagged Text> | <MultiPoint Tagged Text> | <MultiLineString Tagged Text> | <MultiPolygon Tagged Text> | <GeometryCollection Tagged Text> <Point Tagged Text> := POINT <Point Text> <LineString Tagged Text> := LINESTRING <LineString Text> <Polygon Tagged Text> := POLYGON <Polygon Text> <MultiPoint Tagged Text> := MULTIPOINT <Multipoint Text> <MultiLineString Tagged Text> := MULTILINESTRING <MultiLineString Text> <MultiPolygon Tagged Text> := MULTIPOLYGON <MultiPolygon Text> <GeometryCollection Tagged Text> := GEOMETRYCOLLECTION <GeometryCollection Text> <Point Text> := EMPTY | ( <Point> ) <Point> := <x> <y> <x> := double precision literal <y> := double precision literal <LineString Text> := EMPTY | ( <Point > {, <Point > }* )
84
ANNEXE A. GRAMMAIRES WKT
<Polygon Text> := EMPTY | ( <LineString Text > {, < LineString Text > }*) <Multipoint Text> := EMPTY | ( <Point Text > {, <Point Text > }* ) <MultiLineString Text> := EMPTY | ( <LineString Text > {, < LineString Text > }* ) <MultiPolygon Text> := EMPTY | ( < Polygon Text > {, < Polygon Text > }* ) <GeometryCollection Text> := EMPTY | ( <Geometry Tagged Text> {, <Geometry Tagged Text> }* )
A.2 WKT pour les systmes de rfrences spatiaux

<coordinate system> := <projected cs> | <geographic cs> | <geocentric cs> <projected cs> := PROJCS["<name>", <geographic cs>, <projection>, {<parameter>,}* <linear unit>] <projection> := PROJECTION["<name>"] <parameter> := PARAMETER["<name>", <value>] <value> := <number> <geographic cs> := GEOGCS["<name>", <datum>, <prime meridian>, <angular unit>] <geocentric cs> := GEOCCS["<name>", <datum>, <prime meridian>, <linear unit>] <datum> := DATUM["<name>", <ellipsoid>] <ellipsoid> := ELLIPSOID["<name>", <semi-major axis>, <inverse flattening>] <semi-major axis> := <number> (mesur en mtres et positif) <inverse flattening> := <number> <prime meridian> := PRIMEM["<name>", <longitude>] <longitude> := <number> <angular unit> := <unit> <linear unit> := <unit>
85
ANNEXE A. GRAMMAIRES WKT
<unit> := UNIT["<name>", <conversion factor>]
86
Annexe B
Calcul de distance de Vincenty

a et b : les demis-axes majeurs et mineurs de l'ellipsode f : l'crasement (attening) de la Terre : f = (ab) a lat1, lat2 : latitudes des deux points long1, long2 : longitudes des deux points L |long1 long2| U 1 atan((1 f ).tan(lat1)) U 2 atan((1 f ).tan(lat2)) L 2 while | | > 1012 do sin() (cos(U 2).sin())2 + (cos(U 1).sin(U 2) sin(U 1).cos(U 2).cos())2 cos() sin(U 1).sin(U 2) + cos(U 1) + cos(U 2).cos() sigma atan2(sin(), cos()) sin() cos(U 1).cos(U 2).sin() sin() cos2 () 1 sin2 () cos(2.m ) cos() 2.sin(U 1).sin(U 2) cos2 ()
C C 16 .cos2 ()[4 + f.(4 3.cos2 ())] L+(1C).f.sin(). + C.sin().[cos(2.m ) + C.cos().(1 + 2.cos2 (2m ))]
2 2
end while 2
u2 cos ().(a b ) b2 u2 A 1 + 16384 .4096 + u2 .[768 + u2 .(320 175.u2 )] u2 B 1024 .256 + u2 .[128 + u2 .(74 47.u2 )] s b.A( ) B.sin().{cos(2.m ) + B .[cos().(1 + 2.cos2 (m )) 4 B .cos(2.m .(3 + 4.sin2 ()).(3 + 4.cos2 (2m ))]} 6
87
Annexe C
Utilisation de PostGIS
C.1 Introduction
L'ensemble des procdures exposes ici ont t ralises sous Debian GNU/Linux Sid (version unstable au moment de la rdaction de ce rapport). Des milliers de logiciels sont disponibles dans ce qu'on appelle des repository et permettent de facilement installer et mettre jour les logiciels.
C.2 Installation de PostGIS

La premire chose faire est d'installer PostGreSQL, le code source de PostGreSQL et les direntes librairies ncessaire au bon fonctionnement de PostGIS : Proj4 pour les transformations de projections et Geos pour le support des fonctions de test topologiques comme Touches(), Contains(), et d'oprations spatiales du type Union() ou Intersection(). On peut galement installer phpPgAdmin pour visualiser les tables partir d'une interface Web.
$ apt-get install postgresql-8.1 postgresql-server-dev-8.1 $ apt-get install libgeos-dev proj $ apt-get install phppgadmin
Ensuite, il faut tlcharger le code source de PostGIS sur le site ociel (http://postgis.refractions.net/download/). Le code source doit tre dcompress dans l'arborescence du code source :
$ cd /usr/include/postgresql/8.1/server/contrib
On tlcharge, dcompresse, congure le paquet, on construit les libraires, on teste que tout fonctionne correctement et on installe la librairie avec les commandes :
88
ANNEXE C. UTILISATION DE POSTGIS
$ $ $ $ $ $
tar xvfz postgis-1.1.1.tar.gz cd postgis-1.1.1 ./configure make make test make install
C.3 Conguration
Pour que PostGreSQL accepte toutes les connexions de l'extrieur, il faut diter le chier pg_hba.conf :
Fichier: /etc/postgresql/8.1/main/pg_hba.conf (...) #CIDR 0 parce que c'est OK pour tous de se connecter host all all 164.15.81.58/0 md5 (...)
Pour indiquer PostgreSQL d'accepter les connexions venant de plusieurs IP/URL et le port utilis, il faut diter le chier postgresql.conf. C'est utile si le serveur applicatif n'est pas situ sur la mme machine que la base de donnes.
Fichier /etc/postgresql/8.1/main/postgresql.conf (...) listen_addresses = 'localhost,memoire.dessalle.be,164.15.81.58' port = 5432
C.4 Crer une base de donnes spatiale

Pour crer une table spatiale, il faut faire les tapes suivantes avec sont fournis dans PostGIS.
nomdb
le nom de la base de donnes. Les chiers lwpostgis.sql et spatial_ref_sys.sql
createdb nomdb createlang plpgsql nomdb psql -d nomdb -f lwpostgis.sql psql -d nomdb -f spatial_ref_sys.sql
C.4.1 Crer une table spatiale

Pour crer une table, voici les tapes suivre. La premire ligne sert prciser qu'on utilise les oids (Object IDs) qui ne sont plus utiliss par dfaut par Postgres dans ses version suprieures 8.1 mais qui est toujours utilis par GeoTools. L'exemple reprsente une table
history
de la base
silas
contenant
89
ANNEXE C. UTILISATION DE POSTGIS
le nom de l'utilisateur (String), la position de cet utilisateur (Point) deux dimensions, utilisant la projection WGS 84 (SRID=4326), le moment o l'utilisateur tait cet endroit (timestamp).
SET default_with_oids = true; CREATE TABLE history ( username text, "timestamp" timestamp with time zone ); select AddGeometryColumn('silas','history','the_geom','4326','POINT',2);
C.4.2 Crer une vue spatiale

Pour crer une vue utilisable par GeoTools qui donne la dernire position de chaque utilisateur, voici les commandes SQL eectuer :
SET default_with_oids = true; CREATE OR REPLACE VIEW last_pos AS SELECT oid, username, the_geom, "timestamp" FROM history WHERE (history."timestamp" = (SELECT max(h2."timestamp") AS max FROM history h2 WHERE (h2.username = history.username))); INSERT INTO "geometry_columns" VALUES('', 'public', 'last_pos', 'the_geom', 2, 4326, 'POINT');
Aprs, la vue peut tre utilise comme n'importe quelle table. L'important est d'avoir un OID (Object ID) et une entre dans geometry_columns ( la main car pas gnr par la cration de vue). Les classes de GeoTools ont besoin d'avoir une entre dans la table geometry_colums an de connatre le type des donnes spatiales.
90
Annexe D
Eclipse et JBoss
D.1 JBoss
L'installation de JBoss se fait graphiquement et est trs simple. La documentation ocielle est l'url :
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossInstallation
On lance jBoss Installer (en rutilisant par exemple le java install avec la JDK) :
$ java -jar jboss-4.0.3SP1-installer.jar

On lance run.sh dans le dossier bin de JBoss pour lancer JBoss. Pour utiliser les librairies GeoTools dans les EJB programms sous JBoss, il faut ajouter les chiers JAR correspondant dans le dossier lib de JBoss. Si on utilise la conguration de serveur appele default, les JAR doivent tre mis dans
$JBOSS_HOME/server/default/lib
D.2 Eclipse
L'installation d'Eclipse est trs simple et se rsume dcompresser l'archive tlcharge sur le site ociel
1 et on peut lancer directement ./eclipse 2
L'installation du plugin JBoss IDE se fait en utilisant le gestionnaire de plugin d'Eclipse. Sur le site de JBoss , on tlcharge l'archive JBoss IDE correspondant la version de JBoss utilise. Ensuite on dcompresser l'archive, on obtient deux dossiers : features et plugin.
1 2
www.eclipse.org www.jboss.org
91
ANNEXE D. ECLIPSE ET JBOSS
Il faut ensuite lancer Eclipse, et aller dans le menu Help->Software Updates->Find & Install On choisit New Local Site" et on slectionne le dossier o on a extrait l'archive. On peut ensuite congurer Eclipse en lui indiquant l'emplacement du serveur JBoss en suivant les instructions de l'article
opensource/Article/20242.
http://www.devx.com/
92

Des 2006 Masters Thesis

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Des 2006 Masters Thesis

Hochgeladen von

Copyright:

Verfügbare Formate

Universit Libre de Bruxelles Facult des Sciences Appliques Service Informatique et Rseaux

Anne acadmique 2005-2006

Conception et ralisation d'une plateforme de dploiement de services golocaliss

Directeur de Mmoire : Esteban Zimnyi

Table des matires

Qui seront les futurs acteurs ? . . . . . . . . . . . . . .

TABLE DES MATIRES

3 Les donnes spatiales

Open Geospatial Consortium

Les bases de donnes spatiales . . . . . . . . . . . . . . . . . .

Cration et manipulation de donnes spatiales . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

TABLE DES MATIRES

5.3.1 5.3.2 5.4 5.5

Le jeu de donnes Spearsh . . . . . . . . . . . . . . . Le jeu de donnes Frida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MapViewer 5.5.1 5.5.2

couche graphique . . . . . . . . . . . . . . . . . . . . . Le systme de plugins pour les services . . . . . . . . .

FriendFinder 6.4.1 6.4.2

Exemples de code . . . . . . . . . . . . . . . . . . . . . . . . . Utiliser les mthodes de ServiceBean . . . . . . . . . . Crer une carte . . . . . . . . . . . . . . . . . . . . . .

TABLE DES MATIRES

B Calcul de distance de Vincenty C Utilisation de PostGIS

Crer une vue spatiale . . . . . . . . . . . . . . . . . .

Table des gures

Projection cylindrique rgulire, transverse et oblique [19]

Slection des couches dans MapViewer . . . . . . . . . . . . .

TABLE DES FIGURES

5.5 5.6 5.7 5.8 5.9

1.2 Objectifs du mmoire

1.3 Organisation du rapport de mmoire

Location-Based Services ). On va commen-

2.2 Vue gnrale

CHAPITRE 2. SERVICES GOLOCALISS

Fig. 2.1  Architecture LBS.

CHAPITRE 2. SERVICES GOLOCALISS

2.3 Exemples de services golocaliss

CHAPITRE 2. SERVICES GOLOCALISS

2.4 Types de services

CHAPITRE 2. SERVICES GOLOCALISS

2.4.2 Positionnement de personnes et d'appareils

2.4.3 Services dirents selon la position

2.5 Dangers et abus

CHAPITRE 2. SERVICES GOLOCALISS

2.6 Mthodes de positionnement

CHAPITRE 2. SERVICES GOLOCALISS

CHAPITRE 2. SERVICES GOLOCALISS

Fig. 2.2  Tlphone dans une cellule

2.6.2 Rseaux cellulaires

CHAPITRE 2. SERVICES GOLOCALISS

Fig. 2.3  Positionnement par Timing Advance [22]

moins il faut d'antennes pour cou-

1 la plus proche, on peut positionner le tlphone

CHAPITRE 2. SERVICES GOLOCALISS

Fig. 2.4  Positionnement par Time of Arrival [22]

Time of Arrival (TOA)

Angle of Arrival (AOA)

CHAPITRE 2. SERVICES GOLOCALISS

Fig. 2.5  Positionnement par Angle of Arrival [22]

2.6.3 Positionnement indoor

CHAPITRE 2. SERVICES GOLOCALISS

Fig. 2.6  Positionnement par E-OTD [22]

2.6.4 Positionnement par WiFi

3 dans les gares, les restaurants ou les stations-service

qui peut ensuite tre connect d'autres rseaux comme Internet.

CHAPITRE 2. SERVICES GOLOCALISS

2.6.5 Positionnement sur Internet

Le jeu de donnes Spearsh . . . . . . . . . . . . . . . Le jeu de donnes Frida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table des gures

Fig. 2.1 Architecture LBS.

2.4.3 Services dirents selon la position

Fig. 2.2 Tlphone dans une cellule

Fig. 2.3 Positionnement par Timing Advance [22]

Fig. 2.4 Positionnement par Time of Arrival [22]

Fig. 2.5 Positionnement par Angle of Arrival [22]

Fig. 2.6 Positionnement par E-OTD [22]

Application Program Interface, c'est dire un ensemble de mthodes rutilisables an

Fig. 3.1 Gode, sphre et ellipsode

WGS 84 pour World Geodesic System 1984, qui a t revu en 2004

Fig. 3.2 Datums locaux

Fig. 3.3 Projection cylindrique rgulire, transverse et oblique [19]

Fig. 3.4 Zones UTM de la France et de la Belgique

Fig. 3.5 Projections coniques [19]

Fig. 3.6 Projections pseudo-cylindrique interrompue [19]

Fig. 3.7 Projection azimuthale et de Winkel [19]

Fig. 3.8 Projection Armadillo sur un tore [19]

Fig. 3.9 LineString simple et ouverte ; LineString simple et ferme (Li-

tant une ligne brise. Chaque paire de points conscutifs dnissant

(gure 3.9b) hritant de

Fig. 3.11 Schma UML des donnes spatiales OGC

Fig. 3.13 Structure des tables SQL OGC

Tab. 3.1 GEOMETRY_TABLE contenant un objet compos de deux