CETE Méditerranée Université Aix-Marseille Polytech MarseilleIUT Informatique Aix

CALCUL D’INDICATEURS D’ACCESSIBILITÉ AVEC LE

LOGICIEL LIBRE OPENTRIPPLANNER

Rapport de stage

NOTICE ANALYTIQUEOrganisme commanditaire :CETE Méditerranée, DGITM, CERTU

Titre : Calcul d’indicateurs d’accessibilité avec le logiciel libre OpenTripPlanner

Sous-titre : Langue : FrançaisOrganismes auteursUniversité AMU, CETE Med

Rédacteurs ou coordonnateursVALLIERE Brice, MARTYChristopher, Patrick GENDRE

Date Juin 2013

Résumé :L’accessibilité transport est un indicateur important voire essentiel de la qualité de service d’une offre detransport pour les pouvoirs publics ; la production de cartes isochrones est un outil pertinent pour représentercet indicateur, qui présente l’intérêt d’être à la fois compréhensible du grand public, des élus et destechniciens.Le CERTU a lancé en 2013 un travail de recensement des pratiques en matière d’accessibilité transport : quelstypes d’étude, quels sont les indicateurs calculés, quels sont les outils pour calculer les indicateurs et lesreprésenter (notamment sous forme de carte).

Dans le cadre de ce travail, le CETE Méditerranée a proposé de présenter le logiciel libre OpenTripPlannerAnalyst, identifié depuis quelques temps comme le logiciel libre de référence pour la recherche d’itinérairesmultimodaux, et qui est doté d’un module appelé Analyst, destiné justement à produire des indicateursd’accessibilité.

Ce logiciel a atteint un bon niveau de maturité depuis quelques mois et bénéficie désormais de l’accès à desdonnées décrivant les réseaux de transport sous licence open data, tant pour la voirie (OSM) que pour letransport collectif, qui jusqu’à récemment étaient indisponibles ou très difficiles à obtenir, et constituaient sansdoute l’obstacle principal pour développer l’usage de l’accessibilité dans les études des réseaux de transport.En outre, le développeur principal de ce logiciel est basé en France, ce qui est un atout important pour encomprendre le fonctionnement et les possibilités.

Ce rapport présente le travail réalisé par Christopher Marty, stagiaire en 2ème année de l’IUT informatiqued’Aix, et Brice Vallière, en 1ère année à Polytech Marseille :- installation du logiciel sous linux- test de l'application web de recherche d'itinéraire avec des données réelles (open data: Rennes, Marseille)- test de l'application web de calculs d'isochrones Analyst- premiers tests des outils de calcul d'indicateurs d'accessibilité Batch AnalystLa documentation d’OTP reste très incomplète sur les détails d’Analyst notamment, et une bonne partie dustage a consisté à explorer les fonctionnalités pour essayer de comprendre à quoi servait tel ou tel paramètre.Nous avons réussi à faire fonctionner l’application avec des données réelles ( Marseille, Rennes ...), maisn’avons eu le temps d’explorer sérieusement la richesse des possibilités offertes par Analyst pour le calculd’indicateurs d’accessibilité. Néanmoins il ne manquerait sans doute pas grand chose pour mettre en place une plate-forme opérationnelle.Pour la suite :- d’installer un serveur visible sur l’internet avec des données réelles (celles de Marseile par exemple, publiéessur http://www.lepilote.com/presentation/?rub_code=92)- de développer des calculs d’indicateurs d’accessibilité dans le même esprit que walkscore / transitscore, maisavec un score d’accessibilité pondéré par l’accès à des lieux publics (écoles, hôpitaux) plutôt que privés(restaurants, spectacles...), en utilisant le mécanisme d’agrégation / accumulation d’OTP Analyst.

Mots clés : transport public, accessibilitétransport, logiciel libre, application web

Diffusion :Version électronique

Nombre de pages :20 pages

Confidentialité :Non

Bibliographie :Oui

Mise à jour du 25/06/13

Sommaire

Table des matières

INTRODUCTION .......................................................................................................................................... 5

CONTEXTE.............................................................................................................................................................5LE CETE MÉDITERRANÉE.......................................................................................................................................5INDICATEURS D’ACCESSIBILITÉ TRANSPORT...................................................................................................................5OBJECTIFS DU STAGE..............................................................................................................................................6DÉMARCHE............................................................................................................................................................6CONTENU DU RAPPORT............................................................................................................................................6

ENVIRONNEMENT TECHNIQUE ............................................................................................................ 8

LES LOGICIELS.......................................................................................................................................................8OPENTRIPPLANNER.................................................................................................................................................8CHOUETTE ET GTFS FEED VALIDATOR.....................................................................................................................9LES DONNÉES.........................................................................................................................................................9LES DONNÉES DE TRANSPORT PUBLIC...........................................................................................................................9LES DONNÉES DE VOIRIE..........................................................................................................................................10

MISE EN PLACE DE L’ENVIRONNEMENT DE TRAVAIL ................................................................ 11

INSTALLATION DE L'ENVIRONNEMENT DE TRAVAIL....................................................................................................11CRÉATION DE LA BASE DE DONNÉES ET MISE EN PLACE DE L'APPLICATION..................................................................11COMPILATION DU GRAPHE.......................................................................................................................................11SERVEUR WEB APPLICATIF.......................................................................................................................................12UTILISATION DE L’APPLICATION DE RECHERCHE D’ITINÉRAIRE :.....................................................................................12UTILISATION DE L’APPLICATION DE RECHERCHE D’ISOCHRONES :...................................................................................14

ANALYST EN MODE BATCH .................................................................................................................. 16

PRINCIPE.............................................................................................................................................................16DÉTAILS DE L’API...............................................................................................................................................16MISE EN ŒUVRE : TESTS AVEC DES DONNÉES RÉELLES..............................................................................................18

CONCLUSIONS ET SUITES À DONNER ................................................................................................ 19

EN RÉSUMÉ...........................................................................................................................................................19PERSPECTIVES......................................................................................................................................................19

ANNEXE : RÉFÉRENCES ......................................................................................................................... 20

Remerciements.

Nous remercions M Andrew Byrd, Mme Ventimiglia Véronique, Lucas Jolly.

I. INTRODUCTION

Le présent rapport décrit le travail effectué par Christopher Marty lors de son stage de 2ème annéeà l’IUT d’informatique d’Aix-en-Provence, effectué au CETE Méditerranée d'avril à juin 2013 etBrice Vallière, étudiant en 1ère année à Polytech Marseille en stage au CETE Méditerranéependant le mois de juin 2013.

A. Contexte

1. Le CETE Méditerranée

Le CETE (Centre d’Etudes Techniques de l’Equipement) Méditerranée est un service technique duministère du développement durable. http://www.cete-mediterranee.fr. Avec environ 400 agents, ses activités sont très nombreuses : études, expertises, conseils,assistance à maîtrise d’œuvre, recherche, méthodologie, animations de réseaux, formation, avistechnique, essais de laboratoire et contrôles de chantier. Le CETE Méditerranée fait partie duréseau scientifique et technique du Ministère qui deviendra un établissement public début 2014,baptisé CEREMA1.

Le CETE Méditerranée contribue à l’action du ministère du développement durable en vue dedévelopper l’information sur tous les modes de transports, dite ‘information multimodale’. Monstage a été effectué au sein du département DCEDI, dans la mission MIM. La mission InformationMultimodale2 est un petit service de 2 personnes qui contribue à l’action de l’Agence Française del’Information Multimodale et de la Billettique3 , au travail de capitalisation des connaissances etd’animation technique du CERTU (un service technique central du ministère basé à Lyon), ainsiqu’au programme de recherche et développement pour l’innovation dans les services de mobilitéPREDIM (www.predim.org). Dans ce cadre, la mission contribue en particulier à la mise en œuvred’un annuaire des sources d’information transport www.passim. info et d’un logiciel librewww.chouette.mobi permettant la validation, l’échange et l’édition de données décrivant l’offre deréseaux de transport public conformément à un profil d’échange normalisé (XML Neptune).Avec la généralisation en France de Systèmes d’Information Multimodale (SIM), projets fédérantles collectivités autorités autorités organisatrices de transport (AOT) en vue de mutualiser lesdonnées de Transport Collectif (TC) et multimodale, et de fournir aux usagers une vue d’ensemblesur toutes les solutions de mobilité alternatives à la voiture particulière sur un territoire, de plus enplus de bases de données d’offre de TC sont disponibles à l’échelle de régions ou dedépartements. Ces données permettent non seulement d’informer les usagers, mais peuvent aussiêtre utiles pour d’autres applications, en particulier les études sur l’offre de transport.

2. Indicateurs d’accessibilité transport

L’accessibilité transport (nombres de services accessibles, ou distance accessible à partir d’un lieuen un temps donné) est un indicateur important voire essentiel de la qualité de service d’une offrede transport pour les pouvoirs publics ; la production de cartes isochrones est un outil pertinent1 http://www.cerema.fr

2 http://www.cete-mediterranee.fr/tt13/www/rubrique.php3?id_rubrique=27

3 http://www.cete-mediterranee.fr/tt13/www/rubrique.php3?id_rubrique=27

pour représenter cet indicateurs. (Notons que le terme accessibilité4 doit être compris au sensgénéral de l’analyse socio-économique, où le but est d’évaluer et de comparer l’accès à différentslieux et services que permettent les réseaux de transport, et pas au sens de l’accessibilité destransports aux personnes à mobilité réduite)

Cet indicateur présente l’intérêt d’être à la fois compréhensible du grand public, des élus et destechniciens.Le CERTU, service technique du ministère du développement durable basé à Lyon, a pour missionde capitaliser les connaissances dans les domaines des déplacements et de l’aménagementurbains. Le CERTU a lancé en 2013 un travail de recensement des pratiques en matièred’accessibilité transport : quels types d’étude sont menés, quels sont les indicateurs calculés,quels sont les outils pour calculer les indicateurs et les représenter (notamment sous forme decarte). Le CETE Méditerranée contribue à ce travail, et notamment a proposé de présenter le logiciel libreOpenTripPlanner Analyst, identifié depuis quelques temps comme le logiciel libre de référencepour la recherche d’itinéraires multimodaux, et qui est doté d’un module appelé Analyst, destinéjustement à produire des indicateurs d’accessibilité.Ce logiciel a atteint un bon niveau de maturité depuis quelques mois et bénéficie désormais del’accès à des données décrivant les réseaux de transport sous licence open data (c’est à direlibrement réutilisables), tant pour la voirie (Open Street Map) que pour le transport collectif, quijusqu’à récemment étaient indisponibles ou très difficiles à obtenir, et constituaient sans doutel’obstacle principal pour développer l’usage de l’accessibilité dans les études des réseaux detransport. En outre, le développeur principal de ce logiciel est basé en France, ce qui est un atoutimportant pour en comprendre le foncti

B. Objectifs du stage

L'objectif du stage est de tester l'application OpenTripPlanner et son module Analyst avec desdonnées réelles pour un secteur d’étude en PACA.En principe l’installation initiale doit permettre des premiers tests ; en pratique pour aller plus loin,il sera nécessaire de configurer voire adapter le logiciel, et surtout de développer des scriptspermettant de lancer des lots de calculs et de les analyser.

C. Démarche

Pour ces stages, les différentes étapes du travail effectué ont été les suivantes : Prise de connaissance du contexte Installation de l’environnement de travail Test avec des jeux de données Perspectives d’utilisation Mémoire de fin de stage.

D. Contenu du rapport

Outre la présente introduction, ce rapport téléchargeable sur le site web du CETE Med comprend3 parties :

Contexte technique décrivant les logiciels et données utilisés . Mise en place de l'environnement de travail . Conceptions de requêtes pour Batch Analyst

Il se termine par une conclusion proposant des pistes pour continuer, et en annexe, par une listedes principales références utiles.

4http://fr.wikipedia.org/wiki/Accessibilit%C3%A9#Transports ethttp://en.wikipedia.org/wiki/Accessibility#Accessibility_planning_for_transportation

II.ENVIRONNEMENT TECHNIQUE

A. Les logiciels

1. OpenTripPlanner

La disponibilité de données décrivant l’offre de transport, tant la voirie routière que l’offre detransport collectif, est devenue une réalité depuis seulement quelques années, grâce audéveloppement rapide de données mises à disposition gratuitement, tant par la communauté (basede données géographiques collaborative OpenStreetMap – OSM) que par les pouvoirs publics(bases de données d’offre de transport publiées en open data, apparues d’abord aux Etats-Unis).C’est cette disponibilité des données qui a rendu réellement possible, et surtout utile et visible, ledéveloppement de logiciels libres de recherche d’itinéraires multimodaux. Le plus abouti d’entreeux, OpenTripPlanner (OTP), a été développé en fédérant une équipe de développeurs américainsqui travaillaient déjà chacun de leur côté sur le sujet, grâce à l’initiative de la métropole de Portlanddans l’Oregon.

OTP est une application web en java, accessiblé à l’adresse www.opentripplanner.org/C’est un logiciel libre (open source en anglais), ce qui signifie que son code source peut êtrelibrement réutilisé. La forge logicielle sur lequel OTP est publié est github, où l’on accès également à ladocumentation en ligne https://github.com/openplans/OpenTripPlanner/wiki. Il existe par ailleurs unforum Développeurs et un forum Uitlisateurs, tous deux publiés sur Google Groups.OTP est en cours de ré-écriture (refactoring), afin de simplifier et rendre plus modulaire encore etplus performant son code ; néanmoins cette ré-écriture ne sera achevée qu’à l’automne 2013 et ilfaudra donc suivre ces améliorations dans les mois qui suivent. Les développements sont trèsactifs actuellement, avec une communauté de développeurs assez solide d’une dizaine depersonnes, dont le centre de gravité s’est rapproché de l’Europe avec plusieurs projets en coursnotamment aux Pays-Bas et en Pologne.

OTP comprend plusieurs modules, directement visibles dans les répertoires du code source(https://github.com/openplans/OpenTripPlanner). La plupart de ces modules ont un rôle technique.Les modules qui nous concernent en pratique en tant qu’utilisateur de l’application sont lessuivants :

– graph-builder– web-app– analyst-client

Le principe est le suivant :– avant de commencer à pouvoir utiliser le logiciel, il faut réunir les données (de voirie et de

transport) et créer le graphe qui servira aux calculs d’itinéraires ;– il faut ensuite lancer le serveur web applicatif ;– dès lors, on peut utiliser directement depuis un navigateur deux applications interactives

sur le web : une recherche d’itinéraire multimodale, et une analyse d’accessibilitémultimodale (isochrones) ;

– il existe par ailleurs divers utilitaires (notamment pour visualiser un graphe) ;– il est également possible d’utiliser le logiciel depuis d’autres programmes, pour récupérer

les résultats de recherche d’itinéraire ou au moyen d’API (interfaces de service web) ; c’estce que nous présenterons pour l’accessibilité, avec le module batch -analyst.

OTP fait appel à de nombreuses librairies open source. Par ailleurs il s’installe dans unenvironnement technique qui fait appel à de nombreux logiciels open source également (eclipse,maven, tomcat), qui varient sur la configuration technique choisi. Cf. installation plus loin.

2. Chouette et GTFS Feed Validator

CHOUETTE est un logiciel libre développé à l'initiative du ministère du développement durable,dans le but de faciliter l'échange de données d'offre (théorique) de transport collectif, ens'appuyant pour cela sur la norme NFP 99506, dite Neptune, qui spécifie un profil d'échange XML.

Les principales fonctions de ce logiciel sont, dans l'ordre : valider des données au format XML/Neptune visualiser des réseaux TC importer / exporter / convertir des jeux de données gérer et mettre à jour des données d'offre TC.

Le logiciel est utilisable de plusieurs façons en tant qu'application web hébergée gratuitement surwww.chouette-mobi, ou en installant le logiciel sur un autre serveur ou sur une machine virtuellesur son PC.

Dans ce projet, Chouette est utile lorsque les données d’offre TC sont disponibles au format XML/Neptune et qu’il faut les convertir au format GTFS utilisé par OTP.

Le logiciel libre GTFS Feed Validator permet de vérifier la conformité d'un jeu de données auformat GTFS.

B. Les données

Pour faire des calculs d’itinéraires, on s’appuie sur une description des réseaux de transport. Il y aessentiellement 2 sources de données utiles pour cela, même si cela peut être plus complexelorsque l’on veut prendre en compte des services de mobilité plus larges (covoiturage, transport àla demande zonal, stationnement, etc.) :

– le réseau de voirie sert à faire circuler le transport individuel (voiture, marche, vélo)– les réseaux de transport collectif sont modélisés séparément

Le point d’arrêt de TC doit être mis en correspondance avec le réseau de voirie afin de permettredes itinéraires multimodaux ; en 1ère approche, cela est fait automatiquement en projetant le pointd’arrêt sur la rue la plus proche, même si dans le détail il existe différentes méthodes pourconnecter les 2 réseaux et que cela peut être retouché à la main si nécessaire.

1. Les données de transport public

Le réseau de transport public est décrit classiquement d’abord par sa topologie (arrêts, lignes) puisses horaires. Il existe une norme européenne (Transmodel) qui décrit de manière générale unmodèle de données de TC, et une norme française (Neptune) qui spécifie comme échanger dansdes fichiers les données représentant l’offre de transport public. Dans OTP, c’est un autrestandard, GTFS, qui est utilisé pour les données de TC, d’une part parce que le logiciel estd’origine nord-américaine, d’autre part parce qu’il vient du monde open data où GTFS est lestandard de fait, bien plus simple à traiter que Neptune, techniquement. Néanmoins il existe desoutils de conversion entre les 2 formats (Chouette, notamment).En pratique, un jeu de données GTFS se présente dans un répertoire .ZIP qui regroupe lesdifférents fichiers texte ‘à plat’ (format CSV) décrivant les différents types de données nécessaires(réseau/agency, horaires/stop_times, courses/trips, itinéraires/routes, arrêts/stops,calendriers/calendar).

Des données open data notamment nord-américaines sont répertoriées sur le site http://www.gtfs-data-exchange.com/ ; en France, les données open data de TC sont répertoriées sur http://petitpois.passim.comarquage.fr/poi/search?ack=Open+data&k=Open+data&q=&w=&s=active

2. Les données de voirie

Un réseau routier est classiquement décrit par des tronçons (arcs géo-référencés), dont lesextrémités sont les nœuds du réseau et sont reliés aux autres tronçons. Contrairement autransport public où seuls les nœuds sont référencés (on ne peut pas prendre un bus en marche),pour la voirie il faut aussi décrire la géométrie des tronçons. Il existe bien sûr des subtilités dans lamodélisation d’un réseau routier, notamment en ce qui concerne les mouvements tournants etautres interdictions (sens unique, types de véhicules autorisés) et attributs descriptifs de la voirie(vitesse limite, pente...).Dans OTP, l’idée est de s’appuyer sur des données librement réutilisables, tout comme pour le TC.Ces données existent : ce sont celles de la Base de Données mondiale OpenStreetMap (OSM),créée en 2004 sur le principe d’une saisie collaborative sur le web par une communauté trèsactive, et qui a atteint depuis 2 à 3 ans une qualité suffisante pour être utilisable dans desapplications finales, de production de cartes interactives et de recherche d’itinéraires routiers. OTPutilise donc des données conformes au modèle et au format d’échange d’OSM.Le site d’OSM France donne accès à toutes les informations et données utiles :http://www.openstreetmap.fr/

III.MISE EN PLACE DE L’ENVIRONNEMENT DE TRAVAI L

A. Installation de l'environnement de travail

OTP est une application web : une évolution est en cours pour l’utiliser directement en tantqu’exécutable java compilé (OTP-standalone), néanmoins pour ce stage, nous avons utilisél’application complète qui est une application java J2EE. Pour fonctionner, une telle application doitfonctionner sur un serveur applicatif Java (servlet container) dont Tomcat est le logiciel opensource le plus répandu (mais il en existe d’autres, comme winstone par exemple, ou glassfish).Par ailleurs, conformément à la documentation en ligne, nous avons en fait installé le code dansun environnement de développement Eclipse5, ce qui permet de gérer des mises à jour de laconfiguration de manière plus intégrée dans un seul outil. Le versionnement du code est géré parGit. La compilation du code java est gérée par l’outil Maven.

OTPsous

Eclipse

Surtout si on installe le code et les outils associés, l'environnement logiciel est complexe. Pourl’installation, mais aussi l’utilisation d'OTP, le point clé est de gérer de manière rigoureuse lesdonnées, qui sont réparties dans de nombreux répertoires (attachés aux outils le cas échéant :code source, serveur web et aux données : graphes, fichiers sources, configurations, historiquedes traitements réalisés).

B. Création de la base de données et mise en place de l'application

1. Compilation du graphe

Comme évoqué plus haut, il faut commencer par créer le graphe multimodal avant d’utiliser lelogiciel. La création du graphe utilise le module GraphBuilder et est documentée ici :https://github.com/openplans/OpenTripPlanner/wiki/GraphBuilder5https://github.com/openplans/OpenTripPlanner/wiki/GettingStartedEclipse

Le principe est le suivant : toute l’information concernant le graphe est décrite dans un fichiergraph-context.xmlEn première approche (on peut ensuite gérer plus en détail le mode vélo, le mode marche, lesconnexions entre réseaux TC et routier), il faut indiquer dans ce fichier :- la source des données de TC : un ou plusieurs jeux de données GTFS (dossiers .ZIP) ;- la source des données de voirie : le plus simple est d’indiquer à OTP d’aller chercher sur leserveur OSM en ligne les données de voirie correspondant à la zone rectangulaire couverte parl’offre de TC, sous forme de fichiers XML au format .osm ; néanmoins il est aussi possible de lesfournir directement à OTP dans un répertoire local (il suffit de les télécharger ou de les produire enamont).

En général les données proviennent de sources open data mais ce n’est bien sûr pas obligatoire, ilsuffit que les données soient conformes aux formats (GTFS, OSM).

La compilation du graphe prend quelques minutes (lancement de graph-builder) et crée un fichiergraph.obj , dont on indique les références au serveur lorsqu’il effectue les calculs.Il existe un outil dans OTP pour visualiser le graphe à l'écran (graphviz).

2. Serveur web applicatif

Le serveur web peut être lancé sous Tomcat directement depuis Eclipse (tout comme graph-builder).Il peut également être lancé en ligne de commandes sous linux ; dans ce cas ce n’est pas leserveur Tomcat intégré comme module d’Eclipse qui sera lancé, en général, mais un autre serveurd’applications installé au préalable sous linux (winstone, glassfish, ou tomcat d’ailleurs). CommeOTP est un programme java pour l’essentiel, il fonctionnerait peut être sous windows mais nousn’avons pas testé.

3. Utilisation de l’application de recherche d’itinéraire :

Pour utiliser l’application depuis un navigateur en local, saisir l'url :http://localhost/opentripplanner-webapp/L'application de recherche d'itinéraire est composée d'un menu et d'une carte centrée sur lesdonnées du graphe. Les paramètres pour la recherche d'itinéraire que l'on peut choisir dans lemenu sont les suivants: le mode de transport (TC + marche, bus seulement + marche, train/métroseulement + marche, marche seule, vélo seul, vélo +TC...), le nombre de kilomètres de marchemaximum, la vitesse de marche, la date et l'heure de départ ou d'arrivée, ainsi que le critèred'optimisation (le plus rapide ou le moins de correspondances).Pour modifier la langue, aller sans le fichier config.js est mettez French.locale au lieu deEnglish.locale.Voici le chemin pour trouver le fichier config,jsopentripplanner-webapp/src/main/webapp/js/otp/

Paramètres d'une recherche d'itinéraire

recherche d'itinéraire web avec OTP (Rennes)

Feuille de route résultant d'une recherche d'itinéraire (Marseille)

4. Utilisation de l’application de recherche d’isochrones :

Pour utiliser l’application depuis un navigateur en local, saisir l'url :http://localhost/opentripplanner-analyst-client/

Analyst s'appuie sur le calcul de l'arbre des plus courts chemins (shortest path tree : SPT) à partird'un point pour produire ensuite différentes représentations graphiques. Depuis l’IHM web, nous avons accès à 4 modes de calcul.Les paramètres de calcul des plus courts chemins sont les mêmes que ceux de la recherched'itinéraires (combinaison de modes, date/heure arrivée/départ, km max à pied/vélo).

Single origin / destination : A partir d'un point Origine, des zones isochrones à partir du point sont affichées.

Potential path area : A partir de deux points, le résultat affiché est l'intersection des 2 arbres des plus courts chemins :les zones les plus claires montreront sont celles les plus proches de ces deux points. Les zones ennoir sont celles inaccessibles depuis l'un ou l'autre des 2 points dans le temps maximum défini enparamètre.

Two origin difference :

A partir de 2 points choisis par l'utilisateur, Analyst calcule la différence du temps de trajet entrechaque point de la carte et les deux points chosis ; 3 types de zones sont affichées, celles plusproches de l'origine, celles plus proches de la destination et les zones neutres.

Single-origin difference : Ce mode a le même principe, mais la différence est calculée depuis un seul point Origine pour 2paramètres de recherche d'itinéraire différents (typiquement, pour comparer 2 modes detransport).

En pratique nous avons utilisé OTP avec des données OpenData récemment publiées par leSyndicat Mixte des Transports des Bouches-du-Rhône qui gère le service d’informationmultimodale www.lepilote.com.

Menu OTP Analyst pour Single origin / destination

Résultat d'un calcul d'isochrones TC à Marseille avec OTP Analyst

IV.ANALYST EN MODE BATCH

A. Principe

Batch processing est un vieux terme informatique qui signifie traitement par lots, par opposition autraitement interactif ; le but est donc de lancer des calculs d’indicateurs définis spécifiquement parl’utilisateur, pour produire des jeux de données qui seront visualisables et exploitables dans un2ème temps, en temps différé : c’est précisément ce que nous recherchons dans le cadre del’étude du CERTU.Le principe est un peu similaire à celui de graph-builder :toute la configuration des paramètres de calcul passés à analyst est envoyée au programme javabatch-analyst via un fichier : batch-context.xml situé dans le répertoire OpenTripPlanner /opentripplanner-analyst / src / main / resources /

B. Détails de l’API

L’ensemble des paramètres est donc décrit dans le fichier batch-context.xmlLe principe des calculs est le suivant :

– on définit une liste de points comme « population d’Origines », et une série de pointscomme « population de Destinations » ; la liste peut être soit une liste de points individuelsdécrits en XML, soit un fichier CSV, soit un fichier SHP, soit une grille de points (un fichierd’image bitmap au format geo-TIFF) ;

– batch analyst lance une recherche d’itinéraires sur chaque point de la population d’origine :plus précisément, il calcule un arbre des plus courts chemins (shortest path tree) pourchaque point Origine. Ensuite, il calcule un indicateur pour chaque point de destinationrelatif à cet arbre de plus courts chemins partant de l’origine. Enfin, il est possible d’agrégerles résultats, c’est à dire de produire un seul indicateur pour une origine donnée à partirdes résultats obtenus pour toutes les destinations, ou d’accumuler les résultats, c’est à direà l’inverse de sommer les résultats obtenus pour toutes les origines sur une mêmedestination

Il y a donc trois cas de figure pour les résultats correspondant à la boucle de calcul :* cas simple : pour chaque O : calcul de l’arbre des plus courts chemins spt(O)

* pour chaque D, calcul d’un indicateur de D sur spt(O)→ O résultats (fichier) de dimension D et au format fourni pour les Destinations : tableau

CSV, bitmap TIFF, couche SHP...* agrégation : pour chaque O, calcul du spt(O)

* pour chaque D, calcul d’un indicateur pour spt(O) puis agrégation des résultats sur les Den une seule valeur agrégée (il est possible de définir un paramètre d’entrée input pour le calculd’agrégation des indicateurs)

→ 1 résultat (fichier) de dimension O* accumulation: pour chaque O, calcul du spt(O)

* pour chaque D, calcul d’un indicateur sur spt(O) et accumulation des résultats pourchaque D en une seule valeur s’accumulant avec les résultats calculés pour chaque O

→ 1 résultat (fichier) de dimension D

L’agrégation et l’accumulation permettent a priori de calculer le même type d’indicateurs: le choixde l’un ou l’autre mode de calcul se fait en fonction du temps de calcul. Le mode le plus rapide estcelui qui minimise le nombre de calculs d’arbres des plus courts chemins (Single Source ShortestPath – SSSP Problem).

Par défaut, l’indicateur calculé pour chaque D dans la boucle ci-dessus est le temps de parcoursentre O et D en secondes (toutefois nous n’avons pas trouvé comment calculer un autreindicateur! La documentation est incomplète sur ce point, mais en lisant le code il doit être possiblede comprendre comment faire).

Ce principe est général (donc potentiellement puissant!) mais abstrait, voici quelques exemplesd’utilisation possible, du moins en principe :

1) 1 point O, bitmap de points D -> le résultat est un fichier image (.TIFF) avec un codecouleur correspondant à la distance de O à D, ce résultat est donc une carte isochroneautour de O.

2) n points O, bitmap de points D -> cela produit n cartes isochrones autour de chaque pointO

3) 1 point O, fichier Shapefile D représentant la population, avec accumulation des résultats-> on peut calculer le nombre d’habitants à moins de x minutes du point O

4) bitmap de points O, fichier Shapefile D représentant la population, avec accumulation desrésultats -> permet de produire une carte couleur représentant la population à moins de xminutes de chaque endroit sur la carte

Les calculs se font pour un graphe donné, c’est-à-dire pour une combinaison modale donnée (TCseul, marche seule, vélo seul, vélo+TC etc.) et pour une offre donnée (voirie + TC).Comme OTP est conçu pour gérer plusieurs graphes, il serait possible de comparer des résultatscalculés (tableaux, ou cartes) pour différents modes (ex. vélo vs. TC) ou pour différents offres (ex.

selon congestion routière, ou avec / sans une ligne de métro), mais cela implique de programmerces calculs, au-delà de la seule utilisation du fichier de configuration

C. Mise en œuvre : tests avec des données réelles

Pour exécuter les calculs, on peut soit lancer Analyst en ligne de commande java (c’est unprogramme java), mais à condition d’inclure dans la commande toutes les dépendances maven dece programme, soit - de manière plus pratique si on a installé OTP dans l’IDE Eclipse - via le menu‘Run As’.Les données réelles que nous avons utilisées comme exemple sont essentiellement celle de laRTM de la ville de Marseille. Elles comprennent les horaires de bus, tram et métro.Nous avons testé les différentes configurations des origines et des destinations.

Configuration Basic Nous créons les points manuellement dans le fichier batch-context.xml.Le résultat est un fichier .csv (avec colonnes : nom, coordonnées x, y, temps de trajet en

secondes)

Configuration CSV Les points destinations ou origines sont définis dans un fichier .csv : le nombre de fichiers générés par batch-analyst sera égal au nombre de points Origines.

Configuration ShapefileDe la même manière qu’avec configuration ci-dessus, nous pouvons également charger les points origines ou destinations à partir d'un fichier shapefile.

Configuration ZoneDans le fichier batch-context, une zone est définie par des latitudes et longitudes. Tous les points inclus dans cette zone sont des points origines et chacun de ses points va trouver le plus court chemin avec le ou les point(s) Destination(s) . Comme ci-

dessus, le nombre de fichiers générés sera égal au nombre de points Origines que nousavons définis.

V.CONCLUSIONS ET SUITES À DONNER

A. en résumé

OpenTripPlanner est une application extrêmement intéressante, qui a atteint un bon niveau dematurité, d’autant plus qu’une réécriture est en cours qui devrait grandement simplifier sa mise enœuvre et peut être améliorer ses performances. OTP bénéficie de la disponibilité croissante dedonnées à des formats standard, de qualité, et librement réutilisables.OTP reste une application complexe :

– techniquement, car s’appuyant sur le framework java spring et nécessitant d’être installéeavec son code dans un IDE avec Maven pour être testée convenablement

– sur le plan fonctionnel, car la recherche d’itinéraires multimodale fait intervenir un grandnombre de paramètres si on veut pouvoir décrire convenablement tous les modes et leschangements de mode, et également car le module Analyst permet une grande souplessedans la définition des calculs à effectuer, et est donc assez abstrait et général.

La documentation d’OTP reste très incomplète sur les détails d’Analyst notamment, et une bonnepartie du stage a consisté à explorer les fonctionnalités pour essayer de comprendre à quoi servaittel ou tel paramètre. Nous avons réussi à faire fonctionner l’application avec des données réelles( Marseille, Rennes ...), mais n’avons eu le temps d’explorer sérieusement la richesse despossibilités offertes par Analyst pour le calcul d’indicateurs d’accessibilité.

B. Perspectives

Pour la suite du projet, le CETE Méditerranée envisage, si le CERTU est intéressé :– d’installer un serveur visible sur l’internet avec des données réelles (celles de Marseile par

exemple, publiées sur http://www.lepilote.com/presentation/?rub_code=92)– de développer des calculs d’indicateurs d’accessibilité dans le même esprit que walkscore /

transitscore, mais avec un score d’accessibilité pondéré par l’accès à des lieux publics(écoles, hôpitaux) plutôt que privés (restaurants, spectacles...), en utilisant le mécanismed’agrégation / accumulation d’OTP Analyst.

VI.ANNEXE : RÉFÉRENCES

Les résultats de cette étude sont disponibles sur le site web: http://www.cete-mediterranee.fr/tt13/www/

Contexte et outils

http://fr.wikipedia.org/wiki/Accessibilit%C3%A9#Transports

www.chouette.mobisite GTFS feed validator : http://code.google.com/p/googletransitdatafeed/wiki/FeedValidator http://www.normes-donnees-tc.org/

www.opentripplanner.orgwikipage analystforums

Données :Annuaire passim :http://petitpois.passim.comarquage.fr/poi/search?ack=Open+data&k=Open+data&q=&w=&s=activesite Rennes open data: http://data.keolis-rennes.com/fr/les-donnees/donnees-telechargeables.htmlsite Lepilote : http://www.lepilote.com/presentation/?rub_code=92

Glossaire, termes utilisés:

Isochrone est une courbe délimitant les points accessibles en un temps donné

General Transit Feed Specification (GTFS) est un format informatique standardisé pourcommuniquer des horaires de transports en commun et les informations géographiques associées

TC désigne les transports collectifs

Comma-separated values, connu sous le sigle CSV, est un format informatique ouvertreprésentant des données tabulaires sous forme de valeurs séparées par des virgules.

Source glossaire : Wikipédia