Rapport de Mémoire de Fin d'Etudes.
Sujet : Réalisation de librairies réutilisables mettant en avant l'interopérabilité
de la solution Web du Spaceyes avec d'autres technologies
Presentation PFE sur le PIM (Product Information Management)
Rapport pfe ingénieur ilyes issaoui
1. Université de la Manouba
Institut Supérieur des Arts Multimédias de la Manouba
RAPPORT
de Mémoire de Fin d'Etudes
Présenté en vue de l'obtention du titre
d'INGENIEUR EN INFORMATIQUE APPLIQUEE AU MULTIMEDIA
par
Issaoui Ilyes
SUJET :
Réalisation de librairies réutilisables mettant en avant l'interopérabilité
de la solution Web du Spaceyes avec d'autres technologies
Organisme : SPACEYES
Nom du responsable : M. Mohamed Ali El Kar
Encadré par (entreprise): M. Frédéric Trastour
Supervisé par (ISAMM): M. Oualid Khayati
Adresse : Le Colisée Saula - Escalier B, 5ème étage EL MANAR 2 - TUNIS
2. Remerciements
C’est avec le plus grand honneur que je réserve cette page en signe de gratitude et de
reconnaissance à tous ceux qui m’ont aidé dans la réalisation de mon stage.
Mes remerciements s’adressent à messieurs Mohamed Ali El Kar et Frédéric Trastour pour
leur accueil chaleureux et pour m’avoir accepté en tant que stagiaire au sein de la société. Leur
soutien technique et leur suivi m’ont permis d’accomplir ce travail dans de bonnes conditions.
J’exprime également ma profonde reconnaissance à mon encadreur à l’ISAMM : M. Oualid
Khayati pour la qualité d’encadrement dont il m’a fait bénéficier tout au long de la réalisation de ce
projet.
Enfin, un grand merci à ma famille.
3. Rapport de projet de fin d’étude
Table des matières
LISTE DES FIGURES 5
INTRODUCTION GENERALE 1
CHAPITRE 1 INTRODUCTION ET PRESENTATION DU PROJET 2
INTRODUCTION 3
I PRESENTATION DE L’ENTREPRISE 3
1 LES SOLUTIONS 3
2 LES REFERENCES DE L’ENTREPRISE 4
II PRESENTATION DU PROJET 6
1 OBJECTIF DU PROJET 7
2 PUBLIC CIBLE DU PROJET 7
CONCLUSION 8
CHAPITRE 2 ETUDE DE L’EXISTANT 9
INTRODUCTION 10
I SPACEYES3D PLUGIN 10
II LE GEOCODAGE 11
1 GOOGLE 11
2 BING 11
3 OSM 12
4 L’AUTO-COMPLETION 14
III VUES IMMERSIVES 15
IV LES SLIPPY MAPS 2D 15
1 OPENLAYERS 16
2 LEAFLET 17
CONCLUSION 17
CHAPITRE 3 ANALYSE ET CONCEPTION 18
INTRODUCTION 19
I METHODOLOGIE : 19
1 CYCLE DE VIE 19
2 IDENTIFICATION DES ACTEURS 20
II ITERATION 1 (GEOCODAGE) 22
1 ANALYSE ET SPECIFICATION 22
2 CONCEPTION 25
4. Rapport de projet de fin d’étude
III ITERATION 2 (GOOGLE STREET VIEW) 32
1 ANALYSE ET SPECIFICATION 32
2 CONCEPTION 33
IV ITERATION 3 (SLIPPY MAPS) 41
1 ANALYSE ET SPECIFICATION 41
2 CONCEPTION 42
CONCLUSION 49
CHAPITRE 4 REALISATION ET TEST 50
INTRODUCTION 51
I ENVIRONNEMENT DE DEVELOPPEMENT 51
1 CHOIX TECHNIQUE 51
2 ENVIRONNEMENT MATERIEL 52
3 ENVIRONNEMENT LOGICIEL 52
II APERÇU SUR LE TRAVAIL REALISE 52
1 MODULE GEOCODAGE 53
2 MODULE GOOGLE STREET VIEW 57
3 MODULE SLIPPYMAPS 61
CONCLUSION 63
CONCLUSION GENERALE 64
NETHOGRAPHIE 65
5. Rapport de projet de fin d’étude
Liste des figures
FIGURE 1.1 : SPACEYES3D BUILDER 6
FIGURE 1.2 : APPLICATION WEB BASEE SUR SPACEYES3D PLUGIN 6
FIGURE 1.3 : RESULTAT SOUHAITE 7
FIGURE 2.1 : OSM SEARCH SERVICE 13
FIGURE 2.2 : AUTO COMPLETION DE GOOGLE 14
FIGURE 2.3 : GOOGLE STEET VIEW 15
FIGURE 2.4 : EXEMPLE D’UTILISATION DE CALQUE OPENLAYERS 17
FIGURE 3.1 : MODELE EN SPIRALE 20
FIGURE 3.2 : DIAGRAMME DE CONTEXTE 21
FIGURE 3.3 : DIAGRAMME DE CAS D’UTILISATION GENERAL POUR LE DEVELOPPEUR–GEOCODAGE 24
FIGURE 3.4 : DIAGRAMME DE CLASSE DU MODULE DE GEOCODAGE 26
FIGURE 3.5 ETAPES D’EXTRACTIONS DES POINTS LIMITES 27
FIGURE 3.6 : DIAGRAMME DE SEQUENCE GEOCODAGE DETAILLE 1 28
FIGURE 3.7 : DESIGN PATTERN SINGLETON 28
FIGURE 3.8 : DIAGRAMME DE SEQUENCE DE GEOCODAGE GOOGLE 29
FIGURE 3.9: DIAGRAMME DE SEQUENCE DE GEOCODAGE BING/OSM 29
FIGURE 3.10 : DIAGRAMME DE SEQUENCE AUTO-COMPLETION BING/OSM 30
FIGURE 3.11 : DIAGRAMME DE COMPOSANT GEOCODAGE 30
FIGURE 3.12 : DIAGRAMME DE CAS D’UTILISATION POUR LE DEVELOPPEUR – GSV 32
FIGURE 3.13 : DIAGRAMME DE CLASSE GSV 33
6. Rapport de projet de fin d’étude
FIGURE 3.14 : DIAGRAMME DE SEQUENCE GSV 1 34
FIGURE 3.15 : DIAGRAMME DE SEQUENCE GSV 2 36
FIGURE 3.16 : DIAGRAMME DE SEQUENCE GSV 3 38
FIGURE 3.17 : DIAGRAMME DE COMPOSANT GSV 39
FIGURE 3.18 : DIAGRAMME DE CAS D’UTILISATION SLIPPYMAPS - DEVELOPPEUR 42
FIGURE 3.19 : DIAGRAMME DE CLASSE SLIPPYMAPS – OPENLAYERS 43
FIGURE 3.20 : DIAGRAMME DE SEQUENCE SLIPPYMAPS – OPENLAYERS 45
FIGURE 3.21 : DIAGRAMME DE SEQUENCE SLIPPYMAPS – UTILISATEUR 1 46
FIGURE 3.22 : DIAGRAMME DE SEQUENCE SLIPPYMAPS – UTILISATEUR 2 47
FIGURE 3.23 : DIAGRAMME DE COMPOSANT – SLIPPYMAPS 48
FIGURE 4.1 : DIAGRAMME DE CAS D’UTILISATION GENERAL POUR L’UTILISATEUR– GEOCODAGE 54
FIGURE 4.2 : DIAGRAMME DE SEQUENCE POUR L’UTILISATEUR – GEOCODAGE 55
FIGURE 4.3 : GEOCODAGE GOOGLE 56
FIGURE 4.4 : AFFICHAGE DU MARQUEUR 57
FIGURE 4.5 : DIAGRAMME DE CAS D’UTILISATION GENERAL POUR L’UTILISATEUR - GSV 57
FIGURE 4.6 : DIAGRAMME DE SEQUENCE GSV – UTILISATEUR 58
FIGURE 4.7 : GOOGLE STREET VIEW 59
FIGURE 4.8 : GSV – AFFICHAGE DU MARQUEUR 60
FIGURE 4.9 : MARQUEUR FLECHE 60
FIGURE 4.10 : DIAGRAMME DE CAS D’UTILISATION SLIPPYMAPS– UTILISATEUR 61
FIGURE 4.11 : DIAGRAMME DE SEQUENCE SLIPPYMAPS 1 62
FIGURE 4.12 : SLIPPYMAPS - OPENLAYERS 63
7. Introduction générale
Rapport de projet de fin d’étude Page 1
Introduction générale
La géomatique est une discipline ayant pour objectif la gestion des données à référence
spatiale et qui fait appel aux sciences et aux technologies reliées à leur acquisition, leur stockage,
leur traitement et leur diffusion. La géomatique fait appel principalement à des disciplines comme la
topométrie, la cartographie, la géodésie, la photogrammétrie, la télédétection et l'informatique1
.
L'évolution sans cesse croissante de l'informatique appliquée aux systèmes d'informations
géographiques a favorisé le développement de plusieurs outils technologiques d'observation de la
terre via des applications informatiques. Ces opportunités du numérique viennent rendre pertinente
la problématique de la gestion numérique et dynamique des villes comme levier de l'observation
urbaine et du tourisme.
Avec l’apparition de services web gratuits, proposant des fonctionnalités géomatiques
avancées, s’est posé le problème de l’interopérabilité de la solution de cartographie 3D SpacEyes3D
avec ces nouveaux outils. La problématique à la base du projet est donc de développer un ensemble
de composants logiciel permettant de faciliter l’utilisation combinée, au sein d’une même application
web, de SpacEyes3D Plugin et de services web géomatiques.
Dans le présent rapport, nous présentons en détail les étapes que nous avons suivies pour
réaliser nos librairies.
Ce rapport comporte quatre chapitres qui sont organisés comme suit : dans le premier
chapitre, nous présenterons la société SPACEYES et le projet proposé. Dans le deuxième on trouve
l’étude de l’existant. Le troisième chapitre comprend la méthodologie du travail et trois itérations
contenant chacune l’analyse et la conception d’un module de la librairie. Enfin, le quatrième
chapitre présentera les étapes de la réalisation ainsi que les tests effectués.
8. Chapitre 1
Introduction et présentation du projet
Rapport de projet de fin d’étude Page 2
Chapitre 1
Introduction et présentation du projet
Au Sommaire de ce Chapitre
Introduction
Présentation de l’entreprise
Présentation du projet
Conclusion
9. Chapitre 1
Introduction et présentation du projet
Rapport de projet de fin d’étude Page 3
Introduction
Ce stage d’immersion en société s’inscrit dans le cadre de notre formation d’ingénieur en
informatique à l’Institut Supérieur des Arts Multimédias de la Manouba. Le présent travail se déroule
au sein de la société SPACEYES. Nous présentons dans ce chapitre l’environnement du stage à travers
une présentation de l’entreprise et une présentation du sujet proposé.
I Présentation de l’entreprise
La société SPACEYES est spécialisée depuis 10 ans dans l’édition de logiciels de
représentation tridimensionnelle de données géographiques, et met à votre disposition tout son
savoir-faire pour la mise en place de solutions cartographiques 3D.
SPACEYES, spécialisée dans le traitement des images d’observation de la Terre, assure les
développements et la commercialisation de la gamme de logiciel SpacEyes3D, fondée sur l’utilisation
des images d’observation de la Terre au sein d’un outil de survol virtuel temps réel et de maquettage
3D. Cet outil est destiné à tout utilisateur qui souhaite communiquer, expliquer, informer ou
présenter à un public non spécialisé tout type de problématique touchant à la gestion ou à la mise
en valeur d’un territoire.
1 Les solutions
En travaillant en collaboration avec de nombreux partenaires citant : GEOimage qui offre
une large gamme de cartes digitales pour la télécommunication, les plans urbains, Geomod dont
les activités concernent les domaines de la géomatique et de la modélisation du cycle de l'eau, et
OpsiGAIA qui produit des plans d’information strictement adaptés aux besoins, aux moyens et aux
outils de gestion des collectivités territoriales, SPACEYES propose l’ensemble des produits suivant :
- SpacEyes3D Builder est la solution logicielle complète de survol temps réel et de maquettage
3D. Complément indispensable pour un SIG, il permet de visualiser en 3D toutes vos données
cartographiques, et de créer des présentations 3D innovantes.
- SpacEyes3D Server s’appuie sur une technologie de streaming innovante pour une diffusion
grand public, sur Internet, de maquettes 3D à l’échelle d’un territoire. La solution SpacEyes3D
Server permet la mise à disposition sur Internet des maquettes 3D réalisées à partir de
SpacEyes3D Builder.
- SpacEyes3D Viewer est un logiciel autonome permettant de naviguer et de consulter en
temps réel, des maquettes 3D préalablement construites avec SpacEyes3D Builder. Ces maquettes
peuvent être accédées localement ou à distance depuis un serveur SpacEyes3D Server.
- SpacEyes3D Plugin est un composant permettant d’intégrer la technologie SpacEyes3D dans
une application classique ou dans une application web.
Elle propose également l’ensemble les services de :
- Maquettes 3D : réaliser une maquette 3D virtuelle évolutive où seront mis en valeur les
aspects touristiques, urbains, immobiliers, environnementaux d’un territoire. Elle offre : une
maquette virtuelle adaptée aux besoins et budgets du client, une interface personnalisée (choix
10. Chapitre 1
Introduction et présentation du projet
Rapport de projet de fin d’étude Page 4
des thèmes, charte graphique…), la possibilité de diffuser une maquette sur Internet (durée
personnalisée), et la mise à jour d’une maquette.
- Hébergement : SpacEyes propose une solution complète d'hébergement de maquettes 3D
sur serveurs dédiés. Cette solution est destinée aux organismes souhaitant mettre en ligne leurs
maquettes 3D, sans avoir à les administrer au jour le jour. Elle se charge d'installer et configurer
les serveurs et de les administrer quotidiennement. Ce service comprend :
la location d'un ou plusieurs serveurs physiques,
une ou plusieurs licences de SpacEyes 3D Server pour la diffusion des données,
un serveur de base de données pour la mise à disposition des données vectorielles,
un serveur Web - pour le téléchargement de SpacEyes 3D Viewer et la diffusion des
projets associés.
- Développement : fortement impliquée dans ce domaine depuis plusieurs années et assurant
le développement de la gamme de logiciel SpacEyes3D ainsi que l'évolution du logiciel de
cartographie numérique GEOimage, SPACEYES dispose d'une très forte expérience de ce type
d'application. Disposant de compétences variées dans des domaines relevant tant de la
cartographie que de la géomatique, du traitement d'images, ou de la 3D, SPACEYES propose la
réalisation d'applications autonomes ou intégrées aux logiciels SpacEyes3D et GEOimage.
- Formation : standard à l’utilisation du logiciel SpacEyes3D ou spécifique qui s’organise en
fonction des besoins du client et s’associe souvent à une assistance technique avec l’utilisation
des données du client.
- La maintenance, incluant le support utilisateur (hotline) et la livraison des nouvelles versions
des logiciels.
2 Les références de l’entreprise
Avec plus de 1000 licences SpacEyes3D Builder installées et opérationnelles, force est de
constater que la solution SpacEyes3D séduit en France et à l’export. Les utilisateurs de la solution
SPACEYES sont avant tout des acteurs du monde de la géomatique ayant besoin de présenter et
communiquer sur des projets d’aménagement du territoire à différentes échelles : spécialistes SIG,
géomètres, producteur de données géographiques, urbanistes...
Les domaines d'applications concernés sont très variés. Ci-dessous, quelques références
SpacEyes3D Builder :
- Collectivités territoriales et services déconcentrés de l’Etat :
Communauté Intercommunale Réunion Est (CIREST), Pays S.U.D.
Communauté de Communes Cœur du Var, Plaine des Maures au Luc en Provence
Communautés urbaines: Cherbourg, Grand Lyon, Bordeaux, Nantes Métropole, Lyon
Directions Régionales de l'Environnement, de l'Aménagement et du Logement: DREAL
Rhône Alpes, DREAL PACA
11. Chapitre 1
Introduction et présentation du projet
Rapport de projet de fin d’étude Page 5
- Bureaux d’étude, Géomètres, Sociétés de Services, Grands Groupes :
URBATER, THEIL-COMMENS, Agence MTDA, Altiplano, I2G, Géo-Vision Avenir (GVA),
CORIOLIS, Latitude-Cartagène, GEOSOFT, Expertise & Développement, Point GED
(Nouvelle-Calédonie), AIGL Développement (La Réunion), Zénith Topographie, AEC
Informatique, OPSIA, SYSTRA, SGDS International, S.I.G., C.I.C.L.
Cabinet LECHENE (76), Cabinet QUEAU (29), SOGEXFO (31), METRIS SA (80), Cabinet
GIULIANI (14), Cabinet CLARET (83), Rudaz + Partner (Suisse), Cabinet BUET (83),
Cabinet Guelle & Fuchs (57), GUID-OI (La Réunion), Cabinet CABON (62), Cabinet
AMAYENC (83), Cabinet TREDE (83), Cabinet Fuchs (Martinique), Cabinet BUZANCAIS
(83), Cabinet LEVIN (38), Cabinet NEUILLY (18)
MAPPY, ALCATEL (Paris), FLEXIMAGE, Télédiffusion de France (TDF), SPOTIMAGE,
VEOLIA EAU, MAIA-SONNIER, EGIS-SCETAUROUTE (Toulouse)
- Organismes Publics :
Centre National d'Etudes Spatiales (CNES) - PONT Entente Interdépartementale (Ex-
Circos)
Parc National du Mercantour (Borne interactive) - Parc Naturel Régional de Chartreuse
Bureau de Recherche Géologique et Minières (BRGM Marseille, Paris, Orléans)
SAGEM Défense sécurité, Société National des Chemins de Fer (SNCF)
Commissariat à l'Energie Atomique (CEA), Institut de Radioprotection et de Sûreté
Nucléaire (IRSN)
Centre National d'Aguerrissement en Montagne (CNAM) - Armée de Terre
- Export :
SINTEL & SONATEL (Sénégal), ORASCOM & Orange (Roumanie, NEO (Pays-Bas)
OfekAerialPhotography (Israel), EKODES, INRENA &Peruvian Air Force (Pérou)
Basarsoft, Altındağ Municipality, Ankara Governorship
Engesat, Vista Divina &Engemap (Brésil), Novaterra, Sabesp, Petroecuador (Equateur),
Vietic (Ecuador)
Univ. de Chulalonkorn et Univ. de Silapakorn, OCSB/Ministère de l'industrie, Royal Thai
Air Force (Thailande)
Japan Forest Technology Association (JAFTA), Japan Atomic Energy Agency (Japon)
Chinese Cultural University (Taiwan), Taipei County Government (Taiwan), Aletheia
University (Taiwan), SOMAF company, Korean Aerospace Research Institute (Korea),
Chung-AngAerosurvey (Korea)
Mapping agency & Institute of Information Technology, from Ministry of Defence
(Vietnam), Geomatic Consulting International (Vietnam)
12. Chapitre 1
Introduction et présentation du projet
Rapport de projet de fin d’étude Page 6
II Presentation du projet
SpacEyes3D Builder est une application permettant de créer des maquettes 3D à partir des
données cartographiques. Cette maquette peut être visualisée en local ou sur internet avec le Builder
mais aussi les autres outils de la gamme SpacEyes3D et en particulier SpacEyes3D Plugin qui permet
de développer des applications Web intégrant la technologie 3D de SPACEYES.
Figure 1.1 : SpacEyes3D Builder
La figure 1.1 est une capture d’écran du logiciel SpacEyes3D Builder.
Figure 1.2 : Application Web basée sur SpacEyes3D Plugin
La figure 1.2 est une capture d’écran du plugin Spaceyes intégré dans une page web.
Dans le cadre de mon stage de fin d’étude, qui s’est déroulé du 04 février jusqu’à fin juin,
SPACEYES m’a proposé de concevoir et développer une librairie JavaScript permettant, dans une
13. Chapitre 1
Introduction et présentation du projet
Rapport de projet de fin d’étude Page 7
application Web intégrant le plugin SpacEyes3D[1]
, d’ajouter très simplement des fonctionnalités
supplémentaires (affichage synchronisée d’une carte 2D, fonctions de recherche à partir d’une
adresse, recherche d’itinéraire, ...) en s’interfaçant avec des services Web existant.
1 Objectif du projet
Ce projet vise donc à créer des librairies JavaScript hautement réutilisables et configurables
permettant de combiner aisément dans une même application Web une fenêtre de visualisation 3D
basée sur SpacEyes3D Plugin et des fonctionnalités supplémentaires.
Finalement, après le développement des bibliothèques et les intégrer, le résultat souhaité est
illustré dans la figure 1.3.
Figure 1.3 : Résultat souhaité
Dans la figure 1.3, les carreaux orange, bleu et vert représentent les modules à développer.
Une même application pourra utiliser un ou plusieurs des modules additionnels.
2 Public cible du projet
Les utilisateurs visés sont les possesseurs du kit de développement SpacEyes 3D SDK qui
permet de développer des applications Web 3D basées sur la technologie SPACEYES. Le public final
est le « grand public » dans le cas de développement d’application internet ouverte, comme par
exemple des applications touristiques, ou bien un public professionnel dans le cas de développement
d’applications d’entreprises en intranet par exemple.
[1]
www.spaceyes3d.com/plugin
14. Chapitre 1
Introduction et présentation du projet
Rapport de projet de fin d’étude Page 8
Conclusion
Dans ce chapitre, nous avons présenté l’organisme d’accueil et nous avons spécifié le cadre
environnant du projet ainsi que le travail demandé.
15. Chapitre 2
Etude de l’existant
Rapport de projet de fin d’étude Page 9
Chapitre 2
Etude de l’existant
Au Sommaire de ce Chapitre
Introduction
SpaceEyes3D Plugin
Géocodage
Vue Immersive
SlippyMaps 2D
Conclusion
16. Chapitre 2
Etude de l’existant
Rapport de projet de fin d’étude Page 10
Introduction
Pour réussir les librairies que nous allons développer, nous avons étudié différentes librairies
et API ayant des activités similaires, ce qui nous a permis de visualiser de près le type de service
voulu, éviter toute interruption ou contrainte inattendue et mettre en évidence les différents acteurs
et leurs besoins.
Cette démarche a pour but la restitution des points clés au niveau de la conception et les API
à utiliser.
I SpacEyes3D Plugin
SpacEyes3D Plugin est un composant basé sur la technologie de SpacEyes3D. Ce composant
permet d’intégrer la technologie SpacEyes3D dans une application classique ou dans une application
web. Il permet d’ouvrir et de manipuler des projets 3D réalisés avec SpacEyes3D Builder sous licence
SpacEyes3D SDK.
SpacEyes3D Plugin peut être intégrer sous deux formes :
- Un composant ActiveX permettant l'inclusion dans toute application Windows supportant
cette technologie, indépendamment du langage de programmation (par exemple C#, C++, Visual
Basic, Python).
- Un Plugin à destination des navigateurs Internet (Internet explorer, Firefox, Chrome)
permettant l'intégration dans une application Web (JavaScript).
Ce Plugin inclut une interface de programmation (API) permettant de développer des
applications personnalisées sur la base de la technologie SpacEyes3D. SpacEyes3D Plugin propose
deux niveaux d’API selon la licence choisie: API Basic et API Pro.
Pour notre projet, on s’intéresse à la forme destinée aux navigateurs web. Où l’application
s’exécute chez le client (JavaScript).
Fonctionnement :
Pour intégrer Spaceyes dans une page html, le développeur utilise l’API JavaScript, il instancie
la classe ‘Sp3dViewer’ en lui passant le nom de l’élément html (div) qui va le contenir, largeur et
hauteur de la fenêtre. Une fois le plugin chargé, le développeur charge une scène en passant
l’emplacement du fichier (local ou distant), ce fichier est d’extension SPV.
L'extension de fichier SPV est associée à plusieurs programmes et applications et divers types
de fichiers. SpacEyes3D Builder stocke les modèles 3D crées à partir de différentes données
cartographiques SIG dans des fichiers de projet SPV.
17. Chapitre 2
Etude de l’existant
Rapport de projet de fin d’étude Page 11
II Le géocodage
Un géocoder s'appuie d'abord et avant tout sur un référentiel. Ce référentiel peut être une
couche de points-adresses, une filaire de voies, une couche de parcelles cadastrales… À peu près
n'importe quelle couche d'informations géographiques comportant des adresses.
Le géocodage permet à affecter des coordonnées géographiques (longitude/latitude) à une
adresse préalablement restructurée et normalisée.
Le géocodage inversé (ou reverse geocoding) consiste à effectuer l'opération inverse du
Géocodage, c'est-à-dire d'attribuer une adresse à des coordonnées géographiques.
Plusieurs entreprises fournissent ce service à travers des API JavaScript qui sont accessible via
des services de type REST.
1 Google
Google propose deux solutions de géocodage :
- Géocodage côté client : L'API Google Maps JavaScript V3 fournit des classes permettant de
récupérer des données à travers des requêtes envoyées. Cette API est exécutée dans le
navigateur. Cette API est gratuite et aucune clé n’est demandée2
.
- Géocodage côté serveur http : permet à l’application cotée serveur d'interroger directement
les serveurs de Google pour le géocodage à partir des requêtes http. Aussi on peut utiliser ce
service coté client en invoquant des requêtes http à partir du navigateur en utilisant JavaScript
(requêtes AJAX).
Ces services sont limités pour 25000 requête par jour ; pour notre module, nous allons
utiliser l’API coté client, réduisant ainsi le risque d’atteindre le nombre maximal de requêtes
autorisées.
2 Bing
Bing offre son service de géocodage à travers BingMaps REST API qui fournit une interface
pour effectuer des tâches telles que la création d'une carte statique avec des punaises, récupérer les
métadonnées de l'image, ou la création d'un itinéraire. Pour utiliser cette API, une clé (key) doit être
obtenue.
Pour le géocodage, Bing REST API propose trois solutions, pour chacune un modèle d’url est
spécifié :
- Find a Location by Address : Renvoie une ou plusieurs ressources de l'emplacement qui
contiennent des informations de localisation associées avec les valeurs des paramètres d'URL. Les
informations de localisation pour chaque ressource comprennent les coordonnées de latitude et
de longitude, le type de lieu, et la zone géographique qui contient l'emplacement.
18. Chapitre 2
Etude de l’existant
Rapport de projet de fin d’étude Page 12
Exemple de requête :
« http://dev.virtualearth.net/REST/v1/Locations/CA/adminDistrict/postalCode/locality/addressLi
ne?includeNeighborhood=includeNeighborhood&maxResults=maxResults&key=BingMapsKey »
- Find a Location by Point : renvoie une ou plusieurs ressources de l'emplacement qui
contiennent des informations de localisation associées avec la latitude et les valeurs des
coordonnées de longitude que vous spécifiez. Les informations de localisation peut être aussi
précis comme une adresse ou plus générales comme le pays ou la région. On peut spécifier le type
d'informations de localisation que nous voulons recevoir en définissant le paramètre
‘includeEntityTypes’ dans l'URL. Par exemple, on choisit de recevoir uniquement des informations
sur le quartier qui correspond aux coordonnées.
Exemple de requête :
« http://dev.virtualearth.net/REST/v1/Locations/point?includeEntityTypes=entityTypes&includeN
eighborhood=includeNeighborhood&key=BingMapsKey »
- Find a Location by Query : permet d’ obtenir les coordonnées de latitude et de longitude
correspondants à des informations de localisation prévu comme une chaîne de requête. Ces
chaînes peuvent être spécifiées comme un paramètre d'URL structuré ou comme une valeur de
paramètre de requête. Ce modèle d'URL peut être utilisé pour l'information de géocodage partout
dans le monde.
Exemple de requête :
« http://dev.virtualearth.net/REST/v1/Locations/locationQuery?includeNeighborhood=includeNe
ighborhood&maxResults=maxResults&include=queryParse&key=BingMapsKey »
Pour le développement de notre module, nous avons choisi le service ‘Find location by query’
qui est le plus adapté à notre besoin. Mais cette API présente un inconvénient : les résultats
retournés n’appartiennent pas toujours à la zone précisée avec le paramètre ‘boundbox’.
3 OSM
OpenStreetMap (OSM) est un projet international fondé en 2004 dans le but de créer une
carte libre du monde. Nous collectons des données dans le monde entier sur les routes, voies
ferrées, les rivières, les forêts, les bâtiments et bien plus encore !
Les données cartographiques collectées sont réutilisables sous licence libre ODbL (depuis le
12 septembre 2012)3
.
OpenStreetMap propose deux API accessibles via des web services de type REST :
- MapquestAPI : API limitée demandant un key, elle a deux services pour le géocodage avec la
possibilité de limiter la zone de recherche en précisant un ‘BoundBox’ qui est composé de quatre
paramètres (latitude haut gauche, longitude haut gauche, latitude bas droite, longitude bas
droite).
19. Chapitre 2
Etude de l’existant
Rapport de projet de fin d’étude Page 13
Geocoding Service : permet de prendre une adresse et obtenir la latitude et la
longitude associées. Ou d’utiliser la latitude et la longitude et obtenir l'adresse
associée. Le géocodage et son inverse sont proposés.
Après avoir testé ce service, on peut remarquer qu’il n’est pas assez fiable. Pour la
requête suivante :
« http://www.mapquestapi.com/geocoding/v1/address?key=Fmjtd%7Cluub21uynu%2Cbx%3
Do5-96tl54&callback=renderOptions&inFormat=kvp&outFormat=json
&location=rue&boundingBox=-61.58990639453707,16.28718927344446,-
61.484573815269044,16.211457001692132 »
Où on a précisé le ‘BoundBox’ à une zone connue d’avance, c’est la ville de Pointe à
Pitre. Voici les résultats retournés :
Longitude :-75.6064, latittude:37.787201, adminArea4 : Accomack
Search Service : fournit une interface simple pour obtenir des résultats de recherche
géographique. Le service peut être demandé à l'aide des paramètres de requête, JSON
ou XML et peut être retourné en JSON ou XML afin qu'il puisse facilement être analysé
par les applications clientes. Cette méthode est utilisée pour l’affichage de la map
d’OSM avec la zone recherchée.
La figure 2.1 montre exemple d’utilisation de ce service
Figure 2.1 : OSM Search Service
- OpenMapquestAPI : offrent une interface HTTP facile à la fonctionnalité de MapQuest. Ces
services permettent d'utiliser les données OpenStreetMap pour gérer la plupart des
fonctionnalités présentes dans les MapQuest Web Services Platform. Cette API propose aussi
deux services de géocodage :
20. Chapitre 2
Etude de l’existant
Rapport de projet de fin d’étude Page 14
Open Geocoding Service : demande un key et elle est accessible à partir des requêtes
http en précisant l’adresse et possibilité de limiter la zone de recherche avec un
‘BoundBox’.
NominatimSearch Service : aucun key n’est demandé, le service de recherche
Nominatim est similaire à MapQuest service de recherche avec son interface simple et
des fonctionnalités puissantes, mais repose uniquement sur des données contribuées à
OpenStreetMap.
Après avoir testé tous les services proposés par OSM, nous avons choisi d’utiliser le service
NominatimSearch pour les raisons suivantes :
- Accès sans key.
- Utilisable indépendamment du map d’Osm, c’est-à-dire sans charger la map.
- Retourne des résultats fiables.
4 L’auto-complétion
L'auto-complétion est un mot étrange qui pourrait être également appelé "aide à la saisie".
En fait on l'utilise régulièrement dans nos applications de tous les jours, que ce soit le client mail,
navigateur Web ou même le moteur de recherche habituel4
.
La figure 2.2 nous montre l’auto-complétion de Google.
Figure 2.2 : Auto complétion de Google
21. Chapitre 2
Etude de l’existant
Rapport de projet de fin d’étude Page 15
Nous allons développer cette fonctionnalité pour aider l’utilisateur à choisir le lieu désiré au
moment où il fait la saisie de l’adresse dans un champ à fin de le géocoder.
Parmi les fournisseurs étudiés, seulement Google offre ce service dans son API par la
fonctionnalité ‘Places Autocomplete’.
III Vues Immersives
Google Street View (GSV) fournit des vues panoramiques à 360 degrés sur les routes
désignées dans toute sa zone de couverture. La figure 2.3 nous montre un exemple de vue. C’est une
fenêtre qu’on peut intégrer dans un élément html (un div par exemple). Elle présente aussi des
boutons permettant de gérer le niveau de zoom, d’avancer et de reculer dans la vue.
Figure 2.3 : Google Steet View
Ce service est fourni par l’API Google Maps JavaScript v3[2]
qui ne demande pas de clé (key)
pour y accéder.
IV Les Slippy Maps 2D
Le terme Slippy Map ou carte glissante désigne les applications de cartographie 2D,
fonctionnant dans le navigateur web du client, permettant d'explorer de façon dynamique la carte
simplement en saisissant et en faisant glisser l'image de carte dans n'importe quelle direction. Les
navigateurs modernes permettent le chargement dynamique de tuiles[3]
de carte en réponse à
l'action de l'utilisateur sans la nécessité d’un rechargement de la page. Cet effet dynamique permet
leur visualisation cartographique plus intuitive5
.
La carte glissante est en fait un composant Ajax - JavaScript s'exécute dans le navigateur, qui
demande dynamique les tuiles du serveur en arrière-plan sans recharger toute la page HTML. Ceci
fournit une carte facile à utiliser.
[2]
https://developers.google.com/maps/documentation/javascript/streetview
[3]
Tuiles : une map 2d est segmentée en petits carreaux appelés tuiles
22. Chapitre 2
Etude de l’existant
Rapport de projet de fin d’étude Page 16
Le rendu des tuiles est un processus gourmand en termes de des ressources. C'est la raison
pour laquelle le serveur ne rend pas les tuiles en temps réel, pour chaque utilisateur naviguant sur la
carte.
Plusieurs Framework permettent d’intégrer les Slippy Maps en se connectant à des services
tels que Google Maps, OpenStreetMaps, Bing Maps. Pour le développement de notre module nous
allons étudier les deux librairies OpenLayes et Leaflet.
1 OpenLayers
OpenLayers rend facile de mettre une carte dans n'importe quelle page web. Il peut afficher
des tuiles de carte et des marqueurs chargés à partir de n'importe quelle source. OpenLayers a été
développé pour favoriser l'utilisation de l'information géographique de toutes sortes. OpenLayers est
entièrement gratuit, Open Source JavaScript, publié sous la licence 2-clause BSD (également connu
sous le nom de FreeBSD)6
.
OpenLayers offre plusieurs fonctionnalités telles que la gestion des claques où on peut
intégrer plusieurs couches au même temps, la gestion des marqueurs où on peut dessiner des
marqueurs à partir des géométries[4]
ou des images.
Une Map créée avec OpenLayers est composé principalement de :
- Layers ou couches : Chaque map OpenLayers possède une ou plusieurs couches. Les couches
affichent les données géographiques que l'utilisateur voit sur la carte.
- Controls ou contrôles : En OpenLayers, les contrôles fournissent une façon pour les
utilisateurs d'interagir avec la map. Certains contrôles ont une représentation visuelle tandis que
d'autres sont invisibles pour l'utilisateur. Lorsqu’on crée un map avec les options par défaut, on
dispose de quelques contrôles par défaut visibles. Ces contrôles permettent aux utilisateurs de
naviguer avec les mouvements de la souris (par exemple, faire glisser dans la poêle, double-
cliquez pour zoomer) et les boutons de pan & zoom.
- VectorLayers ou couches vectorielles : est généralement utilisé pour afficher les données sur
une map et permettre une interaction en temps réel avec les données. Fondamentalement, cela
signifie que nous pouvons charger des données géo spatiales à partir d’un fichier, comme KML ou
GeoJSON, et afficher le contenu sur une carte.
[4]
Géométrie : un ensemble des point constituant une forme (par exemple pour dessiner un
carré on a besoin de quatre point)
23. Chapitre 2
Etude de l’existant
Rapport de projet de fin d’étude Page 17
Figure 2.4 : Exemple d’utilisation de calque OpenLayers
La figure 2.4 montre un exemple d’utilisation des calques OpenLayers où les deux couches
Google Street et OpenStreetMap sont intégrées dans la même fenêtre.
2 Leaflet
Leaflet est une bibliothèque JavaScript open-source moderne pour cartes interactives
mobile-friendly. Elle est développée par Vladimir Agafonkin avec une équipe de collaborateurs
dévoués. Pesant seulement 28 Ko de code JS, elle possède toutes les fonctionnalités pour la
visualisation de cartes en ligne.
Leaflet est conçu avec simplicité, performance et facilité d'utilisation à l'esprit. Il fonctionne
de manière efficace dans toutes les plateformes mobiles et bureaux, profitant de HTML5 et CSS3 sur
les navigateurs modernes tout en étant accessible sur les anciens. Elle peut être étendue avec de
nombreux plugins7
.
Conclusion
Ce chapitre a permis de présenter l’étude de l’existant et la solution proposée. Le chapitre
suivant présentera l’analyse et la conception, une étape primordiale dans l’élaboration et la création
du projet.
24. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 18
Chapitre 3
Analyse et conception
Au Sommaire de ce Chapitre
Introduction
Méthodologie
Itération 1 : Géocodage
Itération 2 : Google Street View
Itération 3 : Slippy Maps 2D
Conclusion
25. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 19
Introduction
Dans cette partie, nous allons définir notre méthodologie de travail par un processus de
développement. Ensuite nous allons présenter l’analyse et la conception de notre projet par
itération.
I Méthodologie :
Le Processus de développement logiciel est un ensemble structuré d’activités nécessaires
pour développer un logiciel. C’est une représentation abstraite d’un processus. Dans chacun des
modèles, les étapes sont globalement divisées en quatre phases, à savoir la phase de planification,
mise en œuvre, tester et documenter la scène et à la fin de la phase de déploiement et de
maintenance. Peu importe le modèle choisi pour le développement logiciel, le logiciel à la fin doit
passer par ces étapes. L'ordre dans lequel le logiciel passe par le modèle peut varier. Chacun des
modèles qui peuvent être utilisés dans le cycle de vie du développement logiciel, a ses avantages et
ses inconvénients8
.
1 Cycle de vie
Le modèle en spirale est définit par Barry Boehm dans son article «Un modèle en spirale de
développement de logiciels et d'amélioration» en 1986. Bien que ce modèle ne vient pas avec
l'approche itérative dans le développement logiciel, il a été le premier modèle, ce qui explique
l'importance de l'itération dans le développement de logiciels. Le modèle de cycle de vie en spirale
combine les éléments tant dans leur conception, ainsi que des prototypes dans les stades. Pour cette
raison il peut bénéficier des avantages des deux hauts vers le bas, ainsi qu’approche bottom-up aussi.
Nous avons divisé notre projet en quatre modules indépendants. Chacun d’entre eux
présente une itération. Pour cela nous avons choisi de suivre le cycle de vie en spirale. La figure 3.1
illustre les étapes du développement où chaque module passe indépendamment par les quatre
étapes : analyse, conception, réalisation et test.
26. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 20
Figure 3.1 : Modèle en spirale
Chaque itération va contenir l’analyse et la conception du module associé, ensuite nous
allons terminer par la réalisation et test dans le chapitre suivant.
2 Identification des acteurs
Notre projet est la réalisation des librairies réutilisables. Le développeur l’utilise pour ajouter
des services à une application intégrant une scène du plugin Spaceyes. Par la suite l’utilisateur accède
à cette application et exploite ces services.
Donc notre projet a deux acteurs :
- Le développeur : c’est l’acteur direct des librairies.
- L’utilisateur : c’est l’acteur indirect des librairies en utilisant l’application crée par le
développeur.
Pour présenter les acteurs, nous allons utiliser le diagramme de contexte illustré par la figure
3.2. Un diagramme de contexte est un diagramme qui représente d'une manière globale le système
sans le détailler. Il permet de délimiter le périmètre du système étudié9
.
27. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 21
Figure 3.2 : diagramme de contexte
Description :
Le développeur réutilise nos librairies afin de créer une nouvelle application qui inclut le
plugin Spaceyes. L’utilisateur accède à la page « index.html » pour utiliser ce nouveau système.
28. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 22
II Itération 1 (Géocodage)
Introduction :
Dans cette première itération, nous allons entamer les trois étapes de cycle de vie du module
de géocodage. Commençant par l’analyse.
1 Analyse et spécification
Dans cette section, nous allons définir les besoins fonctionnels, non fonctionnels et semi
formel des besoins.
1.1 Besoin fonctionnels
D'après la norme AFNOR NF X 50-151, l'analyse fonctionnelle est une démarche qui consiste
à rechercher, ordonner, caractériser, hiérarchiser et / ou valoriser les fonctions du produit attendu
par l'utilisateur.
Pour le développeur :
Le développeur doit avoir accès aux fonctionnalités suivantes :
- Ajouter le service de géocodage Google, OSM et/ou Bing, en spécifiant un ensemble des
options tel que le style du marqueur à dessiner, et la fonction à exécuter si l’utilisateur clique sur
un résultat.
- Ajouter le service de géocodage inverse Google, OSM et/ou Bing.
- Ajouter le service de l’auto-complétion aux champs de saisie.
Pour l’utilisateur :
L’utilisateur de l’application doit pouvoir :
- Géocoder une adresse.
- Géocoder l’inverse d’un point en cliquant sur la map 3d.
- Zoomer sur un des résultats obtenus.
1.2 Besoins non fonctionnels
Les spécifications non-fonctionnelles sont celles qui n'expriment pas une fonction du logiciel.
Ces spécifications, qui expriment des contraintes, sont essentiellement de deux types:
- Les contraintes d'interface. L’application doit tourner sur tous les navigateurs web (Internet
Explorer, Mozilla Firefox, Chrome et Safari).
29. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 23
- Les contraintes de performance. L’application doit tourner sur des machines de moyennes
performances.
1.3 Spécification des besoins fonctionnels
Nous avons choisi de concevoir notre librairie à l’aide du langage UML (Unified Modeling
Language) grâce à ses nombreux points forts, car UML est un langage universel pouvant servir de
support pour tout autre langage et que c’est un moyen simple pour définir la structure d’un
programme.
Diagramme de cas d’utilisation
Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner une
vision globale du comportement fonctionnel d'un système. Un cas d'utilisation représente une unité
discrète d'interaction entre un utilisateur (humain ou machine) et un système.
30. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 24
Figure 3.3 : Diagramme de cas d’utilisation général pour le développeur–géocodage
31. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 25
Description :
La figure 3.3 montre un diagramme de cas d’utilisation général pour le premier acteur
« développeur ». Le développeur peut ajouter les fonctionnalités du géocodage et auto-complétion à
un champ de texte. Il peut notamment utiliser le géocodage directement sans utiliser un champ de
texte.
2 Conception
Parmi tous les facteurs qui concourent à la qualité d’un logiciel, nous avons introduit la
notion de réutilisabilité comme étant l’aptitude d’un logiciel à être réutilisé, en tout ou en partie,
dans de nouvelles applications. Or, la notion de classe, à part sa faible granularité et ses connexions
figées (les associations avec les autres classes matérialisent des liens structurels), ne constitue pas
une réponse adaptée à la problématique de la réutilisation.
Pour faire face à ce problème, les notions de patrons et de canevas d’applications ont percé
dans les années 1990 pour ensuite laisser la place à un concept plus générique et fédérateur : celui
de composant. La programmation par composants constitue une évolution technologique soutenue
par de nombreuses plateformes. Ce type de programmation met l’accent sur la réutilisation du
composant et l’indépendance de son évolution vis-à-vis des applications qui l’utilisent10
.
La programmation orientée composant s’intègre très bien dans le contexte de la
programmation orientée objet puisqu’il ne s’agit, finalement, que d’un facteur d’échelle. En effet,
l’utilisation de composants est assimilable à une approche objet, non pas au niveau du code, mais au
niveau de l’architecture générale du logiciel.
Pour cela nous allons présenter le diagramme de composant.
2.1 Diagramme de classe
Dans cette section, nous allons présenter le résultat de l’étude que nous avons fait. Nous
allons décrire la conception du module de géocodage sous forme de diagramme de classe des
diagrammes de séquences pour illustrer le fonctionnement et la communication entre les différentes
classes.
32. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 26
Figure 3.4 : Diagramme de classe du module de géocodage
Comme montre la figure 3.4, les classes Google, Bing et OSM héritent de la classe mère Base.
Cette dernière est une classe abstraite qui définit le fonctionnement du module. « PluginParam » est
une classe singleton, elle ne sera instanciée qu’une seule fois au moment de l’exécution. La première
33. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 27
classe parmi Google, Bing et Osm qui va être utilisée crée cette instance et les autres la récupèrent
par la suite. Cette classe contient des paramètres calculés suivant le map chargé par le plugin
Spaceyes3d. Ces paramètres sont principalement :
- Un tableau pour sauvegarder les combinaisons de touches pour faire le géocodage
inverse.Exemple : aKeyEvent [0] = {‘Google’,’w’} signifie que si on clique sur la map 3d et la touche
‘w’ est appuyée, on lance une requête de géocodage inverse sur ce point.
- BoundBox1 : c’est un objet contenant les deux points sud-ouest et nord-est du map chargé.
- BoundBox2 : c’est un objet contenant les deux points nord -ouest et sud –est.
Ces points sont calculés à partir du map 3d chargé. Les étapes suivies pour les extraire sont :
Récupérer les coordonnées des points Haut-Gauche, Bas-Gauche, Haut-Droit et Bas-
Droit.
Projeter ces points en projection cartographiques.
Calculer les coordonnées (Min Longitude, Max longitude, Min Latitude, Max Latitude)
de rectangle englobant (en vert sur la figure 3.5)
Figure 3.5 Etapes d’extractions des points limites
34. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 28
2.2 Diagrammes de séquence
Figure 3.6 : Diagramme de séquence géocodage détaillé 1
La figure 3.6 montre le fonctionnement du système une fois l’une des classe Google, Bing ou
Osm est instanciée.
Figure 3.7 : Design pattern singleton
La figure 3.7 présente la solution du design pattern singleton, ce pattern restreindre
l'instanciation d'une classe à un seul objet.
Comme on a choisi d’utiliser L'API Google MapsJavaScript V3, l’interrogation de service du
géocodage serait via ces classes de l’API, contrairement pour Bing et OSM où on va utiliser des
requêtes Ajax pour récupérer les données. La figure 3.8 montre le fonctionnement de la classe
‘Sp3dGeoCodingService.Google’ lorsqu’un utilisateur ou une autre classe appelle cette méthode.
35. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 29
Figure 3.8 : Diagramme de séquence de géocodage Google
Pour Bing et OSM, la méthode du géocodage fait appel à
‘Sp3dGeoCodingService.CommonClass’, car toutes les deux utilisent le web service REST. La figure 3.9
illustre ce fonctionnement.
Figure 3.9: Diagramme de séquence de géocodage Bing/OSM
Pour l’auto-complétion, puisque L'API Google Maps fournit ce service on va l’utiliser
directement. Pour Bing et OSM ce service n’est pas encore disponible, donc on a choisi d’utiliser la
fonctionnalité du géocodage au moment de l’auto-complétion.
36. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 30
La figure 3.10 du diagramme de séquence montre ce fonctionnement.
Figure 3.10 : Diagramme de séquence auto-complétion Bing/OSM
2.3 Diagramme de composant
Figure 3.11 : diagramme de composant Géocodage
37. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 31
Description :
Le diagramme de composant illustré dans la figure 3.11 représente l’organisation et les
dépendances liant les éléments physiques logiciels du module de géocodage. L’utilisateur demande
la page « index.html » qui instancie le plugin web déjà installé chez le client pour communiquer avec
le serveur spaceyes3d. Les services de géocodage et géocodage inverse sont offerts par les classes
qui seront développées dans le fichier « sp3dGeoCod.js » dessiné en orange.
38. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 32
III Itération 2 (Google Street View)
1 Analyse et spécification
1.1 Besoins fonctionnels
La bibliothèque doit fournir un composant qui permet au développeur d’ajouter le service
Google Street View (GSV) en spécifiant un certain nombre de paramètres pour permettre à
l’utilisateur de :
- Naviguer sur le panorama du streetview et le système synchronise la position et l’orientation
du marqueur sur la scène 3d du map chargé.
- Chercher des panoramas en déplaçant le marqueur sur la scène.
- Naviguer sur la scène 3d.
1.2 Besoins non fonctionnels
Les contraintes d’interface : l’application doit tourner sur tous les navigateurs web et sa taille
doit être conforme à la taille de l’élément qui va la contenir.
Les contraintes de performances :
- Chargement et synchronisation rapide des diaporamas avec la scène.
- Réduction maximal du nombre de requête vers le serveur Google.
1.3 Spécification des besoins fonctionnels
Diagramme de cas d’utilisation
La figure 3.12 montre le diagramme de cas d’utilisation pour le premier acteur du module
GSV et qui est le développeur.
Figure 3.12 : Diagramme de cas d’utilisation pour le développeur – GSV
Description :
Le développeur peut ajouter la fonctionnalité du GSV à une application intégrant le module
Spaceyes. Pour cela il doit spécifier quelques paramètres tels que l’élément html qui va la contenir, la
couleur et la taille de la flèche.
39. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 33
2 Conception
2.1 Diagramme de classe
La figure 3.13 illustre le diagramme de classe du module GSV.
Figure 3.13 : Diagramme de classe GSV
Description :
La classe « Sp3dGoogleSV » est la classe principale, elle implémente les méthodes qui gèrent
la fenêtre du diaporama du GSV. Cette dernière instancie une image de la classe
« Sp3dSceneManagement », cette dernière gère les dessins des différents marqueurs sur le map 3d.
La classe « Sp3dSceneMnagement » utilise la classe « Sp3dWkt.PolygonRing » de l’SDK du
plugin Spaceyes3d pour dessiner la forme de la flèche.
40. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 34
2.2 Diagramme de séquence
Figure 3.14 : Diagramme de séquence GSV 1
41. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 35
Description :
La figure 3.14 du diagramme de séquence illustre le fonctionnement du module GSV une fois
la classe « Sp3dGooggeSV » est instanciée. Elle initialise les éléments html, et lance l’initialisation du
service qui va demander de la classe « Sp3dSceneManagement » les coordonnées (latitude,
longitude) du point central du map 3d. Une fois retournée elle crée une instance de
« google.maps.StreetViewService ». Cette dernière envoie une requête asynchrone au serveur de
Google demandant un diaporama le plus proche du point central dans un cercle de rayon de 5000
mètre. Après le traitement de la requête, les résultats sont retournés à une fonction de la classe
« Sp3dGooggeSV ». S’il existe un diaporama (Résultat = ok), cette fonction prépare le diaporama
trouvée et calcule ses coordonnées. Si cette fonction est appelée pour la première fois, elle initialise
les marqueurs de la scène 3d et crée les écouteurs des événements de la souris sur le map 3d, si non
un message d’erreur est affiché.
Pour mieux comprendre le comportement du système lorsqu’un utilisateur interagit avec
l’application, nous présentons les diagrammes de séquence relative aux scénarios d’utilisation.
42. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 36
Figure 3.15 : Diagramme de séquence GSV 2
43. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 37
Description :
La figure 3.15 montre le fonctionnement dans le cas où l’utilisateur manipule la scène 3d. Ce
diagramme illustre quand est ce que les marqueurs et le diaporama sont mis à jour. Quand
l’utilisateur clique au-dessus de la scène, l’application calcule les coordonnées de la souris et teste si
elle est en collision avec le marqueur. Si oui et si l’utilisateur maintien le bouton de la souris cliqué :
- Les marqueurs 1 « Bonhomme » suit la position de la souris
- Le marqueur 2 « Cercle » reste à sa position.
- Masquer le marqueur 3 « flèche ».
- Afficher le marqueur 4 « Point » qui suit et indique la position du de la souris sur la scène
(position après projection).
Ensuite s’il fixe le marqueur pendant une seconde, l’application envoie une requête à Google
pour demander le nouvel diaporama correspondant à position actuelle du pointeur. Une fois la
réponse est reçue et si elle contient un diaporama :
- Mise à jour de la position du marqueur 2
- Mise à jour du diaporama.
- Mise à jour des marqueurs 1 et 4.
Finalement, lorsque l’utilisateur lâche le clique :
- Afficher le marqueur 2 « Cercle ».
- Afficher le marqueur 3 « Flèche ».
- Masquer le marqueur 4 « Point ».
44. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 38
Figure 3.16 : Diagramme de séquence GSV 3
Description :
La figure 3.16 du diagramme de séquence montre le fonctionnement de l’application dans le
cas où l’utilisateur manipule le diaporama. Il y’a deux types de manipulation :
- Changement de diaporama : l’utilisateur avance ou recule dans le steetview avec les flèches.
Dans ce cas une requête est envoyée à Google pour charger la vue suivante ou précédente, le
diaporama et les marqueurs seront mis à jour.
- Rotation de la vue : l’utilisateur manipule la vue caméra, dans ce cas l’orientation du
marqueur « Flèche » sera mise à jours.
45. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 39
2.3 Diagramme de composant
Figure 3.17 : Diagramme de composant GSV
Description
Le diagramme de composant du module GSV illustré dans la figure 3.17 représente
l’organisation et les dépendances liant les éléments physiques logiciels du module.
- La page « index.html » utilise la librairie « spaceyes » et communique avec le serveur
« spaceyes3d » pour instancier le plugin web déjà installé chez le client.
46. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 40
- Le composant « sp3dGoogleSV.js » que nous développons assure le service du Street View.
Les classes de ce composant utilisent les librairies JavaScript « Spaceyes » et communique avec le
serveur Google.
- La page « index.html » intègre Le service de Street View exposé par le module
« sp3dGoogleSV ».
47. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 41
IV Itération 3 (Slippy Maps)
1 Analyse et spécification
1.1 Besoins fonctionnels
Pour le développeur :
Le développeur peut ajouter le service SlippyMaps dans une application utilisant le plugin
spaceyes3d soit en utilisant l’implémentation OpenLayers soit Leaflet. Et pour les deux cas, le
développeur doit pouvoir :
- Ajouter une couche du map Google, Osm ou Bing (il peut également ajouter les trois au
même temps).
- Spécifier un certain nombre d’options tel que :
La restriction de manipulation sur zone de la scène 3d.
Le style des marqueurs
Pour l’utilisateur :
L’utilisateur de l’application exploitant le plugin Spaceys doit pouvoir :
- Naviguer sur la scène 3d et le système synchronise la map 2d avec la vue 3d.
- Manipuler la map 2d et le système synchronise la scène 3d suivant ces manipulations.
- Commuter entre les couches des map chargées (Google, Osm, Bing).
- Activer/Désactiver les calques des marqueurs.
- Glisser le marqueur sur la map 2d, et le système synchronise la position du marqueur
correspondant sur la scène 3d, et inversement.
1.2 Besoin non fonctionnels
Les contraintes d’interface : l’application doit tourner sur tous les navigateurs web et sa taille
doit être conforme à la taille de l’élément qui va la contenir.
Les contraintes de performances :
- Synchronisation rapide entre les deux vue 2d/3d.
1.3 Spécification des besoins fonctionnels
Diagramme de cas d’utilisation
La figure 3.18 montre le diagramme de cas d’utilisation pour le premier acteur du module
SlippyMaps et qui est le développeur.
48. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 42
Figure 3.18 : Diagramme de cas d’utilisation SlippyMaps - développeur
Description :
Le développeur peut utiliser les fonctionnalités du OpenLayers ou Leafet pour ajouter les
maps du Google, Osm et/ou Bing dans un élément html dans la même application intégrant le plugin
Spaceyes. Pour cela il doit spécifier les options.
2 Conception
Pour ce module, on va développer deux solutions pour offrir le service de Slippy Maps, la
première se base sur la librairie OpenLayers, et la deuxième se base sur la librairie Leaflet.
2.1 Diagramme de classe
La figure 3.19 montre le diagramme de classe du module SlippyMaps pour la solution
implémentée avec OpenLayers.
49. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 43
Figure 3.19 : Diagramme de classe SlippyMaps – OpenLayers
Description :
50. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 44
Les deux classes illustrées en orange, sont communes aux deux solutions OpenLayers et
Leaflet.
« sp3dOpenLayersService.OpenLayersManagement » : gère la map 2d et offre des méthodes
de synchronisation de cette map.
« sp3dSlippyMaps.SceneManagement » gère la scène 3d chargé via un fichier d’extension
« .spv », cette classe offre des méthodes de synchronisation et manipulation de la scène.
« sp3dSlippyMaps.GlobalManagement » : est une classe singleton qui initialise les éléments
htlm et communiquent avec les deux classes précédentes pour synchroniser les deux vue 2d et 3d.
« sp3dOpenLayersService.Base » est la classe mère de trois classes filles
« sp3dOpenLayersService.Google », « sp3dOpenLayersService.Bing » et
« sp3dOpenLayersService.Osm ». Elle permet d’ajouter des calques de carte.
Cette structure sera utilisée pour l’implémentation avec Leaflet avec la conservation des
deux classes du package « sp3dSlipyMaps » (dessinées en orange sur la figure 32), et le ré
implémentation des classes du package « sp3dOpenLayersService» qui sera nommé
«sp3dLeafletService ».
2.2 Diagramme de séquence
51. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 45
Figure 3.20 : Diagramme de séquence SlippyMaps – OpenLayers
52. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 46
Description :
La figure 3.20 du diagramme de séquence illustre le fonctionnement du module Slippy Maps
implémenté en se basant sur OpenLayers lorsque le développeur instancie une des classes «
sp3dOpenLayersService.Google », « sp3dOpenLayersService.Osm » et « sp3dOpenLayersService.Bing
». Ces classes utilisent la même instance de « sp3dSlippyMaps.GlobalManagement » qui crée une
instance de :
- « sp3dSlippyMaps.SceneManagement » : cette classe calcule le cadre englobant de la scène
et crée le marqueur central du map 3d.
- « sp3dOpenLayersService.OpenLayersManagement » : cette classe initialise la map 2d et crée
le marqueur central dessus.
Après la création de ces deux classes, « GlobalManagement » initialise les élèments html, et
la fonction « createInstance » retourne la classe singleton « sp3dSlippyMaps.GlobalManagement ».
Finalement, la classe instanciée par le développeur crée le calque.
Après avoir illustré le comportement du système lors de création du service, nous allons
présenter les diagrammes de séquence illustrant l’interaction de l’utilisateur avec le système.
Figure 3.21 : Diagramme de séquence SlippyMaps – utilisateur 1
53. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 47
Description :
La figure 3.21 du diagramme de séquence montre l’interaction de l’utilisateur avec la scène
3d. Quand il manipule la scène, le système recalcule le Viewport[5]
et met à jours la map 2d, cette
dernière envoie une requête au fournisseur du service (Google, Bing ou Osm) demandant les
nouvelles données. Une fois le serveur renvoie le données, la map 2d sera mis à jours pour qu’elle
soit synchronisée avec la scène 3d.
La figure 3.22 du diagramme de séquence SlippyMaps montre le fonctionnement du système
quand l’utilisateur manipule le marqueur 3d de la scène.
Figure 3.22 : Diagramme de séquence SlippyMaps – Utilisateur 2
Description :
Quand l’utilisateur manipule le marqueur, le système calcule la position au fur et à mesure
du déplacement du marqueur, mis à jour sa position et la position du marqueur de la map 2d.
Le déplacement du marqueur 3d est réalisé de la même que le deuxième module.
2.3 Diagramme de composant
[5]
Un Viewport est une zone de visualisation rectangulaire projette ce que voit la caméra
54. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 48
Figure 3.23 : Diagramme de composant – SlippyMaps
55. Chapitre 3
Analyse et conception
Rapport de projet de fin d’étude Page 49
Description :
Le diagramme de composant illustré dans la figure 3.23 du module Slippy Maps illustré par la
figure 36 montre l’organisation et les dépendances liant les éléments physiques logiciels du module.
Le fonctionnement de celui-ci est similaire aux deux premiers modules ou l’utilisateur accède à la
page « index.html » qui instancie le plugin spaceyes et contient offre le service. Les composants à
développer dans ce module sont celle dessinés en orange.
Si le développeur veut utiliser le service SlippyMaps en se basant sur OpenLayers, il élimine
le composant « sp3dLeafletService ». S’il veut utiliser le service en se basant sur Leaflet, il élimine le
composant « sp3dOpenLayersService ».
Conclusion
Dans ce chapitre on a présenté dans un premier lieu la méthodologie de notre travail, ainsi
que l’analyse et la conception détaillée de chaque module notre bibliothèque.
56. Chapitre 4
Réalisation et test
Rapport de projet de fin d’étude Page 50
Chapitre 4
Réalisation et test
Au Sommaire de ce Chapitre
Introduction
Environnement de développement
Aperçu sur le travail réalisé
Conclusion
57. Chapitre 4
Réalisation et test
Rapport de projet de fin d’étude Page 51
Introduction
Cette section est consacrée à la présentation de l’environnement matériel et logiciel utilisé
pour le développement de la solution, nous allons expliquer éventuellement nos choix techniques
des langages de programmation et des outils utilisés. Nous donnerons ensuite une description des
résultats aboutis approuvés par quelques captures d’écrans.
I Environnement de développement
Dans cette partie on va présenter l’environnement de développement utilisé pour les trois
modules de notre projet.
1 Choix technique
Langage :
JavaScript
Lorsqu’il est apparu en 1995, son objectif principal était de gérer une partie de la validation
des entrées qui avaient été laissés au serveur - langues secondaires tels que Perl. Avant cette date,
un aller - retour au serveur été nécessaire pour déterminer si un champ obligatoire est laissé vide ou
une valeur entrée est invalide11
.
C’est un langage de programmation de scripts principalement utilisé dans les pages web
interactives mais aussi côté serveur (NodeJs par exemple). C'est un langage orienté objet à
prototype, c'est-à-dire que les bases du langage et ses principales interfaces sont fournies par des
objets qui ne sont pas des instances de classes, mais qui sont chacun équipés de constructeurs
permettant de créer leurs propriétés, et notamment une propriété de prototypage qui permet d'en
créer des objets héritiers personnalisés.
Framework:
Prototype JavaScript Framework : Supporte la programmation
orientée objet, ce Framework est créée par Sam Stephenson en
Février 2005 dans le cadre de la Fondation pour l'Ajax en Ruby on
Rails. Il est implémenté comme un seul fichier de code JavaScript,
« prototype.js » généralement nommés. Prototype est utilisé par
5,1% de tous les sites12
.
jQuery : est une bibliothèque JavaScript rapide, petit et riche en
fonctionnalités. Cela rend les choses comme document HTML
traversée et la manipulation, la gestion des événements, l'animation
et Ajax beaucoup plus simple avec une API facile à utiliser qui
fonctionne sur une multitude de navigateurs.Il est utilisé par 91.6 %
de tous les sites, ce qui en fait l'une des bibliothèques les plus
populaires JavaScript.
58. Chapitre 4
Réalisation et test
Rapport de projet de fin d’étude Page 52
Spaceyes3d SDK : permet de développer une application tierce basée
sur le SpacEyes3D Component Plugin.SpacEyes3D Plugin est un
composant basé sur la technologie SpacEyes3D Viewer, et permet
d'inclure la technologie SpacEyes3D Viewer dans une application de
bureau ou dans une application Web.
2 Environnement matériel
Pour la réalisation de notre projet, nous avons utilisé un ordinateur de bureau Dual-Core
CPU.
3 Environnement logiciel
Ce projet a été réalisé sous Windows 7 en utilisant les outils suivants :
- JetbrainsWebStorm qui est un IDE commercial pour JavaScript, CSS et HTML construit sur
JetBrains' IntelliJ IDEA platform. Il propose l'achèvement automatique de code et l’analyse à la
volée code.
- Firebug pour déboguer le code JavaScript.
- Visual Paradigm For UML 10.0
II Aperçu sur le travail réalisé
Une fois la phase de conception est terminée, nous avons procédé à la réalisation de nos
librairies. Le long de la phase de développement nous avons réalisé des tests unitaires pour vérifier le
bon fonctionnement des bibliothèques.
Dans une deuxième étape nous avons voulu valider nos bibliothèques dans des conditions
réelles d’utilisation. Nous avons procéder à la réalisation de trois applications qui valident les trois
modules développés.
59. Chapitre 4
Réalisation et test
Rapport de projet de fin d’étude Page 53
function createViewer() {
oViewer = new Sp3dViewer("container", "Sp3dPlugin", 1000, 600);
if (oViewer.loaded()) {
oViewer.addEventHandler('SceneProjectCreatedEvent',
onProjectLoaded);
oViewer.plugin().SceneLoadProject("http://www.spaceyes3d.com/plugin/dem
os/projects/pointapitre.spv");
}
else
alert("Viewer creation failed !");
}
function onProjectLoaded(iErrorCode) {
// L'integration des modules ici
}
Code 1 : Aperçu de code générale
Le Code 1 est le code JavaScript que le développeur met dans la page « index.html » pour
intégrer les modules souhaités avec le plugin Spaceyes.
La fonction « createViewer » est appelée lorsque la page html est chargée, elle crée une
instance du plugin et charge la scène à partir d’un fichier d’extension « .spv », une fois la scène
chargée, elle fait appel à la fonction « onProjectLoaded » où le développeur intervient et intègre les
modules voulus.
1 Module géocodage
1.1 Diagramme de cas d’utilisation
60. Chapitre 4
Réalisation et test
Rapport de projet de fin d’étude Page 54
La figure 4.1 illustre le diagramme de cas d’utilisation pour le deuxième acteur « utilisateur »
Figure 4.1 : Diagramme de cas d’utilisation général pour l’utilisateur– géocodage
Description :
L’utilisateur peut utiliser le géocodage du Google, Bing et Osm. Il peut aussi géocoder
inversement un point (longitude, latitude) en cliquant sur la map 3dchargé par le plugin.
1.2 Diagramme de séquence
Les diagrammes de séquences permettent de représenter les interactions entre les objets
selon un point de vue temporel. En général une séquence porte sur un type spécifique d’action dont
la description devrait être renforcée.
Dans la figure 4.2 nous allons représenter le diagramme de séquence correspondant aux
actions de l’internaute.
61. Chapitre 4
Réalisation et test
Rapport de projet de fin d’étude Page 55
Figure 4.2 : Diagramme de séquence pour l’utilisateur – géocodage
Description
Lorsque l’utilisateur commence la saisie de l’adresse dans le champ de texte, le système
prépare la requête et invoque un web service (requête asynchrone) pour auto compléter l’adresse
désirée. Une fois renvoyés, le système affiche les suggestions. L’utilisateur valide son choix en
cliquant sur une des adresses affichées, le système prépare et envoie la requête au fournisseur. Le
fournisseur traite alors la demande et envoie au système une ou plusieurs résultats. Finalement, le
système filtre ces résultats et les affiche à l’utilisateur pour lui permettre de choisir une et zoomer
sur la map 3d.
1.3 Exemple de code et capture d’écran
Le code 2 représente un exemple d’intégration du ce module, où on va utiliser Google.
62. Chapitre 4
Réalisation et test
Rapport de projet de fin d’étude Page 56
function onProjectLoaded(iErrorCode) {
var geoGoogle = new Sp3dGeoCodingService.Google('GeoContainer', oViewer);
var oGeocodeOption = {
ActivateBoundsLimit:true,
callbackFunction:onGeocodingComplete
};
var oAutoCompleteOptionGoogle = {
inputName:"inputgoogle",
onClickSuggestion:{
tFunction:'geocode',
geocodingOption:oGeocodeOption
},
minLength:2
};
geoGoogle.gcdAutoComplete(oAutoCompleteOptionGoogle);
geoGoogle.gcdAddMouseEvent('x',reverseGeoComplete);
function onGeocodingComplete(aResults,sProviderService,oCaller) {
}
function reverseGeoComplete(sAddresss,sProviderService,oCaller){
alert(sAddresss);
}
}
Code 2 : Exemple d’intégration du module de géocodage – Google
Dans la fonction « onProjectLoaded », le développeur instancie la classe qui offre le service
de géocodage Google, appelle les deux méthodes de géocodage et son inverse en passant des
paramètres tel que le nom de la fonction à appeler une fois le géocodage est terminé.
Figure 4.3 : Géocodage Google
La figure 4.3 montre un exemple où l’utilisateur géocode une adresse en utilisant Google.
Dès qu’il commence à saisir dans le champ, les suggestions sont affichées.
63. Chapitre 4
Réalisation et test
Rapport de projet de fin d’étude Page 57
Figure 4.4 : Affichage du marqueur
La figure 4.4 montre l’affichage du marqueur sur la scène 3d une fois l’utilisateur clique sur
une adresse.
2 Module Google Street View
2.1 Diagramme de cas d’utilisation
La figure 4.5 illustre le diagramme de cas d’utilisation pour le deuxième acteur « utilisateur »
Figure 4.5 : diagramme de cas d’utilisation général pour l’utilisateur - GSV
64. Chapitre 4
Réalisation et test
Rapport de projet de fin d’étude Page 58
Description :
L’utilisateur peut naviguer le diaporama du Google (avancer, reculer et tourner) et déplacer
le marqueur sur la scène 3d. Ces actions invoquent des méthodes de synchronisation entre la scène
et le diaporama du GSV.
2.2 Diagramme de séquence
Dans la figure 4.6 nous allons représenter le diagramme de séquence correspondant aux
actions de l’internaute pour le cas d’utilisation naviguer sur le diaporama.
Figure 4.6 : Diagramme de séquence GSV – Utilisateur
2.3 Exemple de code et capture d’écran
Le code 3 représente un exemple d’intégration du module GSV.
function onProjectLoaded( iErrorCode ) {
var oOptions = {
arrowforegroundColor : '#00FF00', // default to green arrow
arrowOutlineColor : '#FFFFFF', // default to white outlineArrow
arrowSize : 100 // defaults to 100 m long arrow
} ;
var gsvModule = new Sp3dGoogleSV('GsvContainer',oViewer,oOptions);
}
Code 3 : Exemple d’intégration du module GSV
65. Chapitre 4
Réalisation et test
Rapport de projet de fin d’étude Page 59
Dans la fonction « onProjectLoaded », le développeur instancie la classe « Sp3dGoogleSV » et
lui passe un objet contenant les options requises.
Figure 4.7 : Google Street View
La figure 4.7 montre l’exemple d’intégration du module GSV avec le plugin Spaceyes. Lors su
lancement l’application cherche le point le plus proche du centre contenant un diaporama et l’affiche
dans l’élément html dédié.
66. Chapitre 4
Réalisation et test
Rapport de projet de fin d’étude Page 60
Figure 4.8 : GSV – Affichage du marqueur
La figure 4.8 montre l’affichage du marqueur 3d sur la scène qui est composé de trois
marqueurs :
- Bonhomme (en orange) : c’est une image qui s’affiche toujours au-dessus à la position du
diaporama.
- Le cercle rouge avec : ce cercle est collé à la surface du map, il prend toujours la dernière
position trouvée
- La flèche (en vert) : collée aussi sur la surface et change de direction suivant la direction de la
vue sur le diaporama. Cette flèche est dessinée à partir de huit points.
La figure 4.9 montre comment les points constituant la flèche.
Figure 4.9 : Marqueur flèche
67. Chapitre 4
Réalisation et test
Rapport de projet de fin d’étude Page 61
3 Module SlippyMaps
3.1 Diagramme de cas d’utilisation
Figure 4.10 : Diagramme de cas d’utilisation SlippyMaps– utilisateur
Description :
La figure 4.10 illustre le diagramme de cas d’utilisation pour le deuxième acteur
« utilisateur ». Ce diagramme de cas d’utilisation est valable pour l’utilisation d’OpenLayers ainsi que
pour Leafet. L’utilisateur peut manipuler la map2d ou la scène 3d et le système synchronise les vues.
Aussi il peut déplacer le marqueur sur la map 2d et le système mis à jour la position du marqueur sur
l scène 3d et inversement. Finalement l’utilisateur peut commuter enre les couches des maps et
activer/désactiver des couches vecteurs.
68. Chapitre 4
Réalisation et test
Rapport de projet de fin d’étude Page 62
3.2 Diagramme de séquence
La figure 4.11 illustre le diagramme de séquence pour le cas d’utilisation « Manipuler la map
2d ». Lorsque l’utilisateur manipule le map 2d (Google, Osm ou Bing), le système envoie une requête
asynchrone au fournisseur de service pour récupérer les nouvelles données. Une fois la réponse
reçue, le système mis à jours le map 2d, et la scène 3d.
Figure 4.11 : Diagramme de séquence SlippyMaps 1
3.3 Diagramme de séquence
Le code 4 représente un exemple d’intégration du module SlippyMaps en utilisant la librairie
OpenLayers.
function onProjectLoaded(iErrorCode) {
var oUserOptions = {
container : 'OpenLayersContainer'
}
var oOlyGoogle = new sp3dOpenLayersService.Google(oViewer,
oUserOptions);
oOlyGoogle.addMapService();
var oOlyBing = new sp3dOpenLayersService.Bing(oViewer, oUserOptions);
oOlyBing.addMapService();
var oOlyOsm = new sp3dOpenLayersService.Osm(oViewer, oUserOptions);
oOlyOsm.addMapService();
}
Code 4 : Exemple d’intégration du module SlippyMap–OpenLayers
Dans la fonction « onProjectLoaded », le développeur instancie les classes de service voulu
(Google, Bing, Osm), et appelle la fonction « addMapService ».
69. Chapitre 4
Réalisation et test
Rapport de projet de fin d’étude Page 63
Figure 4.12 : SlippyMaps - OpenLayers
La figure 4.12 montre un exemple d’intégration du module SlippyMaps en utilisant
OpenLayers. La fenêtre bleue permet de commuter entres les couches map Google, Osm et Bing, et
permet aussi d’activer/désactiver les marqueurs dessinés sur la vue 2d.
Conclusion
Au cours de ce chapitre, nous avons décrit les plates-formes matérielles et logicielles sur
lesquelles nous avons construit nos librairies. Nous avons, ensuite, présenté trois applications de test
pour chaque module de la bibliothèque.
70. Chapitre 4
Réalisation et test
Rapport de projet de fin d’étude Page 64
Conclusion générale
Rappelons que l’objectif de ce travail était enrichir le SDK du plugin Spaceyes. Pour cela, nous
avons réalisé une librairie réutilisable permettant d’intégrer plusieurs services dans la même fenêtre
que le plugin Spaceyes3D.
Notre travail A débuté par la compréhension du contexte du projet, à savoir Spaceyes, ses
concepts et ses activités. Ensuite, nous avons réalisé une étude de l’existant concernant les services
de webmapping existants ce qui nous a permis de fixer les anomalies à éviter et les objectifs à
réaliser pour avoir un système satisfaisant. Puis, nous sommes passé à l’étude conceptuelle de notre
application selon une approche orientée objet tout en se basant sur le modèle UML. Par la suite,
nous avons effectué le codage et l’implémentation de l’application. Enfin nous avons effectué les
tests nécessaires à la validation de notre application.
Ce projet a été très avantageux pour moi car il m’a permis de renforcer et enrichir mes
connaissances théoriques dans le domaine de la conception, et de mettre en application mes
connaissances acquises le long de me études. Il m’a encore donné l’occasion de maîtriser le langage
de programmation JavaScript et ses techniques de codage, les web services et surtout la géomatique.
En plus, ce projet était une bonne occasion pour réaliser un travail très concret, avec des
objectifs clairs et bien définis et de se familiariser avec l’environnement du travail et la vie
professionnelle.
En perspective, cette application peut être améliorée en ajoutant d’autres fonctionnalités
(comme Google Direction). Et pour faciliter l’utilisation des librairies, nous pouvons générer une
documentation automatique des classes et méthodes que le développeur va utiliser.
71. Nethographie
Rapport de projet de fin d’étude Page 65
Nethographie
1
http://cpierkot.wordpress.com/recherche/
2
https://developers.google.com/maps/documentation/geocoding/?hl=fr
3
http://openstreetmap.fr/
4
http://lgmorand.developpez.com/dotnet/autocompletion/
5
http://fantomplanet.wordpress.com/2005/06/23/definition-slippy-map/
6
http://openlayers.org/
7
http://javascript.developpez.com/actu/49445/Leaflet-afficher-des-cartes-interactives-optimisees-
pour-les-mobiles-devient-chose-facile-grace-a-cette-bibliotheque-JavaScript/
8
http://promotionordinateur.blogspot.com/2012/11/modele-de-cycle-de-vie-en-spirale.html
9
http://www.memoireonline.com/01/13/6670/m_Mise-au-point-dun-systeme-de-gestion-des-
panneaux-publicitaires5.html
10
http://laurent-audibert.developpez.com/Cours-UML/html/Cours-UML050.html
11
http://w3techs.com/technologies/overview/javascript_library/all
12
Professional JavaScript®for Web Developers2nd Edition (Nicholas C. Zakas)