Réalisation d’un outil de calcul du temps de parcours d’une route avec la prise en compte d’un trafic prédictif

2.2.1 Définition d’un graphe . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.2 Algorithme de Dijkstra . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.3 Algorithme de Bellman-Ford . . . . . . . . . . . . . . . . . . . . . . 16

2.2.4 Algorithme A étoile . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3

Introduction à la prédiction . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.1 La caractérisation des séries temporelles pour le choix de l’algo-

rithme de prédiction . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.1.1

La stationnarité par époque . . . . . . . . . . . . . . . . . 19

2.3.2 La méthode autorégressive

. . . . . . . . . . . . . . . . . . . . . . 19

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Chapitre 3 Analyse et spécification des besoins

21

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Système cible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

vii

3.4 Les acteurs

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5.1 Diagramme des cas d’utilisations

. . . . . . . . . . . . . . . . . . . 23

3.5.2 Génération d’un graphe automatique . . . . . . . . . . . . . . . . . 23

3.5.3 Prédiction du trafic . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5.4 Calcul du temps de parcours pour un chemin optimal

. . . . . . . 26

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Chapitre 4 Conception

27

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 Conception globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.1 Architecture générale . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.2 Utilisation des services web Nokia Here et Google maps . . . . . . . 28

4.1.3 L’architecture de l’environnement NodeJS . . . . . . . . . . . . . . 28

4.2 Conception détaillée

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.1 Etude de module de plus court temps de parcours d’un chemin . . . 30

4.2.1.1 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . 31

4.2.2 Etude de module de génération de graphe automatique . . . . . . . 32

4.2.2.1 Diagramme de séquence . . . . . . . . . . . . . . . . . . . 33

4.2.3 Etude de module de prédiction . . . . . . . . . . . . . . . . . . . . 34

4.2.3.1 Diagramme de séquence . . . . . . . . . . . . . . . . . . . 35

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Chapitre 5 Réalisation

37

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.1 Environnement matériel

. . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.2 Environnement Logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1.3 Choix des langages . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1.4 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . 39

viii

Table des matières

5.2

Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.1 Génération d’un graphe automatique . . . . . . . . . . . . . . . . . 40

5.2.2 Prédiction du trafic . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2.3 Plus court temps de parcours

. . . . . . . . . . . . . . . . . . . . . 46

5.2.4 Gestion du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Conclusion et Perspectives

Bibliographie

Webographie

Annexes

Annexe A Problèmes de cheminement

A.1 Algorithme de Dijkstra

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.1.1 Principe de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . .

A.1.2 Description de l’algorithme . . . . . . . . . . . . . . . . . . . . . .

A.2 Algorithme de Bellman-Ford . . . . . . . . . . . . . . . . . . . . . . . . . .

A.2.1 Principe de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . .

A.2.2 Description de l’algorithme . . . . . . . . . . . . . . . . . . . . . .

A.3 algorithme A étoile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.3.1 Les listes A étoile . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.3.2 Déroulement de l’algorithme

. . . . . . . . . . . . . . . . . . . . .

49

50

51

i

i

i

i

i

ii

ii

ii

iii

iii

iii

Table des figures

1.1 Réservation d’un taxi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 Portail web du service LeCab . . . . . . . . . . . . . . . . . . . . . . . . .

5

7

2.1 Architecture d’un serveur cartographique sur Internet . . . . . . . . . . . . 10

2.2 Affichage d’une route dans Google maps

. . . . . . . . . . . . . . . . . . . 14

2.3 Affichage d’une route dans Here maps . . . . . . . . . . . . . . . . . . . . . 15

2.4 Graphe des villes de France

. . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Diagramme des cas d’utilisations général

. . . . . . . . . . . . . . . . . . . 23

3.2 Diagramme des cas d’utilisations de génération d’un graphe automatique . 24

3.3 Diagramme des cas d’utilisations de prédiction du trafic routier

. . . . . . 25

3.4 Diagramme des cas d’utilisations du calcul du temps de parcours . . . . . . 26

4.1 Architecture générale de l’application. . . . . . . . . . . . . . . . . . . . . . 28

4.2 Architecture de l’environnement NodeJS . . . . . . . . . . . . . . . . . . . 29

4.3 Architecture d’un serveur NodeJS . . . . . . . . . . . . . . . . . . . . . . . 30

4.4 Architecture de module de plus court temps de parcours

. . . . . . . . . . 31

4.5 Diagramme de classe de plus court temps de parcours . . . . . . . . . . . . 32

4.6 Architecture de module de génération de graphe automatique . . . . . . . . 33

4.7 Diagramme de séquence de génération d’un graphe

. . . . . . . . . . . . . 34

4.8 Architecture de module de prédiction . . . . . . . . . . . . . . . . . . . . . 35

4.9 Diagramme de séquence de prédiction . . . . . . . . . . . . . . . . . . . . . 35

5.1 Ville de Paris englobée dans un grand carré

. . . . . . . . . . . . . . . . . 40

5.2 Ville de Paris divisée en carré . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.3 Le fichier des arcs générés

. . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.4 La distribution des steps dans la carte

. . . . . . . . . . . . . . . . . . . . 42

5.5 Nombre d’occurrences des steps . . . . . . . . . . . . . . . . . . . . . . . . 43

ix

x

Table des figures

5.6 La distribution des steps importants dans la carte . . . . . . . . . . . . . . 43

5.7 Un sous graphe de la ville de Paris

. . . . . . . . . . . . . . . . . . . . . . 44

5.8 Fichier d’une série temporelle . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.9 L’apprentissage des séries temporelles . . . . . . . . . . . . . . . . . . . . . 45

5.10 La prédiction des valeurs futures . . . . . . . . . . . . . . . . . . . . . . . . 46

5.11 Page web de réservation d’un VTC . . . . . . . . . . . . . . . . . . . . . . 47

5.12 Détail de la résercation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.13 Chronogramme des Tâches.

. . . . . . . . . . . . . . . . . . . . . . . . . . 48

Liste des tableaux

2.1 Tableau comparatif des SIGs . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.1 Environnement matériel utilisé.

. . . . . . . . . . . . . . . . . . . . . . . . 37

xi

Glossaire

Ajax : Asynchrones JavaScript And Xml.

API : Application Programming Interface.

CSV : Comma Separated Values.

PHP : Pre-HyperTexte-Processor.

ASP : Active Server Pages.

GIF : Graphics Interchange Format.

GPS : Global Positioning System.

JSON : JavaScript Object Notation.

IGN : Institut Géographique National.

JPEG : Joint Photographic Experts Group.

JSP : JavaServer Pages.

NPM : Node Package Manager

PNG : Portable Network Graphics.

POI : point of interest.

SGBD : Système de Gestion de Bases de Données.

SIG : Système d’information géographique.

SVG : Scalable Vector Graphics.

SWF : ShockWave Flash.

VTC : Voiture de Tourisme avec Chauffeur.

UML : Unified Modeling Language.

XML : EXtensible Markup Language.

WGS84 : World Geodetic System 84.

Introduction

La mise en place d’un système de localisation mondial GPS a permis des progrès

énormes dans le domaine militaire. L’amélioration de ce système coté précision et sa démocratisation au public, a créé des nouvelles opportunités pour les sociétés de ser- vices. Les clients mobiles sont les plus ciblés par ces services. Parmi eux nous citons les chauffeurs de taxi, les pilotes etc... .

Les clients et les chauffeurs de taxi ont beaucoup des problèmes concernant le temps de parcours et le trafic et aussi les réservations. Ces problèmes ont créé du dynamisme dans le marché européen de réseau de transport, avec plus de services et plus de perfor- mance. La société CLASS&CO SAS en partenariat avec la start-up CodersCloud vise à développer un service web qui remplit les critères exigées par les clients et les chauffeurs de taxi afin de mieux gérer le temps et permettre la réduction du coût.

Et comme solution à ces différents critères, la société CLASS&CO SAS a créé une branche pour étudier la faisabilité de concevoir et de réaliser un service web qui permet d’avoir pour un trajet donné et une date future donnée une estimation du temps de par- cours avec trafic. Ce service dans un premier temps va être utilisé dans la ville de Paris (la grande couronne).

C’est dans ce cadre que s’inscrit notre projet qui consiste, en premier lieu, à conce- voir et mettre en place une carte de la ville de Paris, en la transformant en un graphe des nœuds. En second lieu, il s’agit d’implémenter des algorithmes de graphe pour la déter- mination de plus court chemin en considérant le temps, le trajet . . . . En dernier lieu, il s’agit d’implémenter un module de prédiction pour l’estimation du temps de parcours.

Le présent rapport s’articule autour de cinq chapitres. Nous présenterons dans le premier chapitre le cadre du projet et l’organisme d’accueil, ainsi que le travail demandé. Dans le deuxième chapitre, nous présenterons une étude théorique approfondie sur la technologie web de web-mapping et les sciences mathématiques qui nous concerne, à savoir la prédiction et le problème de cheminement. Le troisième chapitre sera consacré à l’analyse et les spécifications des besoins.

1

2

INTRODUCTION

Nous détaillerons les utilisations de l’application proposée à travers les diagrammes des cas d’utilisation. La conception fera l’objet du quatrième chapitre. Dans le dernier chapitre intitulé réalisation nous montrons l’environnement de travail matériel et logiciel ainsi que les technologies utilisés. Nous concluons notre rapport par un bilan du projet, ainsi que des perspectives.

Chapitre1 Présentation Générale

Introduction

Dans ce chapitre, nous allons présenter brièvement notre projet. Tout d’abord nous

définissons le cadre de sa réalisation, par la suite nous présentons l’organisme Co-

dersCloud. Enfin nous introduisons le travail demandé.

1.1 Cadre Général

Notre travail s’inscrit dans le cadre du projet de fin d’étude ayant pour but l’enrichis- sement de notre formation et la mise en pratique des connaissances théoriques acquises. Ce projet, intitulé "Réalisation d’un outil de calcul du temps de parcours avec la prise en compte d’un trafic prédictif" est effectué au sein de la société CodersCloud, pour l’obtention du diplôme d’Ingénieur en Informatique.

1.2 Organisme d’accueil

1.2.1 CodersCloud

Depuis 2012, CodersCloud est basée entre Paris et Tunis. Elle a été créé par trois associés ayant fait les grandes écoles (Polytechnique, Mines ParisTech, Telecom ParisTech) et ayant travaillé pour des grands groupes français et internationaux (McKinsey, Glodman Sachs, Orange, Devoteam). . . .

CodersCloud est aussi une équipe jeune et dynamique d’une dizaine d’ingénieurs de haut niveau. Les équipes de développement sont basées à Tunis pour profiter du meilleur gisement de compétences francophones en terme de rapport qualité / prix. Les chefs de projets sont basés en région Parisienne pour une proximité client sans faille [N3]. Site Web : http://www.coderscloud.com/

3

4

Chapitre 1. Présentation Générale

1.3 Etude de l’existant

Il existe aujourd’hui et dans plusieurs villes du monde divers services de réservation de taxi offerts qui fonctionnent sur web et des smartphones comme par exemple Uber, LeCab, Taxiloc et Drive. Chaque service a ses caractéristiques qui répondent aux besoins des utilisateurs de taxi. En France, depuis un peu de temps, des entreprises spécialisées dans ce domaine commence à prendre place. Et comme tous les domaines, le début est difficile et plusieurs problèmes montent au surface. Ces problèmes créent une course entre les entreprises pour trouver des solutions et répondre aux attentes des clients. Le gagnant est celui qui prend le grand part du marché. Dans ce qui suit nous allons présenter deux services offerts sur Paris UBER et LeCab.

1.3.1 Service de voiture de tourisme avec chauffeur UBER

Uber est une start-up qui offre un service de voiture de tourisme avec chauffeur dis- ponible sur smartphone mettant en relation les usagers du service et des conducteurs de voitures de luxe disponibles à la location. Le service permet de localiser, via le téléphone mobile, les véhicules les plus proches et de les réserver. Le service et l’application mobile associée sont développés par la société homonyme, Uber, basée dans la ville californienne de San Francisco. Uber est présent dans 22 pays et 62 villes [N4].

L’utilisateur réserve instantanément une voiture de tourisme avec chauffeur. Puis, il attend l’arrivée de la voiture réservé le plus proche du chauffeur qui accepte cette course. Le client peut aussi consulter le portail web www.uber.com/cities/paris pour savoir le mode de fonctionnement et la tarification.

La réservation se fait par une application Android ou Ios, il suffit d’ouvrir l’applica- tion et sélectionner l’option uberPOP. Une fois votre position confirmée, deux clics suf- fisent pour commander la voiture la plus proche de vous. Suivez son arrivée en temps réel directement dans votre application. Le tarif est calculé selon la durée et le trajet de course.

La figure 1.1 illustre la phase de réservation d’un taxi. Les voitures disponibles les plus proches sont affichées sur l’écran. Le client, après avoir commandé une voiture pour

1.3. Etude de l’existant

5

une course, observe le déplacement de la voiture jusqu’à son arrivée.

Figure 1.1 – Réservation d’un taxi

Les problèmes du service Uber résident essentiellement dans : (cid:15) La facturation des courses : L’application uber calcule le tarif au fur et à mesure de la durée et du distance parcouru. A la fin du course un mail contenant la facture à payer. Le parcours d’une même course a plusieurs tarifs, ça dépend du chemin suivi et la vitesse de la voiture. Aussi, la marque de la voiture détermine la tarification à suivre.

(cid:15) Réservation en avance : Le client ne peut que commander instantanément et il doit attendre un certain temps pour que le taxi arrive. La durée d’attente dépend

6

Chapitre 1. Présentation Générale

de la distance qui sépare le client et le taxi.

(cid:15) le choix de chemin à parcouru :Le chauffeur est celui qui détermine le chemin à emprunter sans un outil qui l’aide à choisir le bon chemin à emprunter pour gagner du temps et du distance.

1.3.2 Service de voiture de tourisme avec chauffeur LeCab

LeCab est une start-up qui assure un service de voiture de tourisme avec chauffeur créée en décembre 2012 par Benjamin Cardoso. La commande peut être passée par aussi bien via leur site web www.lecab.fr que par téléphone ou via leur application (iPhone ou Android).

Une carte bancaire est exigée comme pour la plupart des VTC pour faire une ré- servation. La réservation se fait immédiatement ou à l’avance. Une fois la commande est passé, LeCab envoie alors un sms de confirmation avec le numéro de commande, le numéro de la plaque de votre chauffeur ainsi que le numéro de son portable en cas de problème. Ensuite, un deuxième sms de notification que le chauffeur est en route. Puis, un troisième sms de confirmation de l’arrivée de votre chauffeur [N5].

Le prix, fixé au moment de la commande pour éviter toute mauvaise surprise, com- prend les frais d’approche, dix minutes d’attente et le trajet. Les tarifs sont très com- pétitifs, fonctionnent par zones, le prix aller sera le même que le prix du retour. Il est également possible de convenir d’un trajet avec une ou plusieurs étapes. Si le client sou- haite effectuer une étape, non prévue initialement, le prix de la course sera alors recalculé et ajusté en fonction.

La figure 1.2 montre les différents services offerts sur le portail web de LeCab. Les prix, les commandes et les chauffeurs sont gérés par le site. Plusieurs informations sont disponibles aux usagers de ce service pour les bien renseigner. Des offres exceptionnelles sont mise à jour pour ses clients.

Les problèmes du service LeCab résident essentiellement dans : (cid:15) Le gain n’est pas garanti : Le service LeCab calcule les factures selon les distances parcourus. Ce qui fait que la facture ne prend pas en compte le temps de parcours que le chauffeur a dépensé pendant la course. Dans une heure ou le trafic est très dense le chauffeur sera le plus perdant. Aussi, si nous disons temps nous disons amortissement qui est n’est pas pris en compte dans cette formule.

(cid:15) Prix fixe des courses usuels : Le client trouve que plusieurs prix des courses usuels (comme ceux à destination des aéroports) ne sont pas étudiés car ces prix dé- passent les prix des taxis quand il n’ y a pas de trafic dense. Donc, Le client

1.3. Etude de l’existant

7

Figure 1.2 – Portail web du service LeCab

opte pour un taxi à compteur dans ses heures. Alors, les prix doivent prendre en compte le trafic pour qu’ils soient convenables dans toutes les heures.

(cid:15) Réservation et gestion de flotte : Pour savoir gérer la flotte convenablement et respecter les dates de réservation il faut respecter le critère du temps. Ce critère n’est pas traité dans ce service . Pour bien répondre aux demandes des clients la société doit avoir une grande flotte. Donc, le service devient n’est pas pratique pour les chauffeurs à cause d’avoir moins de course.

1.3.3 Etude comparative

Après avoir étudié les deux services de VTC LeCab et Uber, nous passons à la réalisation d’une étude comparative de ces deux services. Nous commençons par le critère le plus attractif chez les clients de VTC , le prix. Dans les deux entreprises, le prix n’est pas étudié pour que le client et le chauffeur sortent gagnants tous les deux. LeCab fixe le prix avant le début de la course contrairement à Uber qui envoie la facture après la fin de course ce qui rend LeCAb plus avantageux pour les clients qui n’aiment pas les factures imprévues. Uber ne dispose pas de la réservation à l’avance ce qui rend toute la flotte disponible mieux que Lecab ce qui minimise la durée d’attente de voiture tandis que LeCab joue le plus sur la réservation à l’avance. LeCab offre des prix fixe pour certaines destinations et il fait des promotions selon les périodes. Concernant la prise en compte du

8

Chapitre 1. Présentation Générale

trafic, les deux entreprises ne tiennent pas compte jusqu’à maintenant de ce paramètre.

1.4 Objectif du projet

Pour remédier aux problèmes cités précédemment nous sommes invités à réaliser ce projet qui a pour objectif de réaliser un service web permet d’avoir pour un trajet donné et une date future donnée une estimation de le temps de parcours avec trafic.

Ce projet s’effectue en trois étapes :

1. Création d’un graphe automatique pour la ville de Paris :Cette étape sert à la préparation du terrain pour la création d’une structure adéquate qui permet d’appliquer les algorithmes du plus court chemin pour l’obtention d’une durée de parcours. Pour ce faire il faut tout d’abord assurer un bon choix des coordonnées pour la formation d’un graphe de la ville de Paris d’une manière automatique. Puis, les coordonnées doivent être affichées sur une carte pour la phase de validation.

2. Déterminer le temps optimal de parcours en trafic entre deux coordon- nées géographique dans la ville de Paris : Cette étape consiste à concevoir et développer un outil qui prendre en paramètres les coordonnées deux points avec une date donnée qui se charge de créer un graphe avec les données qui cor- respondent à la date donnée puis nous faisons appel aux algorithmes de plus court chemin pour déterminer le temps de parcours optimal.

3. Intégration d’un module de prédiction : Cette étape consiste à créer un modèle statistique pour les séries temporelles des données du trafic Afin de per- mettre la prédiction du trafic pour le calcul du temps du parcours pour une date future.

Conclusion

Dans ce chapitre nous avons présenté l’organisme d’accueil et donné un aperçu sur le cadre du projet. Le chapitre suivant sera consacré à l’étude des différents concepts théoriques sur lesquels se base ce projet.

Chapitre2 Etat De L’art

Introduction

Dans ce chapitre, nous allons explorer les axes de recherche qui ont été étudiés à

travers ce projet. Notre politique de présentation vise l’assimilation du concept du point de vue théorique pour passer, en ayant des bases solides, à l’aspect pratique ou plutôt technique. Nous aborderons, dans un premier temps les services de cartographie en ligne. Puis nous présenterons le problème de cheminement dans un graphe et finalement les modèles statistiques .

2.1 Cartographie en ligne (Web-Mapping)

2.1.1 Généralités

Le Web mapping est représenté dans la publication des serveurs cartographiques

(SIG) sur internet. Un serveur cartographique SIG sur internet est un serveur Internet doté des fonctionnalités d’un véritable système d’information géographique. Un tel serveur se présente sous forme d’un logiciel installé sur une machine serveur web classique et permettant de répondre aux requêtes de type géographiques [N1].

2.1.2 Fonctionnement du Web mapping

Comme vous pouvez remarquer sur la figure 2.1, un serveur SIG possède les princi- pales fonctions suivantes : le stockage, le traitement et la diffusion des cartes et informa- tions géographiques via le réseau internet [B8].

2.1.2.1 Le stockage

Pour assurer sa fonction de stockage, le serveur SIG possède deux couches :

9

10

Chapitre 2. Etat De L’art

Figure 2.1 – Architecture d’un serveur cartographique sur Internet

Source : Serveur Cartographique et SIG interactifs en ligne M2 IASIG 2010

– Une couche dédiée aux données supportées par un SGBD géographique à l’instar de PostGresql avec son extension Post Gis, ou Oracle avec Oracle spatial etc. . .

– Des images géographiques référencées comme des cartes géographiques.

2.1.2.2 Le traitement

Pour le traitement, Un SIG Web est doté d’un serveur web, et d’un serveur de scripts (PHP, ASP, ou JSP) qui le rendent capable d’assurer les services de base d’un véritable moteur SIG, au-delà du stockage des données, c’est à dire la possibilité d’effectuer des requêtes à composante spatiale :

1. inclusion / juxtaposition / croisement spatial etc. . . .

2. calculs de longueurs et superficies.

3. mesure de distances, zones tampons.

4. mise à jour des données graphiques et attributaires.

5. assemblage et habillage graphiques des couches d’information pour obtenir une

carte.

2.1.2.3 La diffusion

Le serveur SIG va donc ajouter aux fonctions habituelles d’un serveur Internet des fonctions en relation avec la gestion et le traitement de données graphiques géo référencées. Cette fonction permettra aux utilisateurs indépendamment de leur situation géographique d’obtenir des informations géographiques sur un secteur de son choix. Enfin le serveur SIG

2.1. Cartographie en ligne (Web-Mapping)

11

devra de ce fait être capable de retourner l’information sous une forme adaptée à l’interface Internet, c’est à dire au site affiché dans le navigateur de la machine cliente. Cela suppose en particulier la capacité de transformer les données graphiques et alphanumériques issues d’une requête dans le SGDB dans un format compatible avec les navigateurs : GIF, jpeg ou png pour les bitmaps et svg, swf (flash), pour les vecteurs (plugin nécessaire).

2.1.3 Le Datamining

Le data-mining est l’ensemble de techniques d’extraction d’informations d’ordre pré- visionnel à partir de grandes bases de données. C’est un domaine connexe de l’analyse géo spatiale qui est encore assez peu passé dans l’usage courant des utilisateurs de SIG. Les outils de classification, de segmentation et de visualisation sont pourtant directement utiles pour un utilisateur des systèmes d’information géographique. Les SIG de par leur grande capacité à fédérer des masses importantes et diversifiées d’informations théma- tiques autour d’une carte géographique représentent une plateforme de développement du datamining.

2.1.4 Quelques APIs sig web en ligne

Depuis 2005, de nombreuses entreprises leader sur Internet comme Yahoo, Microsoft ,Nokia et Google se sont lancées dans le développement des services cartographiques en ligne accompagnés des API pouvant permettre aux développeurs d’intégrer dans leurs application SIG en ligne des fonds de carte provenant de leur source. Ces géants d’internet ont été joints dans leur initiative par certains organismes étatiques comme l’IGN en France et L’Ordonnance Survey au Royaumes Unis. De plus en plus les services offerts par ces organismes permettent aux développeurs de représenter leurs propres données au-dessus des fonds de cartes servies et d’utiliser les nombreuses fonctions d’interactivités avec la carte mise à leur disposition. Ces fonctions couvrent la totalité des besoins de l’analyse spatiale (Zoom, réaction au click, calcul de distance, classification des phénomènes spatiaux etc. . . ).

L’avantage de ces solutions, réside dans le fait qu’il n’y a plus nécessite d’installer un serveur de cartographie supplémentaire. C’est le navigateur qui exécute les fonctions d’affichage et d’interactivités cartographique grâce au JavaScript téléchargé depuis le ser- veur de ces organismes. Du coup le gain en temps d’affichage est remarquable par rapport aux serveurs de cartographie classiques.

Le tableau 2.1 comparatif montre les différentes fonctionnalités de ses quatre SIGs ce qui aide les utilisateurs à choisir le mieux. Dans notre cas Google API et Here API qui nous conviennent. Google API se démarque parmi tous ces géants des services car- tographiques du fait de sa grande base de données spatiale réutilisable et de ses facilités

12

Chapitre 2. Etat De L’art

offertes aux développeurs et Here API est placé leader dans le domaine de données de trafic pour la création d’une base de données du trafic.

Table 2.1 – Tableau comparatif des SIGs

Bing Maps Google Maps Here Yahoo Maps

Société En voiture En transports en commun En vélo A pieds Info-traffic Orthophoto Relief Routes Cadastre Ordnance Survey Maps Collins Bartholomew Maps Vue à vol d’oiseau Création de cartes Ajout de POI Modification du fond de plan Plan de lieu API Geocoding Web Service Directions Web Service Trafic Web Service

Microsoft Oui Oui USA, UK Non Oui Oui Oui Oui Oui Non Oui Oui Oui Oui Oui Non Oui Oui Oui Oui

Google Oui Oui USA Oui Oui Oui Oui Oui Oui Oui USA Non Non Oui Oui Oui Oui Oui Oui

Oui

Nokia Oui Oui Oui Oui Non Oui Non Oui Non Non Non Non Non Oui Non Non Oui

Oui Oui

Yahoo Oui Non Non Oui Non Oui Oui Oui Non Non Non Non

Non Non

2.1.5 Google maps API

Google maps est un serveur cartographique disponible sur le web à l’adresse

http://maps.google.fr. Il couvre l’ensemble des données cartographiques mondiales. Google maps utilise comme système le WGS84 basé sur le GPS. Les utilisateurs du web peuvent interroger Google maps comme tout autre service de renseignement pour obtenir des informations géolocalisées sur une entreprise, un site touristique, une école etc..., Bref pour rechercher des lieux préalablement indexés sur la carte Google. L’efficacité de Google maps réside dans le fait que Google exploite sa technique de moteur de recherche classique avec Ajax pour rendre rapide et conviviaux l’affichage et les rafraîchissements des cartes sur le web. Google API comme nous l’avons vu au paragraphe précédent, offre une multitude de fonctions aux développeurs leurs permettant d’intégrer son fond de carte dans leur application et surtout d’interagir sur ces carte avec leur propres base de données attributaires. L’affichage d’une carte est déclenché par l’appel d’une fonction JavaScript portant les paramètres sur les dimensions du cadre d’affichage, le niveau de zoom, le point

2.1. Cartographie en ligne (Web-Mapping)

13

central. Les données attributaires du client peuvent être également ajoutées à la carte sous forme de couche géographique par appel des fonctions JavaScript appropriés comme nous le verrons dans notre travail[N2].

2.1.5.1 Google geocoding api

L’API Geocoding de Google maps est très utile lorsque vous souhaitez récupérer des coordonnées GPS à partir d’une adresse (l’inverse étant également possible). Ce que facilite la tâche des développeurs pour cacher les détails aux utilisateurs qui connaissent pas préalablement qu’est-ce qu’une coordonnées géographique. L’appel de l’API Geocoding se fait côté client à l’aide d’une URL :

http://maps.googleapis.com/maps/api/geocode/json?address=\%s\&sensor=false

Par exemple, pour trouver les coordonnées GPS d’une adresse, l’URL sera :

http://maps.googleapis.com/maps/api/geocode/json?address=546\%20rue\%20Baruch\

%20de\%20Spinoza,\%20Avignon\&sensor=false

Cet appel vous renverra un résultat au format JSON qu’il sera possible d’exploiter

par la suite.

2.1.5.2 Google maps directions

L’API Direction de Google maps permet essentiellement d’obtenir un chemin entre deux coordonnées GPS s’il existe. L’utilisation de l’api se fait soit par une requête au serveur directement via la barre de L’URL du navigateur soit par un code JavaScript implémenté dans une page web. La première méthode permet l’extraction des données relative au route entre un point de départ et un point d’arrivée, cette requête prend la forme ci-dessous et renverra un résultat au format JSON ou XML :

https://maps.googleapis.com/maps/api/directions/output?parameters

La deuxième méthode se fait par l’appel de l’api JavaScript de Google maps direction et en appelant les fonctions concernées on obtient une carte avec la route voulue dessinée. La figure 2.2 illustre le résultat d’exécution du code JavaScript coté client.

2.1.6 Here maps API

Here maps api est une API de service Web qui offre un acheminement facile et rapide

pour plusieurs régions du monde. L’API offre les fonctionnalités suivantes : (cid:15) Calculer un itinéraire pour un ensemble de points d’intérêts. (cid:15) Mettre à jour un itinéraire précédemment calculé. (cid:15) Calculer un itinéraire isoline.

14

Chapitre 2. Etat De L’art

Figure 2.2 – Affichage d’une route dans Google maps

Here maps api est plus adapté au monde du transport. Il permet d’obtenir plusieurs informations nécessaires sur les routes, le trafic, les restrictions . . . . Parmi les informa- tions, nous citons état de la route, classifications de réseau, passages bloqués, restrictions spéciales, manœuvres restreintes, routes à péage, catégories de vitesse [N6] .

Cet api est composé de quatre services principaux :

*le service calculate route : il permet de retourner un itinéraire entre deux points en se basant sur la formule du plus court chemin. L’appel de ce service se fait par une requête de cette forme http://route.nlp.nokia.com/routing/6.2/calculateroute{format}?<parameter> =<value> Les paramètres déterminent le mode utilisé (piéton, véhicule ...), le passage par les autoroutes, l’affichage des routes utilisés. Le format soit json soit xml. *le service getroute : il permet de consulter un itinéraire déjà consulté avant par son id. La requête qui appelle ce service suit la forme suivante : http://route.nlp.nokia.com/routing/getroute.{format}?routeid=<ROUTEID>\&<parameter> =<value>. routeid représente l’id d’une route enregistré dans la base de here. Les paramètres sont les mêmes de ceux de service précédent. *service getlinkinfo :il permet de retourner des informations détaillées sur une route. Nous pouvons savoir avec ce service les tronçons d’une route, dans quelle cité, dans quel dépar- tement, sa longueur . . . . L’a