Académique Documents
Professionnel Documents
Culture Documents
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.
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
ii
2.8
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
20
20 21 21 23 25 26 26 30 31 31 35 35 35 36 36 36 36
Donnes spatiales : OGC . . . . . . . . . . . . . . . . . Autres recommandations de l'OGC . . . . . . . . . . . Structure OpenGIS . . . . . . . . . . . . . . . . . . . . MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . Oracle 10g . . . . . . . . . . . . . . . . . . . . . . . . . DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . Middleware . . . . . . . . . . . . . . . . . . . . . . . .
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
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
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
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
6.5
Scnario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Conclusion Bibliographie
79 80
iv
Annexes
A Grammaires WKT
A.1 A.2 WKT pour les types spatiaux . . . . . . . . . . . . . . . . . . WKT pour les systmes de rfrences spatiaux . . . . . . . .
84
84
84 85
87 88
88 88 89 89 89 90
D Eclipse et JBoss
D.1 D.2 JBoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
91 91
. . . . . . . . . . . . . . . . . . . . . . . . . .
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
vi
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.
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.
Chapitre 2
Services golocaliss
2.1 Introduction
Ce chapitre a pour but de donner une vision gnrale des services golocaliss (galement appels LBS pour
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.
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.
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.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.
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
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).
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
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 ,
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
Les antennes GSM sont parfois appelles stations de base ou Base Station
11
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.
12
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.
13
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].
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
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.
14
cess Point, il sut de pouvoir le reconnatre et de retrouver l'identit unique de l'AP dans une base de donnes.
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].
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
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
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.
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.
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.
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
20
limitations respectives.
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
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.
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.
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
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
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.
25
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.
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.
nearRing)
Fig. 3.10 LineString non simple et ouverte ; LineString non simple et ferme
Curve :
la classe abstraite
Curve
LineString
reprsen-
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
LineString
est un
Li-
premier point du
LinearRing
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
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.
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
Geometry
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.
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.
31
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,
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.
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
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
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.
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.
ArcReader ArcView
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
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.
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
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.
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
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.
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
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.
bytecode
bytecode
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.
simple :
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.
41
multi plateformes :
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.
pement d'une plateforme. Cela permet de faciliter la rutilisation des objets entre les dirents services et de sparer la programmation en
susamment performant :
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 :
(ou libres) et des environnements de dveloppement puissants (comme Eclipse d'IBM) sont disponibles gratuitement.
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.
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
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.
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
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 :
43
sage Service qui permet la communication asynchrone entre composants Java ; JAXP qui permet de lire des chiers XML.
44
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
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.
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.
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.
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.
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 :
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
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
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
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
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.
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
Serveur Silas
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, . . .
54
CHAPITRE 5. IMPLMENTATION
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
CHAPITRE 5. IMPLMENTATION
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.
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-
La table
streams
56
CHAPITRE 5. IMPLMENTATION
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 ).
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
MULTILINES-
La table
rivieres
http://frida.intevation.org
57
CHAPITRE 5. IMPLMENTATION
La table La table (
espacesverts
MULTIPOLYGON
poi POINT ).
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
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
FeatureSource
DataS-
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
58
CHAPITRE 5. IMPLMENTATION
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.
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
Filter.
59
CHAPITRE 5. IMPLMENTATION
Une fois les donnes rcupres, les direntes couches sont assembles dans l'objet
MapContext
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
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,
FeatureSource StyledMapPane.
Da-
et la repr-
60
CHAPITRE 5. IMPLMENTATION
61
CHAPITRE 5. IMPLMENTATION
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 ).
login
62
CHAPITRE 5. IMPLMENTATION
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.
ServiceBean
qui est
63
CHAPITRE 5. IMPLMENTATION
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
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.
64
CHAPITRE 5. IMPLMENTATION
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
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.
UserInfosBean :
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
CHAPITRE 5. IMPLMENTATION
66
CHAPITRE 5. IMPLMENTATION
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 :
UserInfosBean
(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.
UserServiceBean :
GateBean :
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 :
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.
AlreadyExistingUserException
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.
ConnectionException indique qu'il y a eu un problme de connexion. UnknownPositionException survient lorsque la position de l'utilisateur
est inconnue.
67
CHAPITRE 5. IMPLMENTATION
GPSPosition
ServiceDescription
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
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.
MapContext
68
CHAPITRE 5. IMPLMENTATION
69
CHAPITRE 5. IMPLMENTATION
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.
ClientGUIManager
ClientGUI.
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
ceux-ci d'ajouter un menu l'interface graphique le JPanel ach et d'accder la couche logique.
ClientGUI
et de changer
JMenu, . . .
70
CHAPITRE 5. IMPLMENTATION
ClientCommon
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,
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.
ServiceClient
ServiceClient.
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-
classe (voir point 5.6.10). C'est cette classe qui est alors lance par le
71
CHAPITRE 5. IMPLMENTATION
2.
les EJB
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
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
CHAPITRE 5. IMPLMENTATION
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
to (String), precision (int), timestamp the_geom (Point). Bean, qui tend ServiceBean et qui implmente
(String), contenant la valeur des champs
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.
3. On se connecte la base de donnes avec JDBC. 4. On insre les donnes avec JDBC.
74
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.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
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
} } } }
GPSPosition
pos = g e t L a s t P o s ( from ) ; e) {
( UnloggedException
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 ( ) ,
76
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 ( ) ;
catch
( 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).
77
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.
http://fr.wikipedia.org/wiki/Systme_godsique.
[4] Eric Armstrong. June 2005.
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/.
OpenGIS Implementation Specication for Geographic information - Simple feature access - Part 2 : SQL option. Open
GIS Consortium, revision 1.1 edition, May 1999.
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.
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.
81
BIBLIOGRAPHIE
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
Map projections.
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.
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.
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
<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> }* )
86
Annexe B
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.
$ 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
$ $ $ $ $ $
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.
nomdb
createdb nomdb createlang plpgsql nomdb psql -d nomdb -f lwpostgis.sql psql -d nomdb -f spatial_ref_sys.sql
history
de la base
silas
contenant
89
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);
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) :
$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
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
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