Utiliser OTP Analyst

utiliser Open Trip Planner Analyst
logiciel libre de calcul d'accessibilité transport
date : avril 2015
auteur : Direction Territoriale Méditerranée, Patrick Gendre
résumé : ce document présente le logiciel libre OpenTripPlanner et son utilisation pour des calculs d'accessibilité
transport. Il est mis à jour au fil de l'eau.
.
1. contexte
OTP Analyst (OTPA) est un logiciel libre qui permet de produire en mode web des calculs d'accessibilité
transport. Analyst est un module du logiciel de recherche d’itinéraires multimodaux OpenTripPlanner (OTP 1),
déployé dans plusieurs villes2 dont Grenoble en France. OTP Analyst est mis en oeuvre dans de grandes
métropoles telles que New York ou Mexico, ou en Finlande3 .
Principes du calcul d'accessibilité transport
Les études d’accessibilité transport font partie des outils de plus en plus utilisés pour diagnostic et évaluer
l’offre de transport sur un territoire, et font l’objet de nombreux travaux. Un récent rapport du CEREMA fait le
point sur les pratiques en France en termes des méthodes, données et logiciels pour les études d’accessibilité
multimodale des territoires. Nous renvoyons le lecteur intéressé vers ce document, et nous nous limiterons ici à
décrire les principes de fonctionnement d’OTPA pour le calcul d’indicateurs d’accessibilité.
Open Trip Planner est d’abord un logiciel de recherche d’itinéraires multimodaux, qui a atteint un niveau de
maturité suffisant depuis 2 ou 3 ans pour être utilisé en production par plusieurs réseaux comme outil internet
de services d’information transport. Le moteur de calcul d’itinéraires peut aussi être utilisé, en dehors des
applications de préparation d’un déplacement, pour répondre à des questions d’analyse spatiale et d’urbanisme,
en particulier des études sur l’accessibilité des transports.
Les algorithmes de calcul du plus court chemin produisent une grande quantité d’informations intermédiaires,
inutiles pour la recherche d’un point A à un point B, mais qui sont utiles et peuvent être conservés pour des
besoins d’analyse spatiale, quitte à faire tourner le calcul à peine plus longtemps pour explorer un peu loin les
noeuds du graphe de transport. C’est précisément ce que fait OTP Analyst (et la plupart des outils d’analyse de
réseaux de transport) : lors d’une recherche d’itinéraires, tous les chemins au départ d’un point origine sont en
fait explorés, et le calcul produit non seulement les plus courts chemins (PCC), mais en fait aussi un arbre des
plus courts chemins (APC) partant du point origine.
L’arbre des plus courts chemins depuis un point A contient donc beaucoup
d’information sur l’accessibilité au départ de ce point : par exemple, le temps
de parcours de A vers n’importe quel point (ou du moins vers la projection de
ce point vers le segment routier le plus proche), et de même pour toute autre
quantité produite lors du calcul d’itinéraire (nombre de changements, prix du
déplacement, distance de marche à pied, etc.). A partir de là, le temps de
parcours depuis A est une fonction définie depuis tout point du plan autour de
A, fonction que l’on peut stocker en cache mémoire afin de pouvoir la
recalculer très rapidement (en pratique, de manière interactive pour
l’utilisateur) après modification de divers paramètres.
Un calcul d’itinéraire est une fonction qui dépend de l’offre de transport
(réseau routier, avec les détails concernant le cas échéant la marche ou le vélo,
le stationnement, la congestion routière, et transports collectifs), des modes et combinaisons de modes, et de
diverses options (horaires de départ, préférences de modes, etc.), et qui fournit un ou quelques trajets optimaux
d’un point Origine à un point Destination : PCC (offre, modes, options) (O, D) -> trajets de O à D : durée,
feuille de route, nombre de changements, etc.
De même, l’arbre des plus courts chemins est une fonction du point origine qui dépend de l’offre, des modes et
des options de transport choisies et fournit - en chaque noeud du réseau multimodal - les résultats du chemin
optimal : temps de trajet, nombre de changements, etc. On peut dériver facilement de cet arbre, par
1
2
3
http://www.opentripplanner.org/
http://opentripplanner.readthedocs.org/en/latest/Deployments/
http://matka-aika.com/
interpolation, une fonction fournissant - pour tout point (x,y) - les valeurs des résultats du PCC (temps de trajet,
etc.) depuis l’origine O.
Accessibilité (offre, modes, options) (O) (x,y) -> résultats PCC depuis O (durée, feuille de route, nb de
changements, etc.) interpolés de l’arbre des PCC à partir du point x,y
A partir de là, on peut en déduire aussi des courbes ou des surfaces iso-valeurs, notamment les isochrones
partant du point Origine : par exemple la surface contenant les points que l’on peut rejoindre depuis O en moins
de 30 minutes, pour l’offre de transport et la combinaison de modes choisies. Plus généralement, on peut aussi
calculer des scores d’accessibilité, en croisant l’arbre du plus court chemin avec des données localisées sur le
territoire étudié : emplois, services, etc. , par exemple :
• nombre d’hôpitaux à moins de 30 minutes en TC+marche, depuis un point O ;
• nombre d’emplois à moins de 30 minutes tous modes confondus, à l’heure de pointe du matin, depuis un
point O ;
• nombre d’habitants à moins de 400 mètres d’une station de métro ;
• etcetera.
On peut ensuite combiner des scores, pour autant que les données localisées sous-jacentes soient du même
niveau de détail (ou ramenées à un même niveau d’agrégation). SCORE (offre, modes, options) (O) (x,y) :
croisement de résultats de calcul d’itinéraire avec des données localisées en tout point x,y du territoire, ou
somme pondérée de scores
La manière la plus naturelle de représenter l’accessibilité est sans doute sous forme de carte (ou de couche,
semi-transparente) où le temps de parcours (ou tout autre indicateur ou score) est un code couleur calculé sur
une grille régulière de points (les pixels de la carte). Néanmoins, il existe bien d’autres représentations
possibles, ne serait-ce que directement l’arbre des plus courts chemins lui même, ou par des tableaux et
graphiques associés (par exemple pour comparer des scores agrégés sur quelques zones du territoire étudié, ou
pour comparer différents résultats obtenus selon le mode de transport ou leur combinaisons, ou selon des
variantes de l’offre de transport, dans le cadre de scénarios pour un projet de TCSP par exemple). On voit que
l’accessibilité dépend d’une grande combinaison de facteurs, d’un grand « espace de paramètres » possibles:
•
•
•
•
•
localisation sur le territoire
jour ou heure
variantes d’offre de transport
modes et combinaisons de modes
variables socio-économiques localisées (emplois, population, services, etc.).
Par conséquent, une caractéristique essentielle d’un outil d’étude de l’accessibilité est son degré d’interactivité :
la facilité avec laquelle un utilisateur final peut explorer les différents résultats calculés. Les développements
récents d’OTP Analyst se sont faits essentiellement dans cette direction, c’est ce que nous allons voir dans le
point suivant sur l’architecture du logiciel.
2. Architecture du logiciel
Vue d'ensemble
Open Trip Planner (OTP) est un logiciel libre qui permet de produire en mode web des calculs d'itinéraires et
d'en dériver des indicateurs d'accessibilité transport (c'est le module Analyst, OTP-A), selon les principes
généraux décrits ci-dessus.
Le code source OpenTripPlanner comprend essentiellement
- une bibliothèque Java de recherche d’itinéraires multi-modaux, qui permet également les calculs
d'accessibilité (isochrones) et inclut un serveur web
- le client (qui permet d'utiliser OTP depuis un navigateur)
Les communications entre le client et le serveur se font par une interface web (API REST) ; plusieurs clients
peuvent interroger un même serveur. Le client « de base » d'OTP permet d'utiliser les fonctions de recherche
d'itinéraires et de calcul d'isochrones (Analyst), et est traduit en plusieurs langues dont le français.
Les données utilisées pour construire le graphe sur lequel OTP calcule des itinéraires sont des fichiers aux
formats GTFS (pour la partie TC) et OpenStreetMap (pour la partie voirie). Un même serveur OTP peut gérer
plusieurs graphes (paramètre Router).
Données de voirie (OSM)
et de TC (GTFS)
Serveur
graphe 1 (router1)
OTP
(java)
graph2 etc.
Client
API REST
(navigateur)
...
Même si ces derniers mois (1er trimestre 2015), la documentation a été nettement améliorée, en même temps
que l'architecture du logiciel était consolidée, et si la plupart des questions posées sur le forum (Google Group
OTP) trouvent une réponse rapidement, on peut dire qu’OTPA n'existe pas (encore) en tant que produit «
packagé », il s’agit plus d’un ensemble d’outils fournis autour d’OTP et ses différentes versions, qu’il faut
assembler, maintenir et documenter dans le cadre de chaque projet. Un des points forts aussi est que deux
développeurs majeurs d'OTP sont en France.
API REST
Les principaux services web (API REST4) fournis par OTP sont les suivants:
• l’API de recherche d'itinéraire (Planner) : service web REST de recherche d’itinéraire aux formats JSON
ou XML. Cette API peut être utilisée en combinaison avec un front-end javascript pour créer des
applications interactive de recherche d’itinéraire en mode web. Il existe également une variante de
calcul d'itinéraire, dit « en profil », qui permet de calculer : ProfileResource5
• l’API “transit index” (IndexAPI) permet d’interroger en REST les données GTFS hébergées sur le
serveur OTP (selon le modèle de données OTP:
http://dev.opentripplanner.org/apidoc/master/model.html), par exemple les itinéraires desservant un arrêt
particulier, les véhicules arrivant à un arrêt, les prochains arrêts sur un itinéraire, etc.
http://dev.opentripplanner.org/apidoc/master/resource_IndexAPI.html
• le service web OTP Analyst fournit des images (raster : TileService) de surfaces isochrones des temps de
trajet à partir d’un point, ou des couches au format vecteur .SHP ou GEOJSON: SIsochron,
SimpleIsochron, LIsochron, TimeGridWs. Comme Analyst fait partie d’OTP, tous les paramètres de
recherche d’itinéraires peuvent s’y appliquer : heure de départ, mode et combinaison de modes, durée
maximum de marche.
4
5
http://dev.opentripplanner.org/apidoc/master/
http://conveyal.com/blog/2015/02/24/what-is-profile-routing/
Client (javascript)
Le client OTP utilise des librairies javascript qui permettent de construire des applications web adaptées sur
mesure à chaque projet. Une série de fonctions javascript a ainsi été développée pour OTP Analyst, qui
permettent d’appeler les API REST d'OTP. L’idée principale est de stocker en mémoire côté serveur les résultats
de calculs (arbres de plus courts chemins), puis de les appeler depuis le navigateur avec différents paramètres,
mais sans refaire les calculs, avec un bon temps de réponse qui permet une interactivité pour l’utilisateur final.
Les développements effectués en 20146 ont permis d'ajouter au client des fonctions de calculs d'indicateurs
(scores comptant le nombre de points d'intérêt à moins de x minutes du point origine) et une représentation en
histogrammes, ainsi que l'export des courbes isochrones dans un format vecteur réutilisable dans un SIG, en
plus des images des surfaces isochrones (format raster).
Il est toujours possible par ailleurs d’exporter les résultats calculés par OTPA sous forme de tableaux vers des
fichiers externes tabulés, permettant leur traitement dans un tableur, ou par exemple dans R, le logiciel libre
d’analyse statistique.
OTP Analyst
OTP Analyst est un outil associé au programme de calcul d’itinéraires. La fonction principale de OTP Analyst
est de tirer parti de l'arbre des plus courts chemins calculé à partir d'un point origine, pour interpoler les valeurs
de durée d'itinéraire à partir de cette origine, sur une grille de points (grid) et de les produire sous forme de
tuiles cartographiques (images à afficher sur le navigateur du client) ou de données (contours isochrones).
OTP-A est utilisable de 3 manières:
- sur le serveur, pour des utilisateurs maîtrisant la ligne de commandes Linux et connaissant java7 ; l’outil batchanalyst permet de lancer des calculs par lots (batches, en anglais) sur des jeux de points d’intérêt (listes
d’hôpitaux, grille de points, etc.), afin de calculer des scores et autres indicateurs, et produire les cartes
correspondantes
- également sur le serveur, mais de manière plus simple, en écrivant des scripts en python qui utilisent les
fonctions de l'API org.opentripplanner.scripting.api (cf. http://dev.opentripplanner.org/javadoc/)
- depuis un navigateur, via le client.
Evolutions et branches de développement
Une des difficultés (qui est sans doute le revers de la médaille de l’open source) est que les développements
logiciels sont très actifs voire foisonnants : il y a beaucoup de versions d'OTP et également divers outils à côté
d’OTP proprement dits8, dont certains peu ou pas documentés, et il n’est pas évident de s'y retrouver pour
savoir ce qui est vraiment utilisable pour Analyst, « à l’instant t ». Pour répondre à un besoin particulier, il peut
être très utile de savoir que certaines fonctionnalités de la partie client, ou de la partie analyst, ou de la partie
recherche d'itinéraires, ou de la partie sont disponibles dans une certaine branche de développement qui n'est
pas la branche 'master'.
Le plus souvent, les améliorations, corrections ou extensions sont réalisées au départ pour les besoins d'un
projet en particulier, puis lorsqu'ils s'avèrent intéressants pour la communauté OTP et validés techniquement, ils
sont intégrés à la version principale du logiciel. Le code source d’OTP est publié sur
https://github.com/opentripplanner , dans la branche dite « master » (la version actuelle est la 0.15, la 1.0 est
6
notamment pour la DREAL PACA, cf. http://mim.cete-aix.fr/spip.php?article360
7 Cf. le package org.opentripplanner.analyst sur http://dev.opentripplanner.org/javadoc/
8
notamment ceux de conveyal, la société issue d'OpenPlans qui a repris la maintenance d'OTP : https://github.com/conveyal
attendue pour bientôt...).
De nombreuses branches ont été créées, (sur le dépôt GitHub d'opentripplanner, mais aussi sur d'autres dépôts),
qui correspondent donc à un 'clonage' du code et à son adaptation dans le cadre d'un projet. Par exemple, les
développements effectués pour la DREAL PACA sont publiés sur https://github.com/otp-drealpaca/OpenTripPlanner , et OTP en bénéficie (notamment en ce qui concerne le scripting, cf. plus bas).
Fonctionnalités récentes et à venir
Les dernières versions du logiciel comprennent désormais la recherche d'itinéraires TC en temps réel (qui a été
développée dans le cadre d'un projet néerlandais : http://www.predim.org/spip.php?article4720) et la recherche
d'itinéraires « profilés » (cf. http://conveyal.com/blog/2015/02/24/what-is-profile-routing/ , développé dans le
cadre d'un projet à Arlington près de Washington DC http://mobilitylab.org/2014/11/07/the-who-what-whenwhere-whys-of-carfreeatoz/).
D'autres fonctionnalités sont attendues, qui ont déjà été mises en oeuvre dans un projet (cf. notamment les
réalisations de conveyal sur github) mais pas encore incluses dans le tronc commun d'OTP:
- outil de gestion à distance des données et graphes de transport;
- recherche d'itinéraires longue distance;
- nouvelle application web « analyst server » enrichissant les fonctionnalités actuelles du client OTP analyst,
développées dans le cadre d'un projet pour la banque mondiale à Buenos Aires et Mexico et qui seront sans
doute en partie intégrées dans OTP : http://conveyal.com/blog/2015/01/09/transport-analyst/ .
2. Données d'entrée
Modélisation de la voirie avec OSM
OpenStreetMap est utilisé par OTP pour décrire la voirie, y compris le stationnement et les modes actifs, en
s'appuyant sur les balises utilisées dans les fichiers .osm (ou .pbf).
http://wiki.openstreetmap.org/wiki/Map_Features#Highway
Malheureusement le « mapping » entre ces attributs et les valeurs utilisées pour la recherche d'itinéraires dans
OTP reste peu ou pas documenté, par exemple, les vitesses utilisées pour le calcul d'itinéraire en voiture
s'appuient sur l'attribut MaxSpeed ou sur une valeur par défaut en fonction du type de route (tag « highway »)
des tronçons (ways) d'OSM.
Pour savoir dans le détail quelles sont les balises d'OSM utilisées par OTP pour la recherche d'itinéraire, il faut
donc aller voir dans le code, à plusieurs endroits (une réorganisation du code est prévue...), en commençant par
les packages org.openstreetmap.openstreetmap (OSMWithTags) et .osm (OpenStreetMapModule), ou poser une
question ciblée sur le Google Group OTP. Il faut savoir que OTP n'utilise pas que les Ways d'OSM, mais aussi
les Relations (qui décrivent les mouvements tournants, les passages dénivelés, les relations entre arrêts et
stations, des surfaces complexes comme des parkings...).
En pratique si on travaille sur des analyses de calculs d'itinéraires pour la VP, il sera sans doute nécessaire de
regarder de très près les attributs d'OSM qui sont utilisés par OTP pour les itinéraires routiers, et d'éditer les
données (description du stationnement, des modes actifs, des vitesses VP...). Pour cela, on peut s'appuyer sur les
logiciels libres d'édition de données OSM9 : comme il s'agit d'éditer les données pour des besoins et PAS de
modifier la base collaborative OSM, il faut a priori utiliser un éditeur off-line comme josm.
Modélisation des TC avec GTFS
GTFS est un format texte, venu des Etats-Unis, devenu le standard mondial pour la publication de données de
TC en open data.
La plupart des données disponibles TC en open data 10 sont au format GTFS, néanmoins certaines sont publiées
au format Neptune (qui est la norme française d'échange de données d'offre planifiée de transport public). Pour
les convertir au format GTFS, le plus simple est sans doute d'utiliser le logiciel libre Chouette, accessible en
libre service depuis le site www.chouette.mobi (ce qui évite d'installer le logiciel). Ce logiciel peut également
être utile pour importer et éditer des données GTFS, ou saisir par exemple une nouvelle ligne de TC dont on
voudrait évaluer l'apport en termes d'accessibilité. Il existe par ailleurs des logiciels libres qui permettent de
valider ou éditer des données purement GTFS (cf. https://github.com/WorldBank-Transport/GTFS-TrainingMaterials/wiki/Link-repository-for-international-GTFS-training-materials )
Pour en savoir plus (en français)... http://www.normes-donnees-tc.org/format-dechange/donneestheoriques/gtfs-correspondance-avec-neptune-et-autres-normes/
Les spécifications GTFS sont ici : https://developers.google.com/transit/gtfs/reference
Le document de la RATP présente assez clairement les différents éléments de données GTFS :
http://data.ratp.fr/?eID=ics_od_datastoredownload&file=88 .
Configuration
Dans les versions les plus récentes, le mode de configuration a changé et se fait à travers 3 fichiers texte au
format JSON (précédemment la configuration se faisait dans d'autres fichiers XML) :
Voir http://opentripplanner.readthedocs.org/en/latest/Configuration/:
- un fichier contenant les paramètres généraux utilisés par le serveur otp : otp-config.json (qui pour l'instant
n'est utilisé pour gérer quelques points techniques);
- un fichier contenant les paramètres relatifs à la construction d'un graphe à partir des données GTFS et OSM
(utilisés lors d'une commande –build) : build-config.json -> description des correspondances, utilisation de
fichiers pour définir l'altitude;
- un fichier contenant les paramètres relatifs à un réseau particulier router-config.json -> limitation du temps de
calcul (timeouts), modalités de prise en compte du temps réel (pour le TC et les VLS)
Paramètres du calcul d'itinéraires et d'isochrones
Les paramètres pour les calculs d'itinéraires et pour les calculs d'isochrones sont en gros les mêmes ; ce sont
ceux de l'API REST (ou de l'API java) : http://dev.opentripplanner.org/apidoc/master/resource_SIsochrone.html
A noter que le paramètre routerId (choix du graphe) est dans le chemin de l'url, pas dans les paramètres de la
requête.
9 http://wiki.openstreetmap.org/wiki/FR:Editing#Top_3_des_.C3.A9diteurs
ou le module QuickOSM du SIG QuantumGIS http://www.3liz.com/blog/rldhont/index.php?post/2014/09/26/QGIS-QuickOSMPlugin-%3A-Obtenir-simplement-des-donn%C3%A9es-OpenStreetMap-dans-QGIS
10 en France , cf. http://petitpois.passim.info/poi/search?ack=&k=&q=open+data&w=&s=active
paramètre
walkTime
output
fromPlace
toPlace
intermediatePlaces
intermediatePlacesOrdered
date
time
arriveBy
wheelchair
maxWalkDistance
maxPreTransitTime
walkReluctance
waitReluctance
waitAtBeginningFactor
walkSpeed
bikeSpeed
bikeSwitchTime
bikeSwitchCost
triangleSafetyFactor
triangleSlopeFactor
triangleTimeFactor
optimize
mode
minTransferTime
numItineraries
preferredRoutes
otherThanPreferredRoutesPenalty
preferredAgencies
unpreferredRoutes
unpreferredAgencies
showIntermediateStops
description
Temps de marche maxi (minutes)
selon le type de GeoJSON à retourner: "SHED" renvoie une
enveloppe concave ConcaveHull ou convexe ConvexHull des
tronçons de route. "POINTS" renvoie tous les noeuds du graphe
qui sont dans dans la limite de temps, "EDGES" pour les arcs qui
sont dans la limite de temps définie lors de l'appel.
origine (soit lat,lon en degrés ou un nom de noeud)
destination (comme fromPlace)
liste non ordonnée de vias (même format que fromPlace).
true s'il faut respecter l'ordre des lieux intermédiaires (via).
date de départ (or d'arrivée, si arriveBy vaut true).
Heure de départ (ou d'arrivée, pour les requêtes où arriveBy est
true).
Si true, l'heure (time) est l'heure d'arrivée, sinon c'est l'heure de
départ.
true si le trajet doit être accessible en fauteuil roulant.
Distance max de marche en mètres
Durée maxi en secondes du trajet avant de prendre le TC, dans le
cas d'un trajet VP+TC (P+R ou kiss+ride).
quantifie l'aversion de l'usager à marcher, par rapport à être à bord.
Par défaut, 2, mais peut être mis raisonnablement entre 10 et 20.
quantifie l'aversion de l'usager à attendre à l'arrêt, par rapport à être
à bord. Par défaut, les temps d'attente et à bord ont le même poids.
Peut être mis > 1 mais toutefois devrait quand même être inférieur
à WalkReluctance, sinon l'itinéraire calculé proposera de marcher
plutôt que de prendre le TC.
remplace waitReluctance
Vitesse en marche en mètres/seconde, par défaut 5 kmh
Vitesse à vélo en mètres/seconde, par défaut 17 km/h, 15 en VLS.
Temps pour garer le vélo. par défaut, nul
Coût pour garer le vélo. par défaut, nul
Importance du facteur sécurité (de 0 à 1) dans le triangle de critère
pour les itinéraires vélo pente / durée / pente
Importance du facteur pente (de 0 à 1)
Importance du facteur durée (de 0 à 1)
Type d'optimsation des itinéraires vélo
Liste de modes (WALK, BICYCLE, CAR, TRAM, SUBWAY,
RAIL, BUS, FERRY, CABLE_CAR, GONDOLA, FUNICULAR,
TRANSIT, TRAINISH, BUSISH, LEG_SWITCH) cf. le modèle
de données
http://dev.opentripplanner.org/apidoc/master/model.html
Temps minimum en secondes de changement de véhicule (rien
n'empêche bien sûr qu'une correspondance prenne un temps
supérieur à ce temps minimum).
Nombre max d'itinéraires calculés.
Liste des lignes préférées. Format : agency_[routename][_routeid].
Nombre d'itinaires maxi à renvoyer
Liste des réseaux favoris, séparée par des virgules.
Liste des lignes à éviter, même format que preferredRoutes
Liste des réseaux à éviter (format csv)
si à true, les arrêts intermédiaires (où on passe sans monter ni
par défaut
15
POINTS
false
false
false
Illimité
-1 (illimité)
2
1
QUICK
TRANSIT,W
ALK
-1
-1
-1
false
walkBoardCost
bikeBoardCost
bannedRoutes
bannedAgencies
bannedTrips
bannedStops
bannedStopsHard
transferPenalty
nonpreferredTransferPenalty
maxTransfers
batch
startTransitStopId
startTransitTripId
clampInitialWait
reverseOptimizeOnTheFly
locale
ignoreRealtimeUpdates
disableRemainingWeightHeuristic
descendre) sont inclus dans la feuille de route
Coût de montée dans un TC (le but est d'éviter trop de
changements)
Coût de montée dans un TC avec un vélo (en général supérieur à
walkBoardCost).
Itinéraires interdits (format csv agency_[routename][_routeid] : ex.
TriMet_100 (100 is route short name) ou Trimet__42 (two
underscores, 42 is the route internal ID).
Réseaux interdits (même format).
Courses interdites (format csv agency_trip[:stop*], ex.
TriMet_24601 or TriMet_24601:0:1:2:17:18:19 )
Arrêts interdits à la montée ou descente (mais où un itinéraire peut
passer). Format csv agencyId_stopId, ex. TriMet_2107
Arrêts fermés : complètement interdits y compris qu'un itinéraire y
passe.
Pénalité supplémentaire pour les changements, à partir du 2ème
changement. En gros, les valeurs correspondent à des secondes.
Pénalité supplémentaires pour les changements, à partir du 2ème
changement, quand il ne s'agit pas d'une correspondance préférée.
Si aucune correspondance préférée ou planifiée n'est définie, ce
paramètre est ignoré.
Nombre max de correspondances pour un itinéraire. Côté serveur,
ce nb doit être inférieur à MAX_TRANSFERS défini dans
org.opentripplanner.api.ws.Planner.
Si à true, la destination est désactivée et un arbre des chemins
complet est calculé (à spécifier une seule fois)
Permet de définir un arrêt de TC par lequel l'itinéraire doit passer
en premier dans la recherche d'itinéraire (AgencyId_StopId)
Course à utiliser pour le début de l'itinéraire TC (AgencyId_TripId)
N'est effectif que pour Analyst. 0 signifie qu'aucun temps d'attente
initial ne sera soustrait. -1 (valeur par défaut)
Valeur maximale à soustraire du temps d'attente inital, pour éviter
des trajets trop optimistes. L'idée est qu'il est raisonnable de
retarder un départ de 15 minutes pour prendre un itinéraire
meilleur, mais sans doute pas de 15 heures; le cas échéant, cette
durée doit être incluse dans le temps de trajet. La valeur dépend du
type d'itinéraires, par exemple il est possible d'attendre 12 heures
pour prendre un train Paris-Berlin.
L'idée de soustraire le temps d'attente initial correspond à des
situations où les usagers sont plutôt des locaux qui connaissent
l'offre de TC et les horaires et ne vont donc pas attendre longtemps
avant un trajet, mais plutôt partir au bon moment. Ce choix
améliore les indicateurs d'accessibilité TC.
Si true, l'itinéraire retour sera optimisé à la volée. Sinon, le calcul
du retour sera effectuée une fois le trajet choisi (paramètre non
utilisé dans Analyst).
langue
Si true, les mises à jour en temps réel sont ignorées.
Utilisé uniquement pour la recherche longue distance
-1
-1
-1
-1
-1
false
-1
en_US
Exemples d'utilisation
Marseille
Dans le cadre d'un premier marché piloté par la DREAL PACA en 2013, un serveur OTPA a été mis en oeuvre
avec les données de voirie et d'offre de transport collectif (TC) du périmètre métropolitain sur une plate-forme
publique. La prestation a été confiée au groupement Conveyal / Mecatran / Modulaweb. Une mise à jour a été
effectuée début 2015, qui a permis de compléter les données et de développer les possibilités de scriptings pour
le calcul d'indicateurs d'accessibilité. Le projet est documenté ici : http://mim.cete-aix.fr/spip.php?article360
L'application est à l'adresse suivante : http://62.210.125.178/marseille/
La mise en place du prototype a été rendue possible dans un délai rapide (un mois pour la mise en ligne, deux
mois pour les améliorations) à la fois grâce à la disponibilité de données open data normalisées publiées par le
Syndicat Mixte des Transports, et par la maturité acquise depuis 2 ou 3 ans par le logiciel libre OTP. Le
prototype se présente sous la forme d’une carte web avec un menu d’options permettant de lancer un calcul et
l’affichage de surfaces isochrones (voir l'aide en ligne en cliquant sur A PROPOS), et également de faire des
calculs de scores (indicateurs d'accessibilité), à partir de données (population, emplois, lycées, collèges, etc.); le
calcul utilise les possibilités de scripting d'OTP-A.
L'apport du projet se situe à 2 niveaux : d'une part il met en évidence la pertinence des indicateurs
d'accessibilité transport, d'autre part il se place dans un cadre de travail en « innovation ouverte ». Un des
intérêts est que les développements conduits pour le site de Marseille (librairie javascript de calcul
d’indicateurs) sont mutualisés : réciproquement, Marseille pourrait bénéficier d’évolutions qui auront pu être
développées pour un projet à Mexico ou Washington.
Ce prototype a été présenté à plusieurs acteurs métropolitains à Marseille en 2014 puis en 2015; il est envisagé
de l'améliorer notamment dans 2 directions:
-1- mettre en place un site destiné au grand public et aux décideurs permettant comparer l'accessibilité depuis
un point donné, de calculer un certain nombre d'indicateurs pré-définis et le cas échéant de comparer quelques
scénarios d'offre de déplacements pré-définis.
-2- fournir aux différents services d'études une boite à outils leur permettant de calculer leurs propres
indicateurs et d'effectuer leurs propres analyses.
Fin 2014, la DREAL PACA a confirmé la décision de prolonger le prototype et de lancer les actions suivantes :
•
•
•
•
actualisation du site (hébergement d’une nouvelle version d’OTP) ;
remise à jour des données TC et OSM ;
définition de données associées et d’indicateurs d’accessibilité à calculer ;
modélisation a minima de la saturation routière.
Plus largement, cet outil nous semble répondre à certains besoins récurrents d’études Mobilité/Transport des
agences d’urbanisme, et l’équipe projet est intéressée à développer des échanges techniques et des
collaborations avec d’autres agglomérations qui travaillent avec ce type d’outils.
Comparaison de gain d'accessibilité à l'ouverture de la L2
3. Références
Les principaux sites utiles sont :
• la documentation en ligne (http://opentripplanner.readthedocs.org/) qui remplace depuis début 2015
l'ancien wiki (https://github.com/opentripplanner/OpenTripPlanner/wiki)
• le site de conveyal : http://conveyal.com/projects/analyst/ (société qui comprend les principaux
développeurs du logiciel, avec mecatran) inclut de nombreux articles très pédagogiques et pointe sur des
outils développés par eux autour d'OTP et GTFS (disponible sur leur dépôt github)
• les exécutables (.jar) : http://dev.opentripplanner.org/jars/, qui permettent d'utiliser OTP analyst sans
cloner et compiler le code sur votre poste (ce qui présente néanmoins bien sûr l'intérêt de pouvoir
adapter le code à votre besoin particulier)
• le forum utilisateurs OTP Analyst sur Google Groups, peu utilisé toutefois
(https://groups.google.com/forum/#!forum/otp-analyst)
• le forum utilisateurs OTP (https://groups.google.com/forum/#!forum/opentripplanner-users) est
nettement plus actif, avec des messages à peu près chaque jour
• la documentation technique : API (http://dev.opentripplanner.org/apidoc/) et
(http://dev.opentripplanner.org/javadoc/)
• le code source bien sûr : https://github.com/opentripplanner
• le forum développeurs OTP (https://groups.google.com/forum/#!forum/opentripplanner-dev)
javadoc
Centre d’études et d’expertise sur les risques, l’environnement, la mobilité et l’aménagement
Direction Territoriale Méditerranée - Pôle d'activités 30 Avenue Albert Einstein - CS 70499 - 13593 AIX-EN-PROVENCE Ccedex 3 -Tél : +33 (0)4 42 24 76 76
Siège : Cité des Mobilités - 25, avenue François Mitterrand - CS 92 803 - F-69674 Bron Cedex - Tél : +33 (0)4 72 14 30 30 -
www.cerema.fr