STEVE LANG - RAPPORT ST50job.steve-lang.com/download/Steve_Lang_Rapport_ST50.pdfDével tourn burea...

Déveltournburea

Steve DépartemFilière REMSystèmes

LaborUniversitRue Thier90010 Beset.utbm

Rapport

loppemenées des au, et app

e LANGent Génie IM temps réel

ratoireté de Techrry Mieg elfort, Ced.fr

de stage

ent d'unevéhicule

plicatif li

G Informatiqu

l, embarqué

e Systhnologie d

dex

ST50 - A2

e interfaces, des cié sur ord

ue

és et inform

tèmesde Belfort

2007

ce hommcentres dinateur

matique mo

s et Trt-Montbé

me-machid'intervemobile u

obile

ranspoéliard

Am

ine pour ention uultra lége

orts

Tmir HAJJ

un logicrgentisteer.

uteur et SuJAM-EL-

ciel d'optes, sur o

uiveur UTB-HASSAN

timisatioordinateu

BMNI

n des ur de

Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50

Steve LANG – Rapport de Stage – Laboratoire SET / UTBM

Introduction Depuis que le temps est devenu une contrainte, l'Homme a toujours cherché à optimiser ses déplacements. Dans le cadre du commerce, par exemple, où on essayera toujours d'aller le plus vite possible, car plus on satisfait de clients, plus on gagne de l'argent et on répond à l'adage : "Le temps c'est de l'argent." Les Mathématiques et leur évolution Informatique ont tenté, et tentent encore aujourd'hui, de trouver des moyens de plus en plus performants pour satisfaire ce rapport distance/temps surtout quand la vitesse est limitée. Le Problème du Voyageur de Commerce est un bon exemple de l'implication du monde des mathématiques dans les soucis d'optimisation et ce depuis le 19ème siècle. Et aujourd'hui l'engouement pour les appareils GPS d'aide à la conduite prouve un peu plus qu'on attache beaucoup d'importance sur les temps de trajet. Le système GPS, étant un appareil de guidage, repose surtout sur des outils d'optimisation pour le calcul des trajets. C'est sur cet esprit d'optimisation que notre projet a fondé ses bases, C'est sur ces bases que se sont montés les murs d'une interface Homme – Machine à optimiser, C'est sur ces murs qu'aujourd'hui je pose la charpente de l'interactivité et de la réactivité, Et c'est accompli que je souhaite bon courage aux poseurs de tuiles pour les prochaines évolutions.



Remerciements Je tiens tout d’abord à remercier Amir HAJJAM pour m’avoir proposé ce sujet, pour son suivi ainsi que pour son aide tout au long du stage. Je tiens à remercier également Abderrafiaa KOUKAM, directeur de l’équipe informatique du laboratoire, et le laboratoire Systèmes et Transports (SET) de l’UTBM de m’avoir accueilli dans leurs locaux. Ensuite j'aimerais adresser mes remerciements à toutes les personnes qui m'ont aidé et conseillé tout au long du stage. Je pense particulièrement à Jean-Charles CREPUT pour sa précieuse connaissance du système et sa disponibilité, et l'équipe experte Système d'Information Géographique (SIG) par Olivier LAMOTTE, Stéphane GALLAND et Sylvaine SCHLIENGER. Enfin, je remercie tous les membres du laboratoire SET, permanents et doctorants, avec lesquels j’ai eu plaisir à travailler dont Alexandre GONDRAN pour sa contribution matérielle et Christophe DUMEZ pour son savoir faire et sa bonne humeur.



SOMMAIRE INTRODUCTION 2

REMERCIEMENTS 3

SOMMAIRE 4

CHAPITRE 1 : PRESENTATION DU LABORATOIRE D’ACCUEIL 5

1.1 UNIVERSITE DE TECHNOLOGIE DE BELFORT-MONTBELIARD 5 1.2 LABORATOIRE SYSTEMES ET TRANSPORTS 6 1.3 EQUIPE ICAP 6

CHAPITRE 2 : PRESENTATION DU SUJET 7

2.1 LE PROJET MERCURE 7 2.2 LE PROJET EPIDAURE 8 2.3 OBJECTIFS DU STAGE 8

CHAPITRE 3 : LES ANTECEDENCES 9

3.1 PRESENTATION 9 3.2 ARCHITECTURE DU SIMULATEUR 10 3.3 PHASES DE SIMULATION 10

CHAPITRE 4 : JOURNAL DE BORD 12

CHAPITRE 5 : DANS LES DETAILS – PARTIE I.H.M. 18

5.1 JDB - 1) : SENSIBILISATION AUX METAHEURISTIQUES 18 5.1.1 ALGORITHMES GENETIQUES DE BASE: 18 5.1.2 ALGORITHMES DE LA COLONIE DE FOURMIS DE BASE : 21 5.1.3 ALGORITHMES DE RECHERCHE AVEC TABOUS DE BASE : 22 5.2 JDB – 9) : AIDE A LA COMPREHENSION : PANEL OUTPUT 24 5.3 JDB – 10) : JFRAME WINDOS AU LANCEMENT 24 5.4 JDB – 12) : NOUVELLE IHM 25 5.5 JDB – 15) : ‘VERITABLE’ ITINERAIRE 27 5.6 JDB – 18) : COMPOSITION ET CREATION DU FICHIER KML 29 5.7 JDB – 19) : MISE EN PLACE DE LA 'JAVA SERVER PAGE' 31 5.8 CONCLUSION PAR L'EXEMPLE DE LA PARTIE I.H.M. 32

CHAPITRE 6 : DANS LES DETAILS – PARTIE EMBARQUEE : PDA/GPS 36

6.1 JDB – 23) : PORT SERIE COM7 ET TRAME NMEA 36 6.2 JDB – 24) : COMMUNICATION ENTRE L'IHM ET LE SYSTEME EMBARQUE 38 6.3 JDB – 26) : ATTRIBUTION DES COORDONNEES DU PDA A L'IHM 42 6.4 CONCLUSION PAR L'EXEMPLE DE LA PARTIE PDA/GPS 42

CHAPITRE 7 : LES TRAVAUX FUTURS 45

CONCLUSION 46

BIBLIOGRAPHIE 47

ANNEXE 48

FICHIER KML RETOURNE PAR L’API GOOGLE MAPS 49

Interface véhicules

Chapitre

1.1 Un L’UTBM forde la technrecherche escientifiquedu regroupde Belfort (1985). L’UTBM estFALANGA, D L’activité scpersonnels connaissanaux scienceDepuis la favorisant transports t– donner u– accélérer – favoriser – augment– contribue En terme Franche-Co

homme-msur PC et

Steve LAN

e 1 : Prése

iversité d

me des ingnologie et et sur la ve, culturel eement de d

(1962) et l’In

t dirigée paDirecteur dé

cientifique r technique

ces fondames humaines

restructurala converg

terrestres etne meilleurle développles relation

ter de manièer au dévelo

de formatmté dans 2

machine poapplicatif

NG – Rappo

entation d

e Techno

énieurs rapaux mutativalorisationt profession

deux établisnstitut Polyt

ar Pascal Félégué pour

repose sur l’es et admmentales et s toutes indiation intervgence de t énergies de lisibilité à

pement des s interdiscip

ère significaoppement de

tion à et pEcoles Doct

our un loglié sur ord

ort de Stag

du labora

logie de B

idement opions de la . Créée en

nnel. Membssements d’technique d

FOURNIER eles relation

’implicationinistratifs, technologi

ispensablesvenue en 1l’activité dépassant le nos partenlaboratoire

plinaires. ative le nome la valorisa

par la rechtorales, et d

iciel d'optdinateur m

ge – Labora

atoire d’a

Belfort-M

pérationnelssociété. Se1999, l’UTB

bre du résea’enseignemde Sévenans

et son Conss industriel

n de tous lesvenant d’h

ques dans s dans les fo

999, l’étabdes 8 unite cadre des d

aires institus.

bre de doctation et du t

herche, l’Uélivre en co

timisation mobile ultra

atoire SET

accueil

ontbéliar

s, particuliès formationBM est un

au des univeent supéries (antenne d

seil d’ Admles au CEA.

s acteurs, chhorizons divdes domainrmations.

blissement tés de recdisciplines scutionnels et

orants. transfert de

TBM est c-habilitation

des tourna léger.

/ UTBM

rd

rement adans s’appuie

établissemersités de te

eur : l’Ecole de l’UTC im

ministration

hercheurs, evers qui alines s’étend

a mis en herche autcientifiquesprivés.

technologie

co-accréditén 3 Masters

ées des

aptables auxnt sur les

ment public echnologie, Nationale d

mplantée à S

est présid

nseignants-mentent leant des scie

oeuvre untour d’une s classiques.

e.

ée avec l’URecherche.

ST5

Page

x évolutionsactivités deà caractèreelle est née

d’IngénieursSévenans en

é par Anne

-chercheurschamp des

ences dures

ne politiquethématique.

niversité de

50

5

s e e e s n

e

s, s s

e e

e



1.2 Laboratoire Systèmes et Transports Sous la tutelle du Ministère Français de l’éducation Nationale et de la Recherche et de l’Université de Technologie de Belfort-Montbéliard (UTBM), le SeT est un laboratoire multi-disciplinaire. Il est composé de trois équipes : – équipe Informatique : Communication, Agents et Perception (ICAP) – équipe Ergonomie et Conception de Systèmes (ERCOS) – équipe évaluation et Conduite de Systèmes (ECS) Le laboratoire a pour objectif de promouvoir et d’appliquer les travaux de recherche et les nouvelles méthodologies dans le domaine des transports, des systèmes de production, de la robotique, des télécommunications et de la réalité virtuelle appliquée. Il est composé de 80 chercheurs (professeurs, maîtres de conférences, ingénieurs de recherche, post-docs et doctorants). Son directeur est Abdellah EL MOUDNI.

1.3 Equipe ICAP L’approche multi-agents propose un cadre méthodologique bien adapté pour la modélisation et l’analyse des systèmes complexes. Elle considère les systèmes comme les sociétés composées d’entités autonomes et indépendantes, appelées agents, qui interagissent en vue de résoudre un problème ou de réaliser collectivement une tâche. Elle a été utilisée de façon fructueuse dans de nombreux domaines et en particulier : la robotique, la résolution distribuée de problèmes, la modélisation et la simulation des systèmes complexes. Malgré les nombreuses réalisations, dont ils ont fait l’objet, les systèmes multi-agents accusent un certain retard en matière de formalisation et de méthodologie de modélisation. En effet, la conception de tels systèmes se fait dans la plupart des cas selon une démarche empirique ou de manière ad hoc. L’élaboration de méthodes de spécification formelles et de conception constitue une problématique importante des recherches actuelles sur les systèmes multi-agents.



Chapitre 2 : Présentation du sujet Le travail s’insère dans le cadre d’ EPIDAURE (Equipement Portable Intelligent D’Auscultation Rapide et Efficace), un projet du programme MERCURE (Mobile Et Réseau pour la Clinique, l’Urgence ou la Résidence Externe) labellisé par le pôle de compétitivité « innovations thérapeutiques ». Ce programme intègre l’UTBM, ALCATEL, SONY, FRANCE TELECOM, LAENEXT, SOS MEDECINS, l’IRCAD, l’ULP, les Hôpitaux Civils de Strasbourg et les Hôpitaux de Paris.

2.1 Le projet MERCURE Le projet est issu des réflexions qui sont menées dans le cadre des projets de la plateforme de télémédecine, baptisée « MERCURE » (Mobile Et Réseau pour la Clinique, l’Urgence ou la Résidence Externe) qui va aborder des projets de plus en plus ambitieux : STETAU qui a pour objectif de mettre à disposition des malades et du personnel médical des outils de mesure non invasifs, mobiles, et communicants. Les informations vitales sont transmises de manière sécurisée, elles sont qualifiées objectivement par des outils de traitement du signal, afin de permettre le diagnostique précoce et objectif de pathologies pulmonaires, cardiaques ou foetales. Le projet repose sur le développement de périphériques de mesure du signal, le premier périphérique étant le stéthoscope communiquant en sans fil avec un équipement informatique de type PDA ou PC. ASAP l’Ecole de l’Auscultation et la base référentielle mondiale de sons auscultatoires (WebSound), point de départ de programmes de recherche sur la qualification de sons et la création d’un réseau d’expertise au niveau mondial. ASCLEPIOS qui est le cœur du programme MERCURE. Il s’agit du déploiement de la solution en milieu hospitalier, avec couverture WiFi, équipements de mesure sans fil, transmission sans fil entre les véhicules d’urgence, le dispatcheur des urgences a l’hôpital, création d’un dossier du patient hospitalisé, mise à disposition sécurisée de tout ou partie du dossier au personnel hospitalier, communication avec les chirurgiens d’astreinte, accès simplifié et accéléré à des équipements plus riches que le PDA (tablette graphique, PC), suivi du patient à son domicile La réussite de ces projets est conditionnée par la définition de formats standardisés des données et des protocoles d’échange. Il est prévu la création d’un projet spécifique pour cet aspect essentiel du programme MERCURE.



2.2 Le projet EPIDAURE Le projet EPIDAURE permettra aux médecins urgentistes d’effectuer des mesures sur les patients (glycémie, auscultation, ecg. . .). Les résultats seront enregistrés sur le PDA et pourront être envoyés au central d’appel pour analyse et archivage, au médecin traitant, à l’hôpital qui va prendre en charge le patient. . . Le principe du projet consiste à regrouper les principaux instruments de mesure pour une analyse plus simple et plus rapide. L’outil comprendra également des formulaires contenant les constantes du patient, le rapport du médecin itinérant. . ., informations qui pourront par la suite être ajoutées au dossier médical du patient. Les objectifs du projet Epidaure sont : – La création d’un format unifié d’enregistrement des données collectées (ECG, glycémie. . . ). – L’aide à la rédaction du rapport avec une interface simple et optimisée. – L’aide dans la prise des constantes vitales du patient (collecte simplifiée et automatisée avec le PDA). – L’aide à la planification des visites et au guidage du médecin. Le tout sera regroupé dans un outil unique. Nous nous focaliserons sur le dernier objectif. Le central d’appel reçoit les appels des patients et gère les interventions des médecins. Le but du travail est de réaliser des outils pour opérer une gestion dynamique et optimisée de l’intervention des médecins en fonction de leur emploi du temps et des caractéristiques de l’appel (proximité géographique, disponibilité, type de pathologie). L’outil réalisera le suivi GPS des interventions en cours et pourra proposer quels médecins peuvent traiter rapidement et efficacement la demande en les géo-guidant. Il pourra planifier les différentes interventions en fonction de critères de déplacement et de l’urgence de l’appel.

2.3 Objectifs du stage

Il s’agit de développer l'outil d'optimisation déjà présent et de le rendre plus interactif en prenant en compte les adresses réelles des visites. Les itinéraires calculés seront visibles sur une carte. On a aussi pour objectif d'intervenir sur le côté réactif de l'application avec l'apport d'une partie embarquée. L'appareil mobile communiquera avec l'application fixe et transmettra sa position pour avoir un suivi "temps réel" du médecin.

Fig.1 Echanges de données lors de l’arrivée d’un appel



Chapitre 3 : Les Antécédences … fondations et murs

3.1 Présentation La première grande partie de ce projet a été de mettre en place un simulateur permettant d'optimiser des problèmes de tournées de véhicules avec fenêtre de temps.

Le principe est de charger des benchmarks de requêtes et de lancer différents modes d'optimisation pour constater l'efficacité de chacun.

Trace de fonctionnement

Evaluation de la solution

Plan de véhicules solution

Paramètres de configuration

Plan de véhicules initial

Jeu de requêtes initial

Dynamic Optimization System

Fig 2. Problème des Tournées de Véhicules

Fig 3. Entrées/Sorties du DOS



3.2 Architecture du Simulateur Le simulateur doit avoir une architecture simple et efficace. Voici l'architecture choisie :

Nous avons le simulateur qui est la classe principale du projet. C'est elle qui crée l'ordonnanceur (Scheduler) et l'IHM qui seront 2 threads distincts. On peut tout de suite noter la séparation qui a été faite entre l'interface et la partie simulation à proprement dite.

3.3 Phases de Simulation Le simulateur gère 2 phases de simulation. La première est une phase d'optimisation statique destinée à générer une première solution à partir des requêtes connues, pour pouvoir fournir un trajet à parcourir pour les véhicules lors de leur départ. La seconde partie est la phase de simulation dynamique, dans laquelle l'optimisation est toujours présente mais les véhicules ont commencé leurs tournées. Les requêtes peuvent arriver à n'importe quel moment dans l'intervalle de temps dynamicHorizon.

Fig 4. Architecture du Simulateur

Fig 5. Phases de simulation


Légende: Ti: Date de Tv: Date de Tf: Date de Ti – Tv = DuTv – Ti = DudynamicHocommence Les phases d

• statstat

• dynTv)

• statoptidyn

3.4 InteCe simulateespace d'ét

homme-msur PC et

Steve LAN

départ de l'odépart des fin de simu

urée de simuurée d'optimorizon: duré

à Tv et se te

de simulatiotique : les vétiques. (Tv =amique : Le

tique_dynamimisation samique. (Ti

erface Hommeur possèdeude (ou Stu


NG – Rappo

optimisatiovéhicules =lation = Hor

ulation + opmisation statée durant ermine au p

on sont gérééhicules ne

= Tf) es véhicules

mique : lesstatique du

<> Tv <> Tf)

me Machinee une interfadiedArea) e


ort de Stag

n statique. Date de dérizon de simtimisation dtique. laquelle le

plus tard à Tf

ées par l'agese déplacer

se déplacen

s 2 phases u problème)

e ace graphiqt on peut su


ge – Labora

but de simumulation. dynamique

s requêtes f.

ent Companront pas et l

nt, l'optimisa

citées préc sur les re

que ou IHM,uivre l'évolu

Fig 6. Inte


atoire SET

ulation.

= D

dynamiqu

ny. Une simues problèm

ation se fait

cédemmentequêtes co

, les requêtetion de l'opt

erface Homm

des tourna léger.

/ UTBM

es peuvent

ulation peutes abordés

t en parallèl

t sont faitennues suiv

es sont dontimisation e

me/Machin

ées des

t arriver. C

t être soit : seront oblig

e de la simu

es, tout d'avie d'une o

c représenten fonction

e du Simula

ST5

Page

Cette durée

gatoirement

ulation. (Ti =

abord d'uneoptimisation

ées dans undu temps.

ateur

50

11

e

t

=

e n

n



Chapitre 4 : Journal de Bord …de la charpente

Pour faire évoluer cette interface, déjà développée, et la rendre plus interactive et réactive (comme mentionné dans les objectifs du stage du chapitre 2), j'ai décidé de tenir un journal de bord qui condense l'évolution de la compréhension et de l'avancement des travaux. Ceci détaillant ainsi un enchainement de points chronologiques, source de petites informations qui seront détaillées dans les prochains chapitres.

1) du 03/09 au 14/09 : • Sensibilisation aux métaheuristiques

2) du 17/09 au 21/09 : • Survol de la partie optimisation du projet

3) le 24/09 : • Rendez-vous avec A.Hajjam et J-C.Créput : Découverte et démo de l’IHM déjà existante

4) à partir du 24/09 : • Analyse et travail sur l’IHM

5) du 24/09 au 26/09 : ---- Découverte du code et de la hiérarchie de l’application ---- Simulator = main()

IHM Ordonnanceur Environment

Company

6) le 28/09 : • le Simulateur charge le fichier config.dat pour se configurer (pour la partie SIG le fichier

de configuration est config_sig.dat) • aide à la compréhension création d’un bouton config (IDE NetBeans 6beta) • Changement des variables dans Simulator

7) du 01/10 au 03/10 : • aide à la compréhension interaction pour récupération des informations des

"Requests" sur un clic de souris (compréhension des instanciations pour la liste active des "Requests")

Company SetOfRequests liste des "Requests"

Fig 8. Accès à la liste des requêtes

Fig 7. Hiérarchie de l'application



• Méthode getCompany() dans l’ordonnanceur • Evénement addMouseListener sur la "StudiedArea" :

__sa.addMouseListener(new MouseAdapter() { public void mouseReleased(MouseEvent e) { … }) ;

• Translation de l’origine et prise en compte du zoom • Itérations sur les "Requests" actifs avec vérification des coordonnées du "Request "

sélectionné

8) du 04/10 au 05/10 : • aide à la compréhension interaction pour récupération des informations des

‘Vehicles’ sur un clic de souris (compréhension des instanciations pour la liste des ‘Vehicles’)

Company SetOfVehicles liste des Vehicles

• dans le même __sa.addMouseListener() o Itérations sur les "Vehicles" avec vérification des coordonnées du "Vehicle"

sélectionné o Données dans un "JOptionPane.showMessageDialog()" à la place du

"System.out.println()" avec prise en charge des icônes. (Cette option évoluera avec la mise en place du système de vue sur carte)

9) à partir du 05/10 :

• aide à la compréhension mise en place d'un panel (EAST) pour les informations de sortie

• méthode setOutput() avec liste des solutions pour chaque véhicule et leur capacité • gridlayout pour le listage des solutions • récupération des informations dans

Company SetOfVehicles get(Vehicles) • prise en compte de la position du véhicule sur son itinéraire • mise à jour de l'affichage à chaque Paint()

10) le 16/10 : Création du jFrame WinDOS de lancement : 3 boutons

• Simulation • Evaluation (de solutions déjà simulées) • SIG

Fig 9. Accès à la liste des véhicules



11) du 18/10 au 02/11 : Partie Evaluation : • Lecture du .global qui regroupe la liste de véhicules et leurs itinéraires respectifs • Affichage en mode statique du tracé terminé

12) du 05/11 au 23/11 : Partie SIG : Nouvelle IHM

• Bouton "Ajout Requête" qui ouvre une fenêtre de saisie et place la requête sur la StudiedArea

• Récupération des coordonnées de l’adresse saisie par l’API Google Maps o Problème : Prise en compte du proxy UTBM

• Conversions WGS84 vers Lambert 2 étendu vers coordonnés de plan • Adaptation du système d’optimisation du simulateur aux requêtes saisies

‘manuellement’ (plus de chargement de benchmark) o addrequest dans la liste des SetOfRequests

13) le 20/11 : Rendez-vous avec l'équipe experte SIG

(Olivier Lamotte, Stéphane Galland, Sylvaine Schlienger) : Compte rendu succin : Système d'information géographique :

• Le choix de la source de données est important : degré de portabilité de l'application finale

• Plusieurs bases de données (SIG, bdAdresse, Navteq, IGN, ...) o Système de géolocalisation (qui fait que ça)

• Les types de données de la base des adresses et de retour du GPS peuvent être différents (différents Lambert (I,II,IIétendu,…)), mais toujours possibilité de transformer par algorithme

• Outil : MapObject, Carte – Metro B • Problème :

o précision du GPS décalé par rapport à la route o entre 15 et 17, quid du 15bis pas référencé ? o intersection : sur quelle route suis-je ? (aide : ça dépend d'où je viens) o altitude : cas du pont

14) du 26/11 au 30/11 :

• Prise de connaissance de l’existant concernant les SIG o Chargement d’un shapefile qui recense tous les tronçons de route pour une

carte donnée o Lien entre le shapefile (.shp) et une base de données (ex : bdAdresse) qui

comporte les informations des tronçons : nom de rue, sens unique, …



15) du 03/12 au 21/12 : • Prise en compte du ‘véritable’ itinéraire (plus de vol d’oiseau) • Dans quelle méthode faire intervenir cette nouvelle fonction ? • Rendez-vous avec Jean-Charles Créput :

o Prendre en compte le retour de plan de l’optimizer : méthode getPlan() -> setEquivalentBackTOpt() de SetOfVehicles

• Interrogation de Google à chaque changement d’itinéraire, pour remplir le buffer de Vecteurs : Itineraire[i] (i = véhicule) suivant les différentes requêtes que le véhicule i devra satisfaire selon l’optimisation

16) du 07/01 au 09/01 : Recherche d’une solution de cartographie • SIG ‘standard’ : Shapefile + Base de données • Prise en considération de l’option webservice par API pour affichage sur carte des

trajets : o ViaMichelin (Payant) o Yahoo ! Maps (Peu développé, comparé à aujourd’hui 20/02/08) o Google Maps

• Choix de l’API Google Maps pour la partie SIG avec prise en compte des qualités/défauts

o + : Service Web gratuit o + : Carte disponible à l’échelle planétaire (voir coût d’un shapefile) o + : Mise à jour des cartes au soin de Google Maps o + : Informations sur les rues (voir coût d’un bdAdresse) o + : API bien élaborée (grande communauté) o + : Plusieurs modes de vue déjà implantés : Satellite, Carte, Mixte o + : Possibilité de demander et d’intégrer les itinéraires

Localisation exacte du numéro de la rue, Sens de la rue Optimisation des parcours Itinéraires détaillées (+ temps, parfois trafic) Cas du pont

o + : Layering simplifié grâce au KML o - : Tributaire d’une connexion internet garantie o - : Service Web : dépendance à Google Maps telle compagnie tierce

17) du 10/01 au 12/01 :

• Découverte plus approfondie de l’API Google Maps par des exemples o Fichiers KML pour les couches (layers) à donner à la map o Javascript / AJAX pour les commandes et les retours de l’API



18) du 14/01 au 16/01 • Découverte et création du fichier KML

o composition d’un fichier KML ? o les fichiers KML sont créés quand on a un nouveau trajet pour le véhicule i o on crée alors un fichier KML par itinéraire du buffer Itinéraire[i]

précédemment décrit (en 15))

19) du 18/01 au 24/01 • Comment transmettre le javascript (pour les commandes) et nos fichiers KML à l’API

Google Maps à partir de notre applicatif ? • Mise en place du projet GoogleMaps qui est une JSP (Java Server Pages) sous Glassfish

v2 (serveur d’application) qui nous permet de communiquer avec l’API (avec l'aide de la librairie javascript geoxml.js)

20) le 25/01 : appel de la JSP, avec les informations des KML, à chaque clic de souris sur la compagnie ou sur un véhicule

21) du 28/01 au 29/01 : • Récupération du PDA/GPS pour la partie embarquée

o Problème de connexion Wifi (WPA Entreprise) à partir de l’unité mobile o Généreux prêt d’un dongle wifi (Trendnet) de la part d’Alexandre Gondran o Installation du dongle sous Linux + dongle.py pour la configuration

automatique du dongle après redémarrage

22) du 30/01 au 01/02 : • Evaluation de la méthode à employer pour faire interagir le PDA/GPS avec notre

application o GPS : module interne par serial COM, module externe par bluetooth ? o Transmission des données à l’IHM par socket o Java, C++, Python ?

• Rendez-vous avec Franck Gechter o TX qui traitait de la réception de la trame NMEA d’un module GPS externe

codé en JAVA avec Mysaifu comme JVM, mais elle est instable et peu de librairies sont déployées, cela explique leur choix pour un module GPS externe alors que le PDA possède une puce GPS en interne

o Embedded C++ pour la communication entre un PDA et le ‘véhicule intelligent’, lourd à mettre en place quand on veut commencer à coder : Visual Studio pour Visual Embedded C++ (quid sous linux ?)



• Les avantages des 2 solutions ci-dessus ayant été recouvrés par PythonCE sans prendre en compte les inconvénients, c’est vers l’option Python que nous nous sommes orientés

23) du 04/02 au 05/02 :

• Installation de PyCE sous le Windows Mobile 5 du PDA • Communication série avec l’ouverture du port COM7 (avec la libraire ceserial.py) • Parse de la trame NMEA pour récupérer les coordonnées et la vitesse

24) du 06/02 au 07/02 :

• Mise en place de la communication par socket client/serveur entre l’IHM (Java) et le PDA (PythonCE)

• Transfert des données GPS du PDA à l'IHM • Transfert des données du plan de route de l'IHM au PDA

25) le 08/02 : Rendez-vous avec Jean-Charles Créput pour voir ensemble où interférer exactement,

avec le véhicule, pour qu’il ne tienne plus compte de la simulation, mais des coordonnées exactes de sa position

26) du 11/02 au 13/02 : • Modification de la classe véhicule

o prise en compte des coordonnées exactes du véhicule par retour de socket du PDA

o L’optimiseur n’optimise plus par simulation mais par rapport au véhicule

27) le 14/02 : Validation des 2 parties (IHM + PDA/GPS)



Chapitre 5 : Dans les Détails – Partie I.H.M. Nous allons maintenant reprendre quelques points du Journal de Bord (JdB) du chapitre précédent pour en détailler les informations et, de facto, rendre ce document plus ‘guide pratique’ que ‘documentation formelle’, comme me l’a suggéré mon tuteur de stage.

5.1 JdB - 1) : Sensibilisation aux métaheuristiques

Définition : Les métaheuristiques forment une famille d’algorithmes d’optimisation visant à résoudre des problèmes d’optimisation difficile pour lesquels on ne connaît pas de méthodes classiques plus efficaces.

5.1.1 Algorithmes Génétiques de base:

Les algorithmes génétiques s'inspirent de la théorie de l'évolution, initiée par Charles Darwin au XIXème siècle. Dans cette théorie, une population d'individus évolue grâce au mécanisme de la reproduction sexuée. Les individus les plus adaptés à leur milieu se reproduisent plus que les autres, favorisant les caractères les plus adaptés. Ainsi une girafe avec un cou plus long que les autres aura accès à plus de nourriture, et aura donc plus de chances de survivre et de se reproduire. Ses descendants auront un cou plus long, et en moyenne la population de girafe aura un cou plus long. Au niveau de l'ADN, la recombinaison de l'ADN des deux parents (lors de la reproduction) permet de générer différentes combinaisons de gènes. Il y a des chances qu'en recombinant l'ADN de deux parents bien adaptés, l'individu généré soit encore mieux adapté. Exemple :

Parent 1 Parent 2 Cou : long Cou : court Pattes : courtes Pattes : longues adaptation : moyenne adaptation : moyenne

peut donner à la génération suivante :

Fils 1 Fils 2 Fils 3 Cou : court Cou : court Cou : long Pattes : courtes Pattes : longues Pattes : longues adaptation : mauvaise adaptation : moyenne adaptation : bonne

Pour mieux faire comprendre le principe, imaginons le scénario suivant : une population initiale est composée de 4 individus.



Chaque individu est caractérisé par 3 traits : ses capacités de jardinier, sa qualité de cuisinier et ses envies cleptomanes. Chaque trait peut prendre 2 valeurs (0 ou 1), suivant que l’individu ait ou n’ait pas la caractéristique. L’environnement est modélisé par une fonction d’adéquation définie pour chacune des combinaisons des 3 caractéristiques ; par exemple l’individu (0 ;0 ;0) qui n’est ni jardinier, ni cuisinier, ni cleptomane, aura une qualité d’adéquation nulle, ce qui traduit le fait que, ne pouvant se fournir sa nourriture, il dépérira avant d’avoir pu se reproduire (on aura tout simplement pas assez de force pour le faire) ; l’individu (0 ;1 ;0) ne sera pas mieux loti car, malgré ses talents de cuisinier, il n’aura rien à se mettre sous la dent ; l’individu (1 ;0 ;0) aura néanmoins ses chances en se nourrissant de légumes crus. (0 ;0 ;1) survit en volant, tandis que (0 ;1 ;1) arrive à améliorer la qualité de ses vols en les cuisinant ; (1 ;0 ;1) combine ses vols avec les produits de son jardin et (1 ;1 ;0) est l’individu idéal. Quant à (1 ;1 ;1), il perd du temps et de l’énergie à voler pour son propre plaisir, ce qui lui donne une capacité d’adéquation inférieure à celle de (1 ;1 ;0). Ces considérations sont résumées dans le tableau suivant :

Individus qualité d’adéquation (0 ;0 ;0) 1 (0 ;0 ;1) 3 (0 ;1 ;0) 1 (0 ;1 ;1) 4 (1 ;0 ;0) 2 (1 ;0 ;1) 4 (1 ;1 ;0) 5 (1 ;1 ;1) 4

Supposons la population initiale constituée des individus: {(1 ;0 ;0), (0 ;1 ;0), (0 ;0 ;1), (1 ;1 ;1)}. Voyons comment agit un Algorithme Génétique pour trouver la solution optimale : Première phase :

évaluation des qualités d’adéquation (1 ;0 ;0) se voit attribuer un score de 2, (0 ;1 ;0) a un score de 1, (0 ;0 ;1) a 3, tandis que (1 ;1 ;1) a 4.

Deuxième phase : sélection L’algorithme attribue à chaque individu une chance de participer à la phase de reproduction proportionnelle au rapport de sa qualité d’adéquation par rapport à la qualité moyenne. Ainsi on attribuera à l’individu 1 la probabilité de 2/(2+1+3+4), soit 2 chances sur 10. Cela entraîne aussi qu’il aura en moyenne (2/10)x4 enfants (espérance mathématique) dans la génération suivante. On procède alors au tirage au sort, suivant le principe de "la roue de la fortune": 2/10



de la roue sont attribués à l'individu 1, 1/10 à l'individu 2, 3/10 à l'individu 3 et 4/10 à l'individu 4. La roue est lancée autant de fois qu'il y a d'individus dans la population. Supposons que le tirage ait donné: l'individu 4 (2 fois), l'individu 3 (1 fois) et l'individu 1 (1 fois). Nous sommes maintenant en présence d'une population intermédiaire: {(1;1;1), (1;1;1), (0;0;1), (1;0;0)}, respectivement appelés {1bis, 2bis, 3bis, 4bis}

Troisième phase : reproduction Au cours de cette phase, les couples sont choisis au hasard. Supposons que 1bis "aille avec" 4bis et 2bis avec 3bis. Des sites de croisement sont ensuite choisis au hasard:

1 1 | 1 et 1 | 1 1 1 0 | 0 0 | 0 1

ce qui donne: 1 1 0 1 0 1 1 0 1 0 1 1 Les 4 nouveaux membres sont donc: {(1;1;0), (1;0;1), (1;0;1), (0;1;1)}

Ils subissent alors des mutations (en général, la probabilité de mutation est très faible). Supposons que seule la caractéristique 2 du 3ème individu soit mutée. Finalement, la nouvelle population formant la deuxième génération sera : {(1;1;0), (1;0;1), (1;1;1), (0;1;1)} On remarque que l'individu idéal y est maintenant présent.

Ensuite, en recommençant itérativement les 3 phases ci-dessus, on tendra vers une population constituée presque exclusivement de (1;1;0) (qui a une fonction d'adéquation supérieur aux autres); il y aura cependant toujours quelques mutants pour préserver la diversité de la population et donc éventuellement réagir à un changement de la fonction d'adéquation suite à un changement quelconque de l'environnement. Algorithme génétique de base :

Pour chaque Individu dans Groupe Initialiser Individu Fin Pour Pour nombre_d’itérations Parent A := Sélection_d’un_Individu (Groupe) Parent B := Sélection_d’un_Individu (Groupe) Fils := Recombinaison (Parent A, Parent B) Si hasard > pourcentage Alors Appliquer_une_mutation_à Fils Fin Si Optimiser Fils // Optionnel Evaluer Fils Si Fils est_accepté_dans Groupe Alors Réinsérer Fils dans Groupe Fin Si Fin Pour



5.1.2 Algorithmes de la Colonie de Fourmis de base : L’idée originale provient de l’observation de l’exploitation des ressources alimentaires chez les fourmis. En effet, celles-ci, bien qu’ayant individuellement des capacités cognitives limitées, sont capables collectivement de trouver le chemin le plus court entre une source de nourriture et leur nid.

1. la première fourmi trouve la source de nourriture (F), via un chemin quelconque (a), puis revient au nid (N) en laissant derrière elle une piste de phéromone (b).

2. les fourmis empruntent indifféremment les quatre chemins possibles, mais le renforcement de la piste rend plus attractif le chemin le plus court.

3. les fourmis empruntent le chemin le plus court, les portions longues des autres chemins

perdent leur piste de phéromones.

En transposant informatiquement cette méthode et en l'adaptant au PVC (Problème du Voyageur de Commerce), on obtient l'algorithme suivant (proposé par Marco Dorigo pour son logiciel ACS) :

• On crée un ensemble d'agents (les fourmis, à rapprocher aux "individus" des algorithmes génétiques), qui coopèrent par l'intermédiaire des phéromones pour trouver le chemin le plus court du PVC.

Fig 10. Principe de la colonie de fourmis



• Les phéromones sont modélisées par un tableau de taille N x N (avec N le nombre de villes). Par exemple : float Phéromone[N*N]; Phéromone[i, j] représente la quantité de phéromones déposées par les fourmis sur le trajet reliant la ville i à la ville j.

• Le comportement des fourmis est modélisé ainsi : o La fourmi se place initialement sur une ville choisie au hasard o Elle choisie la ville suivante parmi les villes non encore visitées en suivant le chemin le

plus marqué par les phéromones

max_phéromone = 0; Pour Ville_courante allant de 1 à N Si Ville_courante pas encore visitée Si Phéromone[Ville_précédente, Ville_courante] > max_phéromone Ville_suivante := Ville_courante max_phéromone := Phéromone[Ville_précédente, Ville_courante] FinSi FinPour

• Elle dépose des phéromones sur le chemin qu'elle a emprunté (règle locale de mise à

jour des phéromones). On prend en compte l'"évaporation", ce qui donne une loi du genre :

Pheromone[i, j] := (1 - alpha) Pheromone[i, j] + alpha * K

Avec K une constante. La valeur de K recommandée par Dorigo et Gambardella est de 1 / ( N * Lmv ) avec N le nombre de villes du problème et Lmv la longueur du trajet calculé par la méthode du meilleur voisin ou une approximation.

Il faut faire des essais pour déterminer les valeurs optimales des différentes constantes (nombre de fourmis, alpha, K...)

5.1.3 Algorithmes de Recherche avec Tabous de base : Cette méthode est une métaheuristique itérative qualifiée de recherche locale au sens large. L'idée de la recherche avec tabous consiste, à partir d'une position donnée, à en explorer le voisinage et à choisir la position dans ce voisinage qui minimise la fonction objective. Il est essentiel de noter que cette opération peut conduire à augmenter la valeur de la fonction : c'est le cas lorsque tous les points du voisinage ont une valeur plus élevée. C'est à partir de ce mécanisme que l'on sort d'un minimum local.



Le risque cependant est qu'à l'étape suivante, on retombe dans le minimum local auquel on vient d'échapper. C'est pourquoi il faut que l'heuristique ait de la mémoire : le mécanisme consiste à interdire (d'où le nom de tabou) de revenir sur les dernières positions explorées. Les positions déjà explorées sont conservées dans une pile FIFO (appelée souvent liste taboue) d'une taille donnée, qui est un paramètre ajustable de l'heuristique. Cette pile doit conserver des positions complètes, ce qui dans certains types de problèmes, peut nécessiter l'archivage d'une grande quantité d'informations. Cette difficulté peut être contournée en ne gardant en mémoire que les mouvements précédents, associés à la valeur de la fonction à minimiser. Les démonstrations de convergence (capacité de l'algorithme à trouver le minimum global si le temps imparti tend vers l'infini) pour la recherche avec tabous existent, mais supposent des conditions strictes, rarement présentes en pratique. De nombreuses variantes existent, principalement au niveau de la définition du voisinage et de la manière de gérer la mémoire. Schéma de l’algorithme tabou de base :

x := solution aléatoire fmin := f(x) xmin := x TABOU := liste de solutions S(x), de longueur L TABOU := VIDE REPETER

générer un N-échantillon TEL QUE Si(x) ∈ voisinage S(x) et {x, Si(x)} ∉ TABOU

f(S(x)) = min[f(Si(x))] POUR 1 ≤i ≤N ajouter ({x, Si(x)}, TABOU) x := S(x) SI f(x) < fmin fmin := f(x) xmin := x FIN SI

JUSQU'A <conditions d'arrêt satisfaites>


5.2 JdB Pour aider effectiveRovéhicules etCe Panel eschaque véhMéthode se

5.3 JdB

Comme l’apfenêtre d’al’Evaluationnommé SIG

homme-msur PC et

Steve LAN

B – 9) : Aid

à comprenute, nous avt leur situatst intéressa

hicule. etOutput() d

B – 10) : JF

pplication daccueil qui n qui prend G sur lequel


NG – Rappo

de à la com

ndre les revons choisi ion (entre qnt car il do

de la classe I

rame Win

oit toujourspropose 3

les résultatnous avons

Fig


ort de Stag

mpréhens

elations entd'ajouter un

quelles requonne directe

IHM

nDOS au l

s pouvoir prdifférents

s d’une simlonguemen

12. Sélectio


ge – Labora

sion : Pan

tre Compann panel toujêtes ils se trement à l’u

ancemen

roposer la pmodes d’u

mulation pasnt travaillé.

n du mode d


atoire SET

el OUTPU

ny, Requestjours visiblerouvent). tilisateur le

nt

partie Simulautilisation : ssée et qui a

de l'applicat

des tourna léger.

/ UTBM

UT

ts, Vehiclese sur la droit

es informat

ation nous ala Simulat

affiche le rés

tion

Fig 11.

ées des

s, les buffete de l’écran

ions géogra

avons mis etion (déjà sultat, et en

. Panel pour

ST5

Page

ers route etn qui liste les

aphiques de

en place unedisponible)

nfin le mode

r les outputs

50

24

t s

e

e ), e

s



5.4 JdB – 12) : Nouvelle IHM Classe AddRequest : Pour le dernier mode (SIG) nous avons reconditionné l’IHM pour n’avoir plus qu’un bouton : ‘Ajoute Request’. Ce dernier, appelle un JPanel qui propose à l’utilisateur de saisir les informations de localisation de la requête. Après un clic sur le bouton "Ajouter", la classe AddRequest fait appel à la classe GetAddrCoor pour recevoir les coordonnées en WGS84 (système géodésique associé au système GPS, utilisé par Google Maps) de la localisation de la requête. Ces coordonnées sont ensuite converties en Lambert II étendu (si un jour on souhaite faire intervenir un S.I.G directement dans la StudiedArea) Pour l’instant notre application n’a qu’une compagnie située en plein centre de Belfort, aux coordonnées Lambert II étendu : 939891.3620309667, 2303046.5493371906 (Ces coordonnées sont définis dans la classe Constants : SIG_COMPANY_X et SIG_COMPANY_Y) On rescale notre requête par rapport à notre compagnie pour en déduire son px et son py sur la StudiedArea. On créé notre nouvelle requête au bon endroit (px,py) en l’informant du mieux possible sur ses attributs (son identifiant, les coordonnées Google Maps qu’on utilisera plus tard, sa longitude, sa latitude, le nom de sa rue, son code postal, sa ville). On rend la requête active pour pouvoir être servie et on l’ajoute à notre SetOfRequests. Classe GetAddrCoor : Cette classe va nous permettre d’interroger une première fois Google Maps pour récupérer les coordonnées de la requête que l’on veut créer. Une première difficulté a été de passer à travers le proxy de l’UTBM et les premières lignes de code de cette classe y sont consacrées. Une fois le proxy passé, on se connecte à l’URL : URL url=new URL("http://maps.google.com/maps/geo?q="

+ URLEncoder.encode(monAdresse, "UTF-8") +"&output=xml&key=ABQIAAAAGWhwg4im24cm8lfByfFAZRT9ADpIpFBh5OFabol7tYBiGTtMVhSY1_rf

t87Nj1w7Mp_vdIQB_CAKNA");

Détail : geo = appel de l’API de geocoding q = le query, auquel on transmet notre adresse sous la forme: rue,cp,ville,france avec par exemple (les fautes sont volontaires) : monAdresse = 8 bd antole frnce,blfort,france

Fig 13. Fenêtre de saisie de la localisation de la requête



output = le format de sortie que l’on veut traiter, dans notre cas c’est le xml car les balises sont faciles à parser key = la clé d’authentification à l’API, cette clé est gratuite, on l’obtient en s’enregistrant en tant qu’utilisateur de l’API, sans cette clé, on ne dispose d’aucun droit sur l’utilisation de l’API En retour on récupère donc un fichier XML avec toutes les informations qui nous intéressent (on notera que même avec des fautes de saisie, le traitement se fait) :

et nous garderons en fin de traitement (et si tout s’est bien passé) : Coordinates : Les coordonnées WGS84 DD (en degré décimal) de l’adresse, dans notre exemple : 6.843081,47.640703,0 ThoroughfareName : le nom complet de la rue, dans notre exemple on aura : 8 Boulevard Anatole France PostalCodeNumber : le code postal, dans notre exemple :

90000

Fig 14. Retour XML pour le geocoding



LocalityName : le nom correct de la ville (utile si on l’a mal écrit lors de la saisie), dans notre exemple : Belfort

Classe ConversionCoord : Cette classe est composée de 3 méthodes utiles :

• La conversion de DD (degré décimal) en DMS (degré, minute, seconde) se fait dans la méthode leLambert(string dd) qui prend en argument le string (WGS84 en DD) renvoyé par Google Maps

• WGS84toLambert2e(double d_long, double m_long, double s_long, char orientation_long, double d_lat, double m_lat, double s_lat, char

orientation_lat) qui convertie le WGS84 en Lambert II étendu en prenant en argument les coordonnées WGS84 en DMS (degré, minute, seconde)

• Lambert2eToWGS84(double x, double y) qui ne sert pas aujourd’hui, permet de faire la conversion inverse

5.5 JdB – 15) : ‘Véritable’ itinéraire Le principe de cette partie est de prendre en compte l’itinéraire exact (suivant les rues) d’une requête à une autre pour deux raisons :

• Un affichage sur carte, le vol d’oiseau ne donnant pas beaucoup d’information sur la localisation exacte du véhicule

• Envoyer ces informations sous forme de plan de route au véhicule pour qu’il ait la trajectoire la plus optimisée pour rejoindre la prochaine intervention

Le premier travail a été de déterminer dans quelle partie de l’application l’itinéraire devait être impliqué. On constate que cycliquement Company fait une demande de plan (getPlan(SoV)) à l’Optimizer qui le lui renvoie :

On se rend compte aussi qu’à chaque fois que la classe Optimizer reçoit une demande de plan, on a un appel à une méthode setEquivalentBackTOpt() de la classe SetOfVehicles (méthode qui va se charger de la copie)

Fig 15. Evenement getPlan entre Company et Otimizer



C’est donc dans cette dernière méthode qu’il a été le plus judicieux de faire intervenir la prise en charge du ‘véritable’ itinéraire. Le principe est défini comme tel : On a un tableau qui recense la liste de requêtes par véhicule avant l’optimisation et un autre qui regroupe la liste des requêtes par véhicule après optimisation (donc après retour du plan). Si les deux tableaux sont différents, on a donc un changement d’itinéraire pour un véhicule donné. Si un changement d’itinéraire a été détecté, on parcourt le nouveau tableau et on appelle la classe GetRouteCoor(string monadresse1, string monadresse2, string coordGMap) où monadresse1 et monadresse2 sont les adresses des requêtes, toujours suivant l’ordre du tableau, pour décrire les étapes de l’itinéraire. Classe GetRouteCoor : Cette classe suit exactement le même principe de fonctionnement que la classe GetAddrCoor vue en 5.4 à la différence près qu’elle ne traite pas le geocoding mais bien un trajet entre deux points. La connexion se fait donc par cette URL : URL url = new URL("http://maps.google.com/maps?saddr="

+ URLEncoder.encode(monAdresse1, "UTF-8") + ",france&daddr=" + URLEncoder.encode(monAdresse2, "UTF-8") + ",france&hl=fr&output=kml");

Par exemple pour aller de la Compagnie (située en plein centre de Belfort) à l’UTBM : http://maps.google.com/maps?saddr=belfort,france&daddr=8%20Boulevard%20Anatole%20France,Belfort,france&hl=fr&output=kml Détail : maps = l’appel de la fonction carte/itinéraire de Google Maps saddr = adresse de départ (monadresse1) daddr = adresse de destination (monadresse2) hl = langue dans laquelle on veut récupérer les informations de route (ici fr = en Français) output = le format de sortie, ici on choisi le KML pour la facilité du parse par balise (le résultat de la requête est donc un fichier KML dont un exemple est proposé en Annexe) On peut tirer de ce fichier une grande quantité d’informations que nous allons nous garder, comme par exemple

• Le plan de route qu’on utilisera à deux reprises : o Bulle d’information, sur le clic d’une route, sur le trajet généré avec la JSP o Plan de route transmis au PDA

• La distance et le temps de trajet • Les coordonnées des points de passage au format WGS84 pour la création de notre

propre KML qu’on transmettra après à la JSP


5.6 JdB Comme expaux autres aLe layering utiliser l’APDans notre

Exemple d’u <?xml ver<kml xmln<Placemar <de <na <Po </P</Placema</kml> Cet exempemplaceme La créationméthode (setEquivale On parcourt

• on c

• on a• on c• on a• on a• on d

homme-msur PC et

Steve LAN

B – 18) : Co

pliqué dansalternativespar fichier I Google Maprojet, ces i• Les diff

trajet • L’endro• L’endro

un fichier KM

rsion="1.0ns="http:/rk> scriptionme>UTBM Bint>

<coordoint> ark>

ple proposeent, ajouter

des fichierque la

entBackTOp

t le tableau créé un nouvo v + "id d

ajoute les enchoisi une coajoute l'empajoute le pladonne la list


NG – Rappo

ompositio

le 16) du Jos nous ont faKML (Keyhoaps avec desinformation

férents itiné

it (placemarit (placemar

ML qui poin

0" encodin//earth.go

>UTBM BelBelfort</n

inates>6.

e un point, des bulles d

rs KML pourecherche

pt() de la cla

des itinéraiveau fichier

du véhicule"ntêtes KML ouleur pourplacement dan de route te des coord


ort de Stag

on et Créa

ournal de Boait opter po

ole Markup s informatio

ns personnaéraires (line

rk) où se trork) où se tro

nte juste sur

ng="UTF-8"oogle.com/

lfort</desname>

843081,47

mais on d'informatio

r les itinérae de chsse SetOfVe

ires, et pourr KML avec u" + _ + "place

r la ligne trade la requêtepour la bull

données des


ge – Labora

ation du f

ord, les avanour cette sol

Language) fons personnlisées sont :s), avec pla

ouvent les reouve le véhic

r un endroit

"?> /kml/2.0">

scription>

7.640703,0

peut définion, entre aut

aires inhérehangement ehicles)

r chaque itinun FileWritee de l'itinéra

cée correspe pour le poe d'informa

s points de p


atoire SET

ichier KM

ntages confution. facilite auss

nalisées. : n de route,

equêtes à secule

(ici, l'UTBM

>

>

0</coordin

ir des lignetre.

ents à chaqd'itinérai

néraire : er aire dans le

ondant au dointage avec

tion passage pou

des tourna léger.

/ UTBM

ML

férés par Go

si grandeme

, entre chaq

ervir

M à Belfort) :

nates>

es, des ico

ue véhiculeires ou

tableau" + .

dessin de l'itc cet icône :

ur cet itinéra

ées des

oogle Maps

ent la tâche

que étape (

nes pour m

e se fait dan'véritable'

.kml

tinéraire

aire

ST5

Page

par rapport

e si l’on veut

requête) du

marquer un

ns la mêmeitinéraire

50

29

t

t

u

n

e e



Voici un fichier KML généré pour l'itinéraire numéro 2 du véhicule 9 : v9_2.kml qui proposera la couche qui va dessiner l'itinéraire entre Valdoie et Belfort :

Les fichiers KML correspondant à l'emplacement des véhicules sont créés dans l'IHM. Comme on a pour souci d'avoir notre carte Google Maps générée avec des informations temps-réel, c'est au moment du clic de souris (sur le véhicule ou la compagnie) que l'on génère le KML du/des véhicule(s) avec ses/leurs coordonnées précises.

Fig 16. Exemple de KML généré pour tracer l'itinéraire 2 du véhicule 9


Voici un ficvéhicule av

5.7 JdB La seule ponotre systèOn a donc office de reComme la d'applicatif Dans notreavions déjà http://maAZRT9ADpI Ensuite nouavons créés Dans la foexemple l'a

homme-msur PC et

Steve LAN

chier KML gec cet icône

B – 19) : M

ssibilité d'inme lourd autrès vite no

lai entre notplateforme

f web par Gl

e index.jsp, utilisée en

aps.googleIpFBh5OFab

us avons chs en 5.6.

nction initijout des dif


NG – Rappo

généré poue (vehicle.pn

ise en pla

nteragir aveucune interaoté la nécetre applicat

e de déveloassfish V2, l

on a donc 5.4) à l'adre

e.com/mapsbol7tYBiGT

hargé le scri

alize() on pfférents mod


ort de Stag

ur véhicule ng) :

ace de la 'J

ec l'API de Gaction ne peessité de fai

ion et le seroppement ql'option de l

commencé sse :

s?file=apiTtMVhSY1_r

pt de la lib

peut ajoutedes de vue,


ge – Labora

9 : v9_.km

Java Serv

Google Mapseut être direire intervenrvice web. qu'on a utia JSP a vite

par charge

i&v=2&rft87Nj1w7

rairie geoxm

er toutes sola barre de z


atoire SET

ml qui propo

er Page'

s est de pascte.

nir une plat

lisée (NetBeété évident

er le script d

&key=A7Mp_vdIQB_

ml.js pour le

ortes de cozoom, etc…

des tourna léger.

/ UTBM

osera la cou

sser par le Ja

eforme inte

eans IDE) pe et s'est av

de l'API ave

ABQIAAAAGW_CAKNA

e parse des

ommandes

ées des

uche qui va

avaScript, o

ermédiaire

propose l'hévérée efficac

ec la clé (ke

Whwg4im24c

fichiers KM

pour l'API

Fig 17.de KMpour l'empladu véh

ST5

Page

a pointer le

r à partir de

qui va faire

ébergementce.

ey que nous

cm8lfByfF

ML que nous

comme pa

Exemple ML généré

marquer acement

hicule 9

50

31

e

e

e

t

s

s

r


La classe Ge exml = nepour passernos fichiers map = new

5.8 Con Pour conclu Tout d'abor

1. VAL2. MO3. FRA4. DEL5. SEV6. DAN

homme-msur PC et

Steve LAN

eoXML y est

ew GeoXml(r à la partie

s KML, et do

w GMap2(do

nclusion p

ure, nous all

rd nous allonLDOIE NTBELIARD

AIS LLE VENANS NJOUTIN


NG – Rappo

t aussi insta

("exml", me où l'on va nc ajouter n

ocument.ge

par l'exem

ons voir un

ns saisir nos


ort de Stag

nciée :

map, null,utiliser la m

nos couches

etElementB

mple de la

exemple de

s requêtes :

Fig 18


ge – Labora

, {sidebarméthode pa (layers) sur

ById("map_

a Partie I.H

e l'applicatio

. Simulateu


atoire SET

rid:"the_sarseString dr la carte que

_canvas"))

H.M.

on, en mode

r après opti

des tourna léger.

/ UTBM

side_bar"}e cette clase nous avon

);

e SIG, en act

misation de

ées des

}); sse, afin de ns instanciée

tivité.

es requêtes

ST5

Page

faire passee ici :

saisies

50

32

r



Après optimisation nous constatons que 4 véhicules sont nécessaires pour servir nos 6 requêtes. • véhicule 9 : VALDOIE (1) • véhicule 10 : DELLE (4) -> MONTBELIARD (2) -> SEVENANS (5) • véhicule 11 : DANJOUTIN (6) • véhicule 12 : FRAIS (3)

Pour l'instant 10 fichiers KML ont été générés :

• Pour le véhicule 9 : o V9_0.kml : COMPAGNIE -> VALDOIE o V9_1.kml : VALDOIE -> COMPAGNIE

• Pour le véhicule 10 : o V10_0.kml : COMPAGNIE -> DELLE o V10_1.kml : DELLE -> MONTBELIARD o V10_2.kml : MONTBELIARD -> SEVENANS o V10_3.kml : SEVENANS -> COMPAGNIE

• Pour le véhicule 11 : o V11_0.kml : COMPAGNIE -> DANJOUTIN o V11_1.kml : DANJOUTIN -> COMPAGNIE

• Pour le véhicule 12 : o V12_0.kml : COMPAGNIE -> FRAIS o V12_1.kml : FRAIS -> COMPAGNIE

Pour accéder à l'interface GoogleMaps, on a deux options :

soit on clique sur la compagnie pour avoir le plan d'ensemble : tous les véhicules avec leurs itinéraires

au clic, 4 nouveaux fichiers KML correspondant aux véhicules sont générés (v9_.kml, v10_.kml, v11_.kml et v12_.kml) on appelle ensuite notre JSP : index.jsp : http://localhost:8080/GoogleMaps/index.jsp?all=oui&nbIti=12/2,11/2,10/4,9/2&leVeh=rep_v/ all = oui, on veut le plan global nbITI = id_vehicule/nb_itinéraire pour les index des boucles dans le traitement de la JSP leVeh = le répertoire où ont été générés les .kml



notre navigateur internet s'ouvre et on obtient :

La carte a été générée, avec tous les véhicules localisés à la compagnie et les 'véritables' itinéraires. Dans la liste de droite fournie par GeoXML on retrouve toutes nos couches (layers) correspondant aux KML générés (4 véhicules + 10 itinéraires) dans l'ordre :

Itinéraires du véhicule 9, Véhicule 9 (Vers Valdoie), Itinéraires du véhicule 10, Véhicule 10 (Vers Delle), Itinéraires du véhicule 11, Véhicule 11 (Vers Danjoutin), Itinéraires du véhicule 12, Véhicule 12 (Vers Frais).

soit on clique sur un véhicule en particulier pour avoir son trajet propre

Fig 19. Carte générée avec les 14 couches KML



par exemple le véhicule 10 avec un mode de visualisation mixte :

Par couche, on a le véhicule pointé à COMPAGNIE (Belfort Centre), le premier itinéraire en rose qui rejoint DELLE, le deuxième en bleu qui rejoint MONTBELIARD, le troisième en gris qui rejoint SEVENANS et enfin le dernier en brun qui revient vers COMPAGNIE (Belfort Centre). ou par exemple le véhicule 9 avec le plan de route sur l'itinéraire COMPAGNIE -> VALDOIE :

Fig 20. Carte générée pour l'itinéraire du véhicule 10 (en mode mixte)

Fig 21. Plan de route de l'itinéraire 1 du véhicule 9



Avec un clic sur la ligne verte kaki, qui correspond à la couche du fichier v9_0.kml, on obtient le plan de route pour cet itinéraire. Ce même plan de route a est envoyé au PDA si on considère la partie embarquée. (Toutes les cartes correspondant à cet exemple sont disponibles en Annexe)

Chapitre 6 : Dans les Détails – Partie Embarquée : PDA/GPS Pour les 2 dernières semaines de stage, nous avons entamé la partie pour l'assistant électronique doté d'une puce GPS. Après avoir réussi à faire communiquer (par ping) le PDA et le PC de bureau (avec toutes les contraintes décrites dans le JdB -21) le choix de python, pour l'applicatif embarqué, a été sélectionné. La communauté de python ne cessant de croitre, les librairies utiles fleurissent et son interprétation devient très stable même en environnement léger. Nous installons donc PythonCE.WM.cab sur notre Windows Mobile 5.

6.1 JdB – 23) : Port Série COM7 et Trame NMEA La puce GPS du module mobile utilise le port COM7 pour livrer ses informations. Les données qu'elle transite utilisent le protocole NMEA. La première étape a été de réussir à extraire une des trames NMEA du port. Pour les communications séries sur modèles embarqués, une librairie python a été développée : ceserial.py Après un import de la librairie on déclare un descripteur sur le bon port avec une vitesse de transfert : serial = Serial(port='COM7:', baudrate=4800) comme pour un fichier on aura un : serial.open() et un serial.close()

Fig 22. PythonCE installé sur le PDA



une fois le port ouvert, la lecture se fait simplement par un : serial.read(n) n étant le nombre de caractère à lire dans notre cas, comme les trames sont envoyées 'à la volée' sur le port com7 de la puce GPS, nous lisons dans une boucle, caractère par caractère ( serial.read(1) ) La trame NMEA : Il existe différents types de trames disponibles dans le protocole NMEA Chacune transporte son lot d'information et suivant la problématique, les choix vont se tourner vers l'une et/ou l'autre. Dans notre cas, ce qui peut être intéressant de récupérer c'est :

• la date et l'heure de la mesure • les coordonnées (longitude et latitude) • la vitesse au sol (savoir si par exemple le module est en mouvement ou pas)

La trame $GPRMC répond parfaitement à nos attentes, elle est composée des informations suivantes :

00 $GPRMC 01 Heure du fix 02 Alerte (A=OK ; V=WARNING) 03 Latitude au format ddmm.ss 04 Sens de la latitude (N=Nord=Positif, S=Sud=Négatif) 05 Longitude au format dddmm.ss 06 Sens de la longitude (E=Est=Positif, W=Ouest=Négatif) 07 Vitesse au sol en Knots (noeuds) 08 Cap vrai 09 Date du fix 10 Déclinaison magnétique 11 Sens de la déclinaison magnétique

C'est donc cette trame que nous utilisons dans notre système gps_iti.py (Annexe)

Fig 23. Répertoire de travail avec lancement de l'application



D'abord, suivant l'alerte ('A' ou 'V') nous affichons un OK si la trame est correctement renseignée et un NOK dans le cas contraire, par exemple lors d'une couverture trop pauvre en satellite. Par exemple dans la plateforme de recherche, à l'intérieur du bâtiment D de l'UTBM on obtient :

C'est après un petit temps d'adaptation à l'extérieur du bâtiment que nous obtenons un très satisfaisant :

6.2 JdB – 24) : Communication entre l'IHM et le système embarqué Pour le transfert des données GPS du PDA à l'IHM : l'IHM est serveur car il attend les données et le PDA est client car il envoie ses informations de positionnement et de vitesse. Pour le transfert des données de plan de route de l'IHM au PDA: l'IHM est client car il envoie les données dès qu'on constate un changement dans les itinéraires et le PDA est serveur car il attend les informations de guidage. Deux threads sont donc nécessaires dans notre système embarqué, un qui va se charger du transfert des données GPS et l'autre qui se chargera de réceptionner les informations de route.

Fig 24. Aucune information de localisation n'est détectée

Fig 25. Le système capte des informations de position



Dans un premier temps, comme l'IHM se retrouvera à communiquer avec plusieurs entités correspondant à chaque véhicule, il faut identifier notre appareil :

Comme pour les communications séries vues précédemment, une librairie existe aussi pour les communications par socket (socket.py) Détaillons la procédure pour comprendre les correspondances JAVA (partie IHM) et Python (partie embarquée)

• Dans le cadre du transfert des données GPS o Pour la partie embarquée :

Le socket étant de type Client, il est initialisé par : sGPS = socket.socket(socket.AF_INET, socket.SOCK_STREAM) Comme on ne veut pas qu'il soit bloquant on lui impose un timeout d'une seconde: sGPS.settimeout(1) La connexion se fait alors par : sGPS.connect((HOST, PORTGPS+VEHICULE))

HOST : adresse IP de notre PC de bureau (192.168.9.1) PORTGPS : port d'accès pour le transfert concernant les données GPS (50000) VEHICULE : décalage du PORTGPS de l'ID du véhicule pour que chacun ait un port dédié

Et les données sont envoyées par un sGPS.send(données) Enfin, on se déconnecte avec sGPS.close()

o Pour la partie fixe : C'est dans la classe Vehicle que l'on établi la communication car on obtient des informations sur ses attributs propres. Le socket est de type Serveur, il est initialisé par : s = new ServerSocket(50000+__pos); 50000 est le port correspondant à la communication GPS, là aussi on prend évidemment en compte le décalage en fonction de l'ID du véhicule (pour savoir avec qui on parle) Dès qu'une demande de connexion arrive on accepte par : Socket soc = s.accept();

Fig 26. Input pour l'ID du véhicule correspondant à ce PDA


Les informaBufferedRe

Elles sont e Exemple : Une fois quun px et un

• Dan

La communles mêmes à jour le tab

IMPORTANTLe booléen mobile. Si on utilistransmettreSi au contrainformation

homme-msur PC et

Steve LAN

ations transeader plec

nsuite parsé

e les donné py correspo

ns le cadre d

o Pour la nication se flignes qui d

bleau des iti

T : 'PDAwaitin

e l'applicatie des informaire on a un n ne sera jam


NG – Rappo

mises sont = new Buff

ées pour êtr

ées de positiondant aux

u transfert

partie fixe :fait dans la

détectent unnéraires.

ng' a été m

ion sans PDmations de r

PDA qui attmais transm

F


ort de Stag

lues avec unferedReader

re utilisable

ons de l'appcoordonnée

des informa

méthode s

n changeme

mis en place

DA 'PDAwairoute et l'optend des inf

mise.

Fig 27. Outp


ge – Labora

n BufferedRr(new Inpu

s.

pareil mobiles réelles du

ations sur le

setEquivalenent d'itinéra

e pour activ

iting' doit êtimisation n

formations,

ut des infor


atoire SET

eader : utStreamRea

e ont été reu véhicule:

e plan de rou

ntBackTOptire et interr

ver ou pas

être à FALSEne démarrer'PDAwaitin

rmations de

des tourna léger.

/ UTBM

ader(soc.ge

eçues, on les

ute

() de la clasrogent Goog

la commu

E, sinon ellera jamais. g' devra êtr

localisation

ées des

etInputStre

s convertit e

sse SetOfVegle Maps po

nication av

e essayera

re à TRUE, si

n de l'appare

ST5

Page

eam()));

et on obtient

ehicles, dansour remettre

vec la partie

toujours de

inon aucune

eil mobile

50

40

t

s e

e

e

e



Dans cette utilisation de l'application nous avons bien un PDA, notre booléen 'PDAwaiting' est par conséquent actif (TRUE). Le socket est de type Client et est initialisé par : sPDA = new Socket("192.168.9.2", 51000+i);

Cette fois le port de connexion est 51000 + le décalage de l'ID du véhicule On utilise un Stream pour faire transiter les informations à transmettre : os = new DataOutputStream(sPDA.getOutputStream()); On y écrit par l'intermédiaire de : os.writeBytes(itiPDA + "\nEND"); On referme le Stream et le socket : os.close(); sPDA.close();

o Pour la partie mobile : Le socket est créé avec son timeout :

sIti = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sIti.settimeout(1) On attend une demande de connexion, on écoute et on accepte : sIti.bind(('', PORTITI+VEHICULE)) Ici on bind de la part de n'importe qui sur le port PORTITI (51000), décalé de l'ID du véhicule sIti.listen(1) conn, addr = sIti.accept() Une fois que la connexion est établie, on reçoit les informations caractère par caractère : paquet = conn.recv(1) Enfin on referme le socket quand la transmission se termine par "END" (while not

data.endswith('END') : ) conn.close() Exemple : Quand l'applicatif de la partie fixe capte un changement d'itinéraire, il transmet les informations à la partie mobile :

Fig 28. Un nouvel itinéraire a été transmis par l'application fixe


Les deux thAlors que ldeuxième t

6.3 JdB Après plusieêtre affectéAussi, on dovirtuel, maiUne fois les

6.4 Con Reprenons deux itinéra

homme-msur PC et

Steve LAN

reads coexie premier

thread reçoit

B – 26) : At

eurs entretiée dans la moit prendre s qu'il prenn

s coordonné

nclusion p

l'exemple daires : COMP

Fig 29. Eta


NG – Rappo

stent bien : se charge dt bien un no

ttribution

iens avec Jeméthode acti

en compte ne en comp

ées (transmi

par l'exem

du chapitre PAGNIE -> V

at de l'IHM a


ort de Stag

d'envoyer douvel itinéra

n des coor

ean-Charles ivate() de lale datage pote la représeses par le PD

mple de la

précédent VALDOIE et V

après optim


ge – Labora

des informaaire.

rdonnées

Créput, il e classe Vehiour que l'opentation réeDA) reçues,

a Partie PD

avec notre VALDOIE ->

misation, san


atoire SET

tions sur le

du PDA à

en est ressoricle.

ptimizer ne celle de l'ention affecte l

DA/GPS

véhicule 9 COMPAGNI

ns réception

des tourna léger.

/ UTBM

e positionne

à l'IHM

rti que la po

continue paité mobile. e nouveau p

qui se voitE

d'informat

ées des

ement de l

osition du v

as à simuler

px et py au v

t attribuer u

ion du mod

ST5

Page

'appareil, le

véhicule doit

un véhicule

véhicule.

un trajet de

ule mobile

50

42

e

t

e

e


L'applicatif véhicule n'e

Nous sortonplus large, o

Retour vers

homme-msur PC et

Steve LAN

trouve un est pas visib

ns du bâtimon obtient :

le poste de


NG – Rappo

nouvel itinble dans l'IHM

ment D de l'U

travail et vo

Fig 3


ort de Stag

néraire et lM et le PDA

UTBM, et ap

oici ce que l

32. Etat de l'


ge – Labora

'envoie au A n'envoie qu

rès un temp

'IHM nous p

IHM après r


atoire SET

PDA qui nue des NOK)

ps d'adaptat

présente :

réception de

des tourna léger.

/ UTBM

'a pas de c) :

tion et une c

Fig 30. Réceptitinéra

Fig 31.Récepinformpositi

e la localisat

ées des

couverture

couverture s

tion d'un ire

. ption desmations deonnement

tion du véhi

ST5

Page

satellite (le

satellite

icule

50

43

e



Avec un aperçu sur carte (un clic sur le véhicule) :

Et lorsqu'on zoom sur le véhicule avec le mode mixte :

On retrouve bien l'appareil mobile devant le bâtiment D de l'UTBM

Fig 33. Carte générée avec la localisation réelle du véhicule (PDA)

Fig 34. Le PDA se trouve quelque part entre le boulevard Anatole France et la rue Ernest Mieg à Belfort



Chapitre 7 : Les travaux futurs … à l'attention des poseurs de tuiles

Pour améliorer notablement cette application, on peut envisager divers travaux complémentaires

• Pour l'IHM : o Envisager de prendre en compte la liste des coordonnées de points de passage de

Google Maps (ceux utilisés dans les fichiers KML), la convertir et relocaliser les VNodes (points d'optimisation) en fonction, de telle sorte que le trajet sur la StudiedArea suive exactement celui de Google Maps (au lieu d'avoir une ligne droite qui relie chaque requête)

• Pour l'appareil mobile : o Proposer à l'utilisateur de décider quand une requête a été servie, afin d'en avertir

l'IHM de l'application fixe et passer à la prochaine (s'il en reste) o Utiliser la JSP de l'application fixe pour voir apparaître dans le navigateur web du PDA

notre itinéraire cartographié o Proposer une interface graphique pour l'applicatif mobile avec par exemple WxPyCE ou

TkInter qui sont dédiés à Python o Proposer une interface de saisie pour le suivi du patient



Conclusion Dans le cadre de ce projet de fin d'études, j'ai trouvé plusieurs points d'intérêt qui m'ont permis d'approcher, d'un peu plus, les problématiques qu'on peut rencontrer dans un projet professionnel. Tout d'abord, le fait de reprendre un projet existant fait vite prendre conscience de l'importance de la documentation des travaux déjà réalisés. C'est pourquoi j'ai essayé de tenir un journal de bord afin de rendre ce rapport le plus clair et le plus complet possible. La diversité des domaines que j'ai eue la chance de rencontrer lors de ce stage a aussi été un point important dans l'intérêt que j'ai pu porter aux travaux. Dans un premier temps avec une rapide approche des méthodes d'optimisation par les métaheuristiques. Ensuite, avec l'importance de travailler avec un bon outil, et NetBeans IDE 6 a très bien répondu à mes attentes. La partie sur l'application fixe m'a aussi permis d'en savoir un peu plus sur les Systèmes d'Informations Géographiques, et dans notre cas les facettes intéressantes que peuvent fournir les services web (comme l'API Google Maps que j'ai très largement détaillée tout au long des pages qui précèdent). Enfin la partie embarquée a aussi été un moment fort dans mes motivations d'avancement, car l'interaction entre une application fixe, un service web, une partie mobile et son système de géolocalisation a été très enrichissante à mettre en place. Enfin, le travail dans un laboratoire de recherche prend tout son sens dans la profondeur que l'on peut donner à l'état des avancements et je remercie encore une fois Amir Hajjam pour l'autonomie qu'il m'a laissée.



Bibliographie Johann DREO, Alain PETROWSKI, Patrick SIARRY, Eric TAILLARD: Métaheuristiques pour l’optimisation difficile – Ed. Eyrolles (2003) Jean-Michel RENDERS : Algorithmes génétiques et réseaux de neurones – Ed. Hermes (1995) Mounir BOUSSEDJRA : Contribution à la résolution du problème du plus court chemin multiobjectif par algorithmes évolutionnistes : Application aux systèmes de transport intermodal – Thèse (2005) Sites Internet : Les métaheuristiques : http://www.enib.fr/~buche/public/enseignement/SoftComputing/MetaHeuristiques/MetaHeuristique_Optimisation.pdf La documentation de l'API Google Maps : http://code.google.com/apis/maps/documentation/ Les trames NMEA : http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=17661 Système d'Information Géographique (SIG) – Conversion de Coordonnées : http://www.forumsig.org



Annexe



Fichier KML retourné par l’API Google Maps après une requête sur un itinéraire entre : la Compagnie (Belfort Centre) et l’UTBM (8, boulevard Anatole France, Belfort) <?xml version="1.0" encoding="UTF-8" ?> <kml xmlns="http://earth.google.com/kml/2.0"> - <Document> <name>Belfort, France à 8 Boulevard Anatole France, 90000 Belfort, France</name> - <Style id="roadStyle"> <LineStyle><color>7fcf0064</color><width>6</width></LineStyle> </Style> - <Snippet> - <![CDATA[ <font size=+1><a href="http://maps.google.com/maps?saddr=belfort,france&daddr=8%20Boulevard%20Anatole%20France,Belfort,france&hl=fr">Version imprimable</a></font> ]]> </Snippet> - <Placemark> <name>Prendre la direction nord sur Place de la République vers Rue du Repos</name> - <description> - <![CDATA[ sur une distance de 54 m ]]> </description> <address>Belfort, France</address> <styleUrl>root://styleMaps#default+nicon=0x406+hicon=0x416</styleUrl> - <Point> <coordinates>6.862220,47.638830,0</coordinates> </Point> - <LookAt> <longitude>6.862220</longitude> <latitude>47.638830</latitude> <range>100.000000</range> <tilt>45.000000</tilt> <heading>7.990630</heading> </LookAt> </Placemark> - <Placemark> <name>Tourner à gauche pour rester sur Place de la République</name> - <description> - <![CDATA[ sur une distance de 77 m ]]> </description> <styleUrl>root://styleMaps#default+nicon=0x447+hicon=0x457</styleUrl> - <Point> <coordinates>6.862320,47.639310,0</coordinates> </Point> - <LookAt> <longitude>6.862320</longitude> <latitude>47.639310</latitude> <range>100.000000</range> <tilt>45.000000</tilt> <heading>7.990630</heading> </LookAt> </Placemark> - <Placemark> <name>Place de la République tourne légèrement à droite et devient Rue du Docteur Charles Fréry</name> - <description> - <![CDATA[ sur une distance de 0,2 km ]]> </description> <styleUrl>root://styleMaps#default+nicon=0x447+hicon=0x457</styleUrl>



- <Point> <coordinates>6.861350,47.639490,0</coordinates> </Point> - <LookAt> <longitude>6.861350</longitude> <latitude>47.639490</latitude> <range>100.000000</range> <tilt>45.000000</tilt> <heading>302.458771</heading> </LookAt> </Placemark> - <Placemark> <name>Tourner légèrement à droite sur D83</name> - <description> - <![CDATA[ sur une distance de 1,3 km ]]> </description> <styleUrl>root://styleMaps#default+nicon=0x447+hicon=0x457</styleUrl> - <Point> <coordinates>6.859630,47.640860,0</coordinates> </Point> - <LookAt> <longitude>6.859630</longitude> <latitude>47.640860</latitude> <range>100.000000</range> <tilt>45.000000</tilt> <heading>305.183258</heading> </LookAt> </Placemark> - <Placemark> <name>Arrivée à : 8 Boulevard Anatole France, 90000 Belfort, France</name> <address>8 Boulevard Anatole France, 90000 Belfort, France</address> <styleUrl>root://styleMaps#default+nicon=0x467+hicon=0x477</styleUrl> - <Point> <coordinates>6.843081,47.640706,0</coordinates> </Point> </Placemark> - <Placemark> <name>Itinéraire</name> - <description> - <![CDATA[ Distance: 1,6 km (environ 4 minutes)<br/>Données cartographiques ©2008 Tele Atlas ]]> </description> - <GeometryCollection> - <LineString> <coordinates>6.862220,47.638830,0.000000 6.862320,47.639310,0.000000 6.862320,47.639310,0.000000 6.861950,47.639330,0.000000 6.861560,47.639400,0.000000 6.861350,47.639490,0.000000 6.861350,47.639490,0.000000 6.861180,47.639690,0.000000 6.860030,47.640670,0.000000 6.859630,47.640860,0.000000 6.859630,47.640860,0.000000 6.859460,47.640950,0.000000 6.859430,47.641030,0.000000 6.859230,47.641180,0.000000 6.858940,47.641330,0.000000 6.858130,47.641660,0.000000 6.857240,47.641910,0.000000 6.856320,47.641830,0.000000 6.855620,47.641600,0.000000 6.853580,47.641390,0.000000 6.853420,47.641300,0.000000 6.852350,47.641260,0.000000 6.848940,47.641030,0.000000 6.848860,47.641070,0.000000 6.848440,47.641060,0.000000 6.843080,47.640710,0.000000</coordinates> </LineString> </GeometryCollection> <styleUrl>#roadStyle</styleUrl> </Placemark> </Document> </kml>

STEVE LANG - RAPPORT ST50job.steve-lang.com/download/Steve_Lang_Rapport_ST50.pdfDével tourn burea...

Documents

Transcript of STEVE LANG - RAPPORT ST50job.steve-lang.com/download/Steve_Lang_Rapport_ST50.pdfDével tourn burea...