Utilisation Graphserver v1 2

CETEMéditerranée

Utilisation du logiciel GraphServer

logiciel libre pour le calcul d’itinéraire TC et Multimodal

Centre d'Etudes Techniques de l'Equipement Méditerranée

www.cete-mediterranee.fr

Rapport

CETE Méditerranée DCEDI / TIM OSLANDIA

logiciel libre GraphServer pour le calcul d’itinéraire TCdate : Mars 2011

auteurs : OSLANDIA, CETE Méditerranée

responsable de l'étude : Patrick Gendre, DCEDI/TIM

participants : Olivier Courtin, Vincent Picavet OSLANDIA

résumé de l'étude :

Le CETE Méditerranée contribue au programme PREDIM et participe notamment au développement des solutions SIG open source pour l’information multimodale. La présente étude s’inscrit dans le prolongement de ces travaux.Actuellement, graphserver est à notre connaissance un des seuls logiciels libres permettant le calcul d’itinéraires sur un réseau de transport collectif ou multimodal. Un tel logiciel, couplé à un SIG, permet en principe de produire des analyses d’accessibilité en transport public qui restent pour l’instant complexes à réaliser.Ce logiciel américain bénéficie de la disponibilité de données d’offre théorique de Transport Collectif (TC) de plusieurs réseaux américains, de plus en plus diffusées sur le web depuis quelques mois. Il utilise donc en format d’entrée le format texte GTFS développé pour Google Transit et qui est devenu un standard de fait.La norme d’échanges de données d’offre TC en France n’est pas GTFS, mais un profil XML dit ‘Neptune’, récemment publié comme norme NFP 99506 (Voir le site www.chouette.mobi). Le ministère du développement durable contribue à l’effort de normalisation de l’information transport: dans le cadre du marché de maintenance du logiciel Chouette, une fonction de conversion des données disponibles au format Neptune vers le format GTFS a été développée. L’idée est de permettre ainsi à la communauté technique (collectivités autorités organisatrices de transport public, exploitants, services et bureaux d’études) de bénéficier des logiciels libres récemment créés autour du format GTFS (essentiellement développés aux USA mais pas seulement).Le présent rapport est le résultat d'une petite prestation technique (budget 3500 Euros) confiée par le CETE Méditerranée à la société Oslandia, spécialisée dans les solutions SIG open source et notamment postgis.L’objectif est de présenter le logiciel graphserver, ainsi que son utilisation possible en pratique, à la communauté (francophone) intéressée par l’information multimodale et les SIG transport.Ce document est destiné à des techniciens souhaitant tester ce logiciel, connaissant de préférence déjà linux, car le logiciel fonctionne sous ce ce système d'exploitation ; il explicite les étapes nécessaires pour l'installation de graphserver et son utilisation, en l'illustrant avec des données de l'agglomération rennaise. Les principes du fonctionnement, les points forts et faibles ainsi que les perspectives d'utilisation ou d'adaptation sont discutées en conclusion.Sur la base de ce rapport technique, le lecteur pourra donc mettre en place un environnement de travail permettant de tester par lui-même le logiciel (requêtes, scripts documentés et testés avec des données réelles).Le lecteur plus pressé ou le manager pourra lire uniquement la présentation et la conclusion, sans entrer dans les détails de mise en oeuvre, pour se faire une idée de l'intérêt potentiel de ce logiciel.

nombre de pages : 16n° d'affaire : 10C000126maître d'ouvrage : DGITM/MTI

Utilisation du logiciel libre GraphServer pour le calcul d’itinéraire TC et MM 2


Table des matières 1 INTRODUCTION.............................................................................................................................................4

1.1 Contexte........................................................................................................................................................4 1.2 Contenu du rapport.......................................................................................................................................4

2 PRÉSENTATION DE GRAPHSERVER........................................................................................................5

3 LES DONNÉES.................................................................................................................................................5 3.1 disponibilité..................................................................................................................................................5 3.2 normalisation................................................................................................................................................6

4 MISE EN OEUVRE DU LOGICIEL..............................................................................................................7 4.1 Installation....................................................................................................................................................7 4.2 Import des données.......................................................................................................................................8 4.3 Mise en place du Service Web......................................................................................................................8 4.4 Cas d'utilisation TC.....................................................................................................................................10 4.5 Cas d'utilisation VP et routier.....................................................................................................................13

5 DISCUSSION ET PERSPECTIVES.............................................................................................................13 5.1 Visualisation des données routières............................................................................................................13 5.2 limitations du logiciel.................................................................................................................................13 5.3 la question des données..............................................................................................................................14 5.4 perspectives ................................................................................................................................................14

6 ANNEXE..........................................................................................................................................................16 6.1 Références et liens......................................................................................................................................16 6.2 Glossaire.....................................................................................................................................................16



1 Introduction

1.1 ContexteLe CETE Méditerranée contribue au programme PREDIM1, et participe notamment au développement des solutions SIG open source pour l’information multimodale2. La présente étude s’inscrit dans le prolongement de ces travaux.Actuellement, graphserver est à notre connaissance un des seuls logiciels libres3 permettant le calcul d’itinéraires sur un réseau de transport collectif ou multimodal. Un tel logiciel, couplé à un SIG, permet en principe de produire des analyses d’accessibilité en transport public qui restent pour l’instant complexes à réaliser.Ce logiciel américain bénéficie de la disponibilité de données d’offre théorique de Transport Collectif (TC) de plusieurs réseaux américains, de plus en plus diffusées sur le web depuis quelques mois. Il utilise donc en format d’entrée le format texte GTFS développé pour Google Transit et qui est devenu un standard de fait.La norme d’échanges de données d’offre TC en France n’est pas GTFS, mais un profil XML dit ‘Neptune’, récemment publié comme norme NFP 99506 (Voir le site www.chouette.mobi). Le ministère du développement durable contribue à l’effort de normalisation de l’information transport : dans le cadre du marché de maintenance du logiciel Chouette, une fonction de conversion des données disponibles au format Neptune vers le format GTFS a été développée. L’idée est de permettre ainsi à la communauté technique (collectivités autorités organisatrices de transport public, exploitants, services et bureaux d’études) de bénéficier des logiciels libres récemment créés autour du format GTFS (essentiellement développés aux USA mais pas seulement4).Le présent rapport est le résultat d'une petite prestation technique (budget 3500 Euros) confiée par le CETE Méditerranée à la société Oslandia, spécialisée dans les solutions SIG open source et notamment postgis.

1.2 Contenu du rapportL’objectif est de présenter le logiciel graphserver, ainsi que son utilisation possible en pratique, à la communauté (francophone) intéressée par l’information multimodale et les SIG transport.Ce document est destiné à des techniciens souhaitant tester ce logiciel, connaissant de préférence déjà linux, car le logiciel fonctionne sous ce ce système d'exploitation ; il explicite les étapes nécessaires pour l'installation de graphserver et son utilisation, en l'illustrant avec des données de l'agglomération rennaise. Les principes du fonctionnement, les points forts et faibles ainsi que les perspectives d'utilisation ou d'adaptation sont discutées en conclusion.Sur la base de ce rapport technique, le lecteur pourra donc mettre en place un environnement de travail permettant de tester par lui-même le logiciel (requêtes, scripts documentés et testés avec des données réelles).Le lecteur plus pressé ou le manager pourra lire uniquement la présentation et la conclusion, sans entrer dans les détails de mise en oeuvre, pour se faire une idée de l'intérêt potentiel de ce logiciel.

Le plan du rapport est le suivant :- présentation de graphserver- les données TC et voirie- Mise en Oeuvre du logiciel : exemple d’utilisation TC, exemple multimodal- limitations / problèmes de données ou autres retours d’expériences- Conclusions : premier bilan, limitations du logiciel et perspectives- en annexe : références (liens utiles) et glossaire

1 www.predim.org2 www.potimart.org3 en excluant les prototypes de recherche, et surtout opentripplanner, qui est une initiative à laquelle contribue d'ailleurs le

développeur de GraphServer, mais sur lequel nous n'avons pour l'instant pas trouvé d'informations suffisantes pour décider de l'évaluer

4 Cf. Mumoro, librairie python de calcul d'itinéraires multimodaux développée par Tristram Graebener dans le cadre de sa thèse à Toulouse soutenue en 2010 :https://github.com/Tristramg/mumoro/tree/master/lib



2 Présentation de graphserverGraphserver est un logiciel libre développé depuis environ 2007 à l'initiative d'une seule personne (B. Mander). Le code est disponible sur http://graphserver.github.com/graphserver/ . Le développement du logiciel est encore actif, et quelques autres développeurs semblent contribuer ou travailler sur des versions alternatives (forks). Ce logiciel n'est donc pas complètement confidentiel (ce qui justifie que nous nous y soyons intéressés) ; nous ne connaissons pas en revanche sa réelle utilisation ni un éventuel déploiement dans un site web d'un réseau TC.La meilleure référence pour graphserver est sans doute walkscore5, un site web proposant un service de calcul d'accessibilité interactif, initialement piétonne, et depuis 2009 en TC (via graphserver), même si cela montre le caractère encore prototype de l'outil.Graphserver s'inscrit dans la dynamique des développements open source américains autour du TC et de la multimodalité (OneBusAway, OpenTripPlanner), apparus en même temps que la libre diffusion de données TC depuis 2 ou 3 ans et l'ouverture de web services destinés aux développeurs sur les sites des réseaux TC, accompagnant le fort succès Outre-Atlantique de Google Transit et de son concurrent HopStop.La documentation disponible est minimale, mais indique en deux pages comment installer et utiliser le logiciel. Il existe aussi un forum6 où quelques utilisateurs/développeurs ont pu obtenir réponse à leur question. Quelques copies d'écran sont disponibles, notamment des arbres de plus court chemin (shortest path tree), qui représentent ), ce qui est une manière très de visualiser l'accessibilité, intéressante pour un SIG transport. Grâce à la disponibilité des données TC au format GTFS aux USA, et de données OpenStreetMap (OSM) pour la voirie, on constate que graphserver peut traiter avec des performances raisonnables un réseau comme celui de Seattle.Le logiciel est développé en python, sauf le calcul d'itinéraire lui-mêle, écrit en C; la base de données utilisée est sqlite. Il semble bien conçu, il comprend un site web permettant d'interroger le calcul d'itinéraire depuis un navigateur (en mode REST) et potentiellement adaptable ou extensible (par exemple) Un point faible sans doute est qu'apparemment l'algorithme de calcul d'itinéraires est assez basique; GraphServer ne travaille qu'avec un seul graphe où sont fusionnées la voirie et le réseau TC, là où la plupart des logiciels évolués distinguent en général plusieurs graphes voire une hiérarchie dans les réseaux.

3 Les donnéesLa question des données est évidemment centrale pour la mise en oeuvre du logiciel.

3.1 disponibilitéLe premier aspect est la disponibilité des données. Jusqu'à récemment, les développeurs ou chercheurs qui souhaitaient développer des outils d'analyse de graphes de réseaux de transport avaient beaucoup de mal à se procurer des données, et étaient parfois contraints de les ressaisir, ou des les récupérer par des moyens plus ou moins détournés.Sur ce sujet, le CETE Méditerranée a produit un rapport sur la mutualisation des données transport en 2009 7, puis sur l'accès des données TC en France début 20108. La situation évolue et il est vraisemblable que les données d'offre théorique TC finissent par être reconnues comme des données relevant de la loi sur la réutilisation des données publiques. En matière de voirie, la récente explosion des données disponibles grâce à OpenStreetMap a changé la donne (le CETE et la société 3Liz ont également produit début 2010 un rapport sur OSM9). L'IGN a de son côté largement assoupli sa politique de diffusion de ses données du Référentiel à Grande Echelle (qui comprend une couche voirie) depuis fin 2010.

5 http://www.walkscore.com/transit-map.php6 http://groups.google.com/group/graphserver7 http://www.cete-mediterranee.fr/tt13/www/article.php3?id_article=2168 http://www.cete-mediterranee.fr/tt13/www/article.php3?id_article=1389 http://www.cete-mediterranee.fr/tt13/www/article.php3?id_article=221



3.2 normalisationLe second aspect concerne la normalisation des données. De fait, la description d'un réseau de TC est complexe, même en se limitant aux seuls aspects relatifs à l'info voyageurs (lignes, horaires, arrêts). En Europe, on peut s'appuyer sur le modèle de données Transmodel qui décrit les principales notions utiles pour décrire un réseau de transport public, et sur des travaux annexes tels que IFOPT pour décrire les lieux et objets fixes du TC, puis en France sur le profil Chouette/Neptune pour échanger des fichiers XML décrivant chacun une ligne. Les réseaux TC européens sont sans doute les plus avancés en matière d'outils de diffusion sur l'internet (avec le Japon). Néanmoins, la diffusion de l'information TC dans une logique « web 2.0 » est essentiellement nord-américaine, et le standard de fait qui semble s'imposer pour la diffusion de données TC est le format GTFS créé par Google pour le service Google Transit10. Le principe est que les réseaux TC qui souhaitent bénéficier de Google Transit (qui fournit un service de recherche d'itinéraire TC gratuit sur l'internet avec le niveau de service très élévé de Google) envoient leurs données à Google dans dossier zippé comprenant un fichier au format texte par élément de données (horaires, arrêts, etc.) selon des spécifications définies par Google. Plusieurs grands réseaux TC américains ont diffusé librement leurs données sur le web à ce format, ce qui a suscité le développement de logiciels TC par la communauté technique qui utilisent le format GTFS11.Ce format présente certains défauts, par rapport aux profils d'échange existant en Europe, qui ont été analysés notamment en détail par les anglais (cf. par exemple http://rtig.org.uk/web/Portals/0/090206%20-%20PTIC%20-%20Transmodel%20GTFS%20-%20v4%20%28Issued%29.pdf), néanmoins il est déjà assez complet, simple à utiliser et disponible. En pratique, des outils12 de validation et de visualisation des données, un peu analogues à Chouette pour le format Neptune, ont été développés par Google et par la communauté technique, qui permettent de traiter assez facilement les données GTFS.Depuis quelques années, des systèmes d'information multimodale (SIM) ont été mis en place par les collectivités Autorités Organisatrices de Transport (AOT), qui fédèrent les données de plusieurs réseaux TC, le plus souvent au niveau régional ou départemental. Pour faciliter les échanges de données d'offre TC, ces systèmes supportent un format d'échange standard normalisé au niveau français, le profil d'échange XML Neptune13 (norme NFP 99506 depuis début 2011). Le ministère du développement durable et des transports a financé le développement du logiciel libre Chouette qui permet de valider, échanger et gérer des données d'offre TC au profil Neptune. Techniquement, il est donc possible de disposer des données d'offres de la plupart des réseaux TC français au format Neptune (en tout cas de ceux qui sont mutualisés dans des SIM - soit une bonne moitié d'entre eux). Dans le cadre du marché de maintenance du logiciel Chouette a été développée une fonction d'export vers le format GTFS, ce qui permettra en principe de tester le logiciel GraphServer avec les données d'un grand nombre de réseaux TC en France.Pour notre étude, nous avions obtenu l'accord de Tisseo, l'AOT du Grand Toulouse, pour effectuer les tests de GraphServer avec les données du réseau TC toulousain, disponibles au format Neptune (en fait Trident, la version antérieure, ce qui ne change rien en pratique). Néanmoins, les tests d'export des données Tisseo en GTFS se sont avéré produire un grand nombre d'erreurs lorsque soumis aux tests de validation GTFS, que nous n'avons pas eu le temps d'élucider étant les fortes contraintes de temps de la prestation d'Oslandia pour le CETE.Nous avons donc décidé rapidement d'utiliser plutôt les données GTFS que le réseau rennais STAR a mis en ligne en octobre 2010 (http://data.keolis-rennes.com/fr) dans le cadre du projet Rennes open data (http://www.data.rennes-metropole.fr/). Il est d'ailleurs notable que pour cette initiative open data, le format GTFS ait été choisi, plutôt que le format XML Neptune, tablant sans doute sur une facilité d'utilisation plus grande pour les développeurs. Il sera néanmoins intéressant de publier aussi les données au format Neptune, dans la mesure où le logiciel libre Chouette associé à ce format facilite grandement leur exploitation.En tout cas, il faudra suivre attentivement le retour d'expériences sur les développements que la publication de ces données (et d'autres web services) aura suscité dans la communauté technique, à partir du printemps 2011 (en principe le 30 mars).

10 http://transit.google.com11 http://code.google.com/intl/fr/transit/spec/transit_feed_specification.html12 http://code.google.com/p/googletransitdatafeed/wiki/FeedValidator13 http://www.chouette.mobi/spip.php?rubrique40



Les données rennaises étant directement en GTFS, et passant avec succès les tests de validation, elles ont donc été directement utilisées pour tester graphserver.

En matière de données de voirie, les seules données librement diffusées et utilisables en pratique, en tout cas en Europe, sont celles produites par le site de cartographie collaborative OpenStreetMap, décrit dans un autre document d'étude du CETE. Le format XML d'OSM est donc un standard de fait, avec une riche palette d'outils d'édition, de validation et de conversion de données, le plus souvent des logiciels libres.En pratique pour notre test, nous avons donc extrait les données d'OSM autour de Rennes selon des modalités techniques expliquées plus loin.

4 Mise en oeuvre du logiciel

4.1 Installation

Graphserver est dévellopé sous Unix Like. Il est ainsi plus aisé de le déployer sur un OS similaire, dans le cadre de cet étude un Linux Debian-like.

GraphServer est une application intégrant à la fois du C et du Python, il est donc nécessaire de disposer des environnements de compilation et de déploiement respectif de ces deux environnements, soit:

sudo apt-get install python-setuptools python-dev sudo apt-get build-essential git-core

Il est ensuite nécessaire d'installer GraphServer lui même, en prenant la dernière version stable à ce jour des sources, ou la dernière version du trunk via l'utilisation d'un client GIT.

git clone git://github.com/graphserver/graphserver.git graphservercd graphserversudo python2.6 setup.py install

Il est ensuite nécessaire d'installer un Index Spatial de type R-Tree pour pouvoir utiliser les données OSM avec GraphServer:

wget http://download.osgeo.org/libspatialindex/spatialindex-src-1.6.0.tar.gztar xvzf spatialindex-src-1.6.0.tar.gz cd spatialindex-src-1.6.0/./configure makesudo make installeasy_install RTree

Ainsi que l'utilitaire Osmosis, permettant l'extraction de sous parties de fichiers OSM:wget http://gweb.bretth.com/osmosis-latest.zip -O osmosis.zipunzip -x osmosis.zip chmod a+x ./osmosis-0.30/bin/osmosis

Il est également nécessaire de disposer du package Python PyAML, pour pouvoir utiliser le service Web intégré (manipulation de fichier de configuration YAML)

sudo easy_install pyyaml


http://downlo/


4.2 Import des données

La phase d'import des données TC est la suivante : gs_gtfsdb_build gtfs/rennes.zip rennes.gtfsdb gs_import_gtfs rennes.gdb rennes.gtfsdb

La base rennes.gtfsdb contient les informations TC dans un format SqLite utilisable par GraphServer, et très proche de la donnée GTFS initiale.La base rennes.gdb contient une donnée de type graphe (arc, noeud) dans un format SqLite.

Pour les données OSM, il convient tout d'abord de déterminer l'emprise des données:sqlite3 rennes.gtfsdb "select min(stop_lon),min(stop_lat),max(stop_lon),max(stop_lat) from stops"47.9595772386088|-1.93282718563826|48.2232224082137|-1.47822752351023

Sur une étendue un tant soit peu conséquente (plus de 50000 noeuds), il n'est pas possible de passer directement par l'API d'OSM pour extraire les données.

Il est donc nécessaire14 de récupérer le jeu de données OSM routier France entière puis de le découper sur l'emprise de Rennes via l'utilitaire Osmosis:

wget http://downloads.cloudmade.com/europe/france/france.osm.highway.bz2bunzip2 france.osm.highway.bz2

osmosis-0.30/bin/osmosis --read-xml france.osm.highway --bounding-box left=-1.93282718563826 bottom=47.9595772386088 right=-1.47822752351023 top=48.2232224082137 --write-xml rennes.osm

gs_osmdb_compile rennes.osm rennes.osmdbgs_import_osm rennes.gdb rennes.osmdb

Il convient enfin de lier les deux graphes (TC et routier) dans un modèle commun:gs_link_osm_gtfs rennes.gdb rennes.osmdb rennes.gtfsdb

Le lien entre les deux graphes est réalisé via un calcul de distance minimale sur les points de rattachement géométriques.Un couple noeud OSM, noeud TC est alors apparéillé.

Nota: dans le cadre des données de Rennes l'appariement pose problème: tous les noeuds TC sont rattachés au même noeud OSM, ce qui rend ensuite les calculs multimodaux incohérents. Les calculs multimodaux dans le cadre de cet étude ont donc utilisé un autre jeu de données, à savoir la ville d'Adélaïde en Australie.

4.3 Mise en place du Service WebGraphServer est livré en natif avec un service Web Python (API REST) permettant d'interagir avec le moteur de calcul d'itinéraires pour les fonctions les plus courantes. L'utilisation du serveur Web est illustrée aux 4.4 et 4.5.La documentation de cet API est (comme le reste du projet GraphServer) très spartiate, et se résume à quelque exemples sur la page principale du site officiel.

14 il serait possible sinon de récupérer des données au format .SHP par Région française, et de faire la sélection dans un SIG (QGIS, ArcGis ou autre), mais comme graphserver utilise le format .osm, OSMOSIS est la solution la plus 'naturelle'.


http://downloads.cloudmade.com/europe/france/france.osm.highway.bz2


Il convient tout d'abord de mettre en place un fichier de configuration pour le service, un fichier de template (modèle) est disponible dans l'archive de GraphServer, à l'emplacement suivant:

graphserver/pygs/graphserver/ext/routeserver/handlers.yaml

Ci dessous, un exemple de fichier de configuration handlers.yaml utilisé pour les données de Rennes:

edge_handlers: - name: graphserver.ext.routeserver.events.BoardEvent args: gtfsdb_filename: rennes.gtfsdb timezone_name: Europe/Paris - name: graphserver.ext.routeserver.events.DescribeCrossingAtAlightEvent args: gtfsdb_filename: rennes.gtfsdb timezone_name: Europe/Paris - name: graphserver.ext.routeserver.events.AlightEvent args: gtfsdb_filename: rennes.gtfsdb timezone_name: Europe/Paris - name: graphserver.ext.routeserver.events.StreetEvent args: osmdb_filename: rennes.osmdb timezone_name: Europe/Paris - name: graphserver.ext.routeserver.events.HeadwayBoardEvent args: gtfsdb_filename: rennes.gtfsdb timezone_name: Europe/Paris - name: graphserver.ext.routeserver.events.HeadwayAlightEvent args: gtfsdb_filename: rennes.gtfsdb timezone_name: Europe/Paris - name: graphserver.ext.routeserver.events.HeadwayAlightEvent args: gtfsdb_filename: rennes.gtfsdb timezone_name: Europe/Paris vertex_handlers: - name: graphserver.ext.routeserver.events.StreetTurnEvent args: osmdb_filename: rennes.osmdb timezone_name: Europe/Paris - name: graphserver.ext.routeserver.events.StreetStartEvent args: osmdb_filename: rennes.osmdb timezone_name: Europe/Paris - name: graphserver.ext.routeserver.events.StreetEndEvent args: osmdb_filename: rennes.osmdb timezone_name: Europe/Paris

vertex_reverse_geocoders: - name: graphserver.ext.routeserver.geocoders.OSMReverseGeocoder args: osmdb_filename: rennes.osmdb

Dans cet exemple nous faisons tourner le service Web sur le port 81sudo gs_routeserver rennes.gdb handlers.yaml -p 81

Nota: il convient de lancer le gs_routeserver en tant que root (via sudo donc) si le port



utilisé est < à 1024 (port TCP réservés).

Exemple de retour suite au lancement du Web Service:edge event handlers: <graphserver.ext.routeserver.events.BoardEvent instance at 0x105e878>vertex event handlers: <graphserver.ext.routeserver.events.StreetTurnEvent instance at 0x105e9e0>vertex reverse geocoders: <graphserver.ext.routeserver.geocoders.OSMReverseGeocoder instance at 0x105ebd8>Loaded 205230 vertices Loaded 150676 edges starting HTTP server

4.4 Cas d'utilisation TC

Pour lister tous les noeuds du graphes: http://91.121.21.38:81/vertices

En retour, le serveur liste toutes les stations, les points de passage du graphe TC et les noeuds OSM, soit par exemple

wget 'http://91.121.21.38:81/vertices' -O foo && grep sta foo

Permet de lister uniquement les stations:sta-langevi3sta-2601sta-2602sta-2603sta-2605sta-2606sta-2607sta-2608sta-2609sta-2610sta-2611...

Pour lancer un plus court chemin entre deux arrêts, à une date donnée:http://91.121.21.38:81/path?origin = "sta-zola1"&dest="sta-langevi3"&currtime=1287607773

Le retour est un flux GeoJSON, soit avec l'exemple précédent:{ "performance": { "cleanup_time": 0.011898040771484375, "narrative_postprocess_time": 0.0099318027496337891, "path_query_time": 0.041937112808227539 }, "narrative": [ [ "BoardEvent", { "when": "2010-10-20 14:08:00-07:00", "what": "Board the 8-SAINT GREGOIRE - POTERIE", "geom": [ 48.109766999999998, -1.679192


http://91.121.21.38:81/path?origin=

http://91.121.21.38:81/path?origin

http://91.121.21.38:81/vertices


], "where": "Lyce Zola" } ], [ "BoardEvent", { "when": "2010-10-20 14:26:00-07:00", "what": "Board the 8-SAINT GREGOIRE - POTERIE", "geom": [ 48.087556834906799, -1.64351029096876 ], "where": "La Poterie" } ], [ "BoardEvent", { "when": "2010-10-20 15:09:00-07:00", "what": "Board the 2-La Poterie - Haut Sanc / Grand Quartier", "geom": [ 48.133150728584603, -1.6850967490536499 ], "where": "Lyce Mends France" } ], [ "BoardEvent", { "when": "2010-10-20 15:13:00-07:00", "what": "Board the 2-La Poterie - Haut Sanc / Grand Quartier", "geom": [ 48.135817012396899, -1.6931443469957099 ], "where": "Grand Quartier" } ], [ "BoardEvent", { "when": "2010-10-20 15:27:00-07:00", "what": "Board the 4-Beauregard / Beaulieu Atalante", "geom": [ 48.1098741847387, -1.6834911717813299 ], "where": "Place de Bretagne" } ], [ "BoardEvent", { "when": "2010-10-20 21:43:00-07:00", "what": "Board the 67-Rennes (Rpublique) / Noyal s/Vilaine - Brc", "geom": [ 48.109846407899902, -1.6592400882056 ], "where": "Robidou" } ],



[ "BoardEvent", { "when": "2010-10-20 22:39:00-07:00", "what": "Board the 32-Triangle/Beaulieu/Clos courtel", "geom": [ 48.1146308750115, -1.6520430667902 ], "where": "Hpital Rgnier" } ] ]}

En utilisant les données d'Adélaïde, l'on peut également comparer le trajet avec un résultat Google trafic. Et les deux feuilles de routes sont remarquablement similaires dans l'exemple choisi:

http://91.121.21.38:81/path?origin="sta-10"&dest="sta-8139"


http://91.121.21.38:81/path?origin


4.5 Cas d'utilisation VP et routier

On peut réaliser un calcul d'itinéraire multimodal couplant TC et routier simplement en indiquant un noeud de chaque, soit par exemple:http://91.121.21.38:81/path?origin=%22sta-langevi3%22&dest=%22osm-282588717%22&currtime=1287607773

A noter que dans le cas d'une requête mixte les déplacements routiers sont en mode piéton. Il n'y a donc pas de question à se poser au niveau algorithmique sur la gestion de véhicule.Les parties piétonnes pouvant ainsi apparaître à n'importe quel partie du trajet.

5 Discussion et perspectives

5.1 Visualisation des données routièresIl est envisageable de réutiliser le flux GeoJson renvoyé par le serveur python de GraphServer pour gérer côté client l'affichage des géométries du chemin retenu.

Les applications côté client peuvent ensuite être au choix OpenLayers (qui est capable de manipuler nativement du GeoJson), ou Google Maps comme dans l'exemple ci dessous (copie d'écran du site BusMonster à Seattle):

5.2 limitations du logicielLes tests que nous avons effectués nous ont montré la difficulté de fusionner les graphes TC et voirie sur les données de Rennes.Il conviendrait de pouvoir étudier plus finement si ceci est davantage lié aux données GTFS de Rennes et/ou à GraphServer.


http://91.121.21.38:81/path?origin=%22sta-langevi3%22&dest=%22osm-282588717%22&currtime=1287607773

http://91.121.21.38:81/path?origin=%22sta-langevi3%22&dest=%22osm-282588717%22&currtime=1287607773


Par ailleurs, l'algorithme de calcul d'itinéraire (une variante de l'incontournable Dijkstra) est apparemment très basique, et notamment travaille sur un seul graphe VP+TC, ce qui n'est sans doute pas pertinent.Il n'y a pas à proprement parler de spécificités TC dans le moteur d'itinéraire, et certains trajet peuvent être sous optimaux pour un humain.

Le logiciel reste assez 'brut', et demande un investissement technique pour être utilisé.Il ne gère en entrée que les formats GTSF et OSM, néanmoins il serait possible de développer des outils de conversion pour d'autres formats (c'est d'ailleurs ce que nous avons fait pour Chouette/Neptune).

En matière de calculs d'itinéraire, nous recommandons à toute personne intéressée de lire l'état de l'art de l'excellente thèse de Tristram Graebener, soutenue à Toulouse fin 2010. Signalons également qu'à l'occasion de sa thèse, T Gräbener a publié en open source des librairies de calcul d'itinéraires multimodale (mumoro) qui méritent certainement d'être analysées.

Il n'est pas aujourd'hui possible d'exploiter directement les données pour les visualiser sur un SIG ; néanmoins les informations géographiques (coordonnées des arrêts, tracés des chemins) pourraient être convertis, ou réutilisé via scripting dans OpenLayers.Autre piste, Graphserver utilise la BD open source SqLite, dont il existe une version SpatiaLite permettrait de gérer ces informations selon les standards du monde des SIG.

5.3 la question des donnéesAujourd'hui peu de données sont librement disponibles, néanmoins la situation pourrait évoluer assez vite dans les mois qui viennent, plusieurs collectivités AOT s'étant déclarées favorables à la libre diffusion des données en vue de favoriser leur réutilisation (cette approche étant complémentaire de la publication de web services d'info TC).Les AO pourraient décider de les publier directement au format GTFS (ce format étant assez facilement exportable par les prestataires de SIM) et/ou en Neptune (exportable alors en GTFS depuis Chouette) ; les outils de validation/visualisation de données disponibles devraient rendre cette tâche relativement aisée.La difficulté principale pour le calcul d'itinéraires multimodaux VP+TC est de définir les points de transition entre le réseau de voirie et le réseau TC. GraphServer génère ces points automatiquement sur une logique de distance géographique minimale.

5.4 perspectives Nous rédigeons volontairement cette conclusion sous forme d'une liste d'actions mises au conditionnel, dans la mesure où nous le CETE ni Oslandia n'ont le projet d'approfondir l'étude à court terme, faute de moyens, néanmoins nous nous tiendrons en mode 'veille active' sur le sujet et nous sommes preneurs de toutes questions et suggestions de la part de lecteurs éventuellement intéressés !

1. Il faudrait approfondir les tests sur un réseau français (Toulouse par exemple, mais il est possible que le concours organisé par Rennes nous apporte la bonne surprise d'un projet qui aurait fait ce travail dans le cadre Rennes Open Data !), pour vérifier notamment si la "fusion" des graphes TC et VP est gérable correctement. Sans engager de gros moyens, il y a là des sujets de stage

2. Il faudra suivre l'avancement du projet OpenTripPlanner, qui pourrait à terme prendre le relais de graphserver comme logiciel libre de référence pour le calcul d'itinéraire multimodal.

3. Il faudra bien sûr suivre les initiatives open data en France, qui auront forcément un volet transport ; après Rennes et Brest, des villes comme Montpellier, Bordeaux et Paris sont annoncées... Voir par exemple le site



www.mobirennes.com qui est une application open source de calcul d'itinéraire TC et Multimodal.L'Agence Française de l'Information Multimodale et de la Billettique (AFIMB) récemment créée15 par le ministère du développement durable doit pouvoir contribuer.

3. Il faudrait arriver à travailler avec les chercheurs français qui travaille sur le sujet ; ils sont peu nombreux.

4. plus largement, une mutualisation de retours d'expérience parmi les utilisateurs et fournisseurs de solutions de calcul d'itinéraire ou de SIG transport est à organiser, dans le cadre d'un site web (wiki / veille) ou de journées techniques 2 ou 3 fois par an, éventuellement dans le cadre d'un marché financé par le ministère.

5. GraphServer n'est sans doute pas une solution industrielle pour des services d'information usagers (en tout cas pas en l'état), pour lesquels il existe de toute façon une offre commerciale satisfaisante semble-t-il, en revanche cela peut être un outil d'étude intéressant pour produire des cartes d'accessibilité ou des arbres de plus court chemin, c'est d'ailleurs dans ce sens que le logiciel a été mis en oeuvre pour walkscore.Son architecture assez ouverte et des choix techniques qui nous semblent pérennes et pertinents (Python, Web service rest, georéférencement) permettrait par exemple d'envisager son intégration dans la boîte à outils SIG transport de Potimart.

15 http://www.predim.org/spip.php?article3504



6 Annexe

6.1 Références et lienshttp://groups.google.com/group/graphserver/https://github.com/graphserver/graphserver

www.chouette.mobiwww.predim.orgwww.oslandia.comwww.potimart.orghttp://data.keolis-rennes.com/frhttp://www.data.rennes-metropole.fr/www.tisseo.fr

http://code.google.com/p/googletransitdatafeed/http://rtig.org.uk/web/Portals/0/090206%20-%20PTIC%20-%20Transmodel%20GTFS%20-%20v4%20%28Issued%29.pdfhttp://code.google.com/p/googletransitdatafeed/wiki/FeedValidator

http://www.cete-mediterranee.fr/tt13/www/article.php3?id_article=273 la présente étudehttp://www.cete-mediterranee.fr/tt13/www/article.php3?id_article=216 Accès aux données TChttp://www.cete-mediterranee.fr/tt13/www/article.php3?id_article=138 Mutualisation des données transporthttp://www.cete-mediterranee.fr/tt13/www/article.php3?id_article=221 OSM

http://www.walkscore.com/transit-map.phpwww.sqlite.org et http://www.gaia-gis.it/spatialite/index.htmlhttp://opentripplanner.org/http://vrac.tristramg.eu/these_vSoutenance.pdfhttps://github.com/Tristramg/mumoro/tree/master/libwww.mobirennes.com

6.2 GlossaireSIGLE DEFINITION3LIZ http://3liz.orgAFIMBAgence française pour l’information multimodale et la billettiqueAOs Autorités organisatricesAOTU Autorité organisatrice de transports urbainsCERTUCentre d'Études sur les Réseaux, les Transports, l'Urbanisme et les constructions publiquesCETE Centre d'Études Techniques de l'ÉquipementgraphserverGTFS Google Transit Feed SpecificationOpenStreetMapOSMOslandia http://www.oslandia.comPREDIM Plateforme de Recherche et d'Expérimentation pour le Développement de l'Information MultimodaleSIG Système d'Information GéographiqueSIM Système d'Information MultimodaleTC Transport CollectifTrident, Chouette, Neptune www.chouette.mobiVP Voiture Particulière


Documents

Utilisation Graphserver v1 2