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
© Copyright 2024