Jeudi soir se déroulait à Paris, dans les locaux de la Fondation Mozilla, le premier meetup consacré à l’Open Transport. La thématique du soir ? Quelques applications de l’Open Data à la mobilité : calculateurs d’itinéraires Open Source, problématiques de normalisation pour profiter des outils du Big Data, utilisation d’Open Street dans les gares SNCF, visualisation des déplacements de train, et surtout analyse des données transport, pour aller au-delà de « l’assistant personnel de mobilité ». Avec en conclusion une question centrale : comment constituer un référentiel d’adresses ouvert, libre et collaboratif.

C’était dense, inspirant, convivial. Ci-dessous un résumé des idées qui ont retenu mon attention, et quelques commentaires. Merci aux organisateurs, à tous les participants, et rendez-vous à l’automne pour la prochaine édition.

La vidéo de l’évènement est disponible sur le site de Mozilla Air.

Les calculateurs d’itinéraires Open Source

Canal TP est à l’initiative du projet Navitia. Ce calculateur d’itinéraires a été rendu Open Source par la filiale de Keolis consacrée au numérique (pour les transports !) en avril dernier. Cela prend la forme d’une API ouverte disponible sur navitia.io

Au-delà de l’aspect communication, Canal TP participe à une démarche conjointe de différents projets Open Source pour le calcul d’itinéraires (Synthèse, OpenTripPlanner, BlikSem) pour développer des synergies. Cela devrait se traduire par un travail en commun sur les formats d’échanges de données en temps réel, utilisés par exemple pour signaler les anomalies sur le trafic (en cas de grève SNCF ?). L’objectif est de pouvoir réutiliser plus facilement les briques logiciels et algorithmes disponibles en Open Source, en échangeant les données et messages dans un cadre normalisé, donc d’augmenter la réutilisation du code.

Martin vous guide, une application utilisant Navitia pour fournir des informations sur les loisirs et le moyen d'y accéder
Fonctionnement de l’application « Martin vous guide »

La démarche de Canal TP entre en phase d’industrialisation. Ce que je comprends du modèle économique, c’est que la société ouvre sa plateforme à des contributeurs, la rend éventuellement plus agile, et offre à ses clients (collectivités territoriales par exemple) la possibilité de bénéficier des apports de l’écosystème qui pourrait se développer progressivement. Cela signifie que Canal TP se rémunère sur l’implémentation et la maintenance de son outil plutôt que sur un système de licence classique. Cela signifie que la porte est ouverte pour des startups et des porteurs de projet voulant utiliser l’API à leur propre compte, pour créer des applications. C’est alors l’écosystème et la PlateForme de Navitia qui s’enrichit.

Cette approche semble porter des fruits, puisque plusieurs projets évoqués qui utilisent Navitia sont plutôt novateurs :

  • Voyages pote à porte et multi-modal en Europe pour le compte voyages-sncf.com (pour faire mieux que Multicity qui peine à trouver un modèle ?)
  • Incitation au report modal en offrant des fonctionnalités multimodales intégrales pour Mappy
  • HomeNow, projet issu du DataShaker (initiative SNCF / Silicon Sentier), application pour ne pas louper le dernier métro en fin de soirée. L’intérêt est surtout dans la manière ludique d’apporter l’information en push à l’utilisateur
  • Flat Turtle, développé par une startup belge, qui permet de visualiser l’offre de mobilité autour d’un bureau ou d’un bien immobilier
  • UrbanPulse, l’application de TransDev permettant de lier info voyageurs et bons plans / loisirs
  • Martin vous guide, une application à destination des touristes, pour appréhender l’information voyageurs dans le contexte de la visite de la ville de Paris par des touristes

Il en ressort que Canal TP, en ouvrant son produit de calcul d’itinéraire, travaille non seulement son image auprès de ses clients et de la communauté des développeurs, mais augmente la valeur de celui-ci et constitue un laboratoire d’exploration des usages d’Open Transport qui apportera une vraie plus-value à l’entreprise s’ils poursuivent la démarche.

Pieter Colpaert, chercheur et entrepreneur de l’Open Data (Belgique), a présenté quelques-uns des dangers qui pèsent sur l’approche actuelle des calculateurs d’itinéraires : même Open Source et exploitant de l’Open Data, ils dépendent de sources d’informations centralisées, des banques de données (après aggrégation et retraitement, parfois manuel), qui constituent alors des « Single Point of Failure ». La réponse à cela, ce sont les technologies et standards du web. Pour régler les problèmes de scalabilité (synchronisation de données, mise en cache, interopérabilité sémantique), il faut pouvoir utiliser les outils et méthodologies utilisées dans le Big Data. Cela commence par utiliser le protocole http, des standards de messages comme JSON et un vocabulaire standardisé des URL (une sémantique) adaptée à cet usage. Le projet porté par Pieter (avec des exemples sur le portail iRail), c’est d’aboutir à une normalisation W3C.

Transilien mappe ses gares

Le projet

370 gares en Ile de France, et dans chacune, par dizaines : des équipements ferroviaires et techniques, des éléments de cheminement (quais, ascenseurs, escaliers), des services et zones de services liées à la mobilité (parking, vélo, etc…) et des services en gare (téléphone, guichets, commerces).

La réalité c’est que jusqu’à aujourdh’ui la SNCF elle-même n’en avait pas une vision exhaustive et unifiée. Le projet de Transilien a consisté a mappé l’ensemble des POI de ses gares, pour les mettre à disposition non seulement du grand public et des développeurs, mais aussi de ses propres équipes et de son personnel. Après 3 mois de travail, dont une partie en collaboratif (mapping party), le résultat est une base de données en libre accès pour des réutilisations possibles nombreuses.

Outre les sujets d’accessibilité, notamment les PMR (mais je pense que c’est restrictif, le suejt de l’accessibilité est bien plus large !), de multiples réutilisation sont envisageables :

  • En interne : pour des applications SNCF Transilien à destination du grand public, pour fournir de l’information au personnel, voire des interactions directes.
  • En externe : Ces POi contiennent plein d’informations sur les services et équipements disponibles en gare, elles permettent aussi d’envisager des calculs de déplacement indoor plus précis.

Ce projet s’inscrit dans la démarche Open Data de la SNCF qui vise à favoriser la réutilisation de ses données et des nombreux actifs de son réseau et de ses stations en termes d’informations.

Une question subsiste : comment maintenir la qualité de la donnée dans chacune des gares ?Compter sur les utilisateurs, c’est bien, mais il faudra des outils adaptés à des utilisateurs sans connaissances particulières.

Petit test en gare

Du coup je suis allé ce que cela donnait côté informations disponibles. J’habite Pontoise, donc je connais bien la gare, ainsi que celles avoisinantes. Première remarque de banlieusard, les gares RER comme Cergy-Préfecture ne semblent pas prises en compte. Donc plusieurs gares n’ont pas d’infos disponibles à ce jour. Peut-être y aura-t-il des mises à jour ?

Ensuite, selon la taille des gares, le niveau d’information n’a pas l’air aussi fin. En gare de Saint-Ouen l’Aumône seules sont disponibles les infos sur les plateformes, la gare elle-même et la sortie. Tandis qu’en gare de Pontoise, l’information est bien plus riche, avec notamment l’emplacement des bancs (il y a aussi des bancs à Saint-Ouen l’Aumône 🙂 ).

Cartographie Open Street Map de la gare de Pontoise - SNCF Transilien
Cartographie Open Street Map de la gare de Pontoise – SNCF Transilien

En gare de Pontoise, plusieurs infos sont intéressantes. La position de la gare bien sûr, l’entrée principale (mais pas l’entrée secondaire par le pont piéton qui absorbe uen grande partie du flux) et l’intersection avec la rue (indiquée de type « highway » ?). Les quais sont bien positionnés, et certains éléments intéressants comme la sortie spéciale de nuit ou les panneaux d’affichage.

En revanche il y a des lacunes. Outre le fait que les bancs ne sont pas forcément indiqués au bon endroit du quai ou sont manquants (donc l’info n’est pas exhaustive), je suis déçu que toute la passerelle (entrée secondaire) semble avoir été ignorée. Les nombreux escalators menant à la passerelle ne sont pas présents non plus. Apparemment les escaliers ne sont pas mentionnés, dans toute la gare, mais les ascenseurs le sont. Côté service, les guichets ne sont pas indiqués, et plus surprenant encore, le Relay H non plus, situé dans la gare. C’est pourtant un service notable pour une petite gare comme Pontoise. D’ailleurs côté service je suis vraiment déçu, car on ne trouve pas d’infos additionnelles sur le stationnement voiture, vélos, ou sur l’accès poussette / fauteuils roulants qui existe à l’entrée principale (pourtant c’est dans le scope de la PMR).

Conclusion du petit test rapide : les infos présentes sont déjà très utiles. Pourtant elles ne sont pas exhaustives, même sur certains aspects qui paraissaient importants pour le projet (PMR), et le niveau de finesse de l’info peut dépendre des gares.

Faire parler les données

Le calculateur de données, base de « l’assistant personnel de mobilité », c’est une application de l’Open Data dans les transports simple et parlante, que l’on visualise facilement. C’est pourtant loin d’être la seule. Depuis 2005 des collectivités aux US (Portland) ont commencé à ouvrir leurs données de transport (précurseur du format GTFS, développé par la suite avec Google), basiquement les horaires de l’ensemble des transports publics dans un format standard exploitable par des machines. En parallèle s’est développée se sont développés des projets pour exploiter ces données, et les recouper avec d’autres données (géographiques, démographiques, économiques). Objectif : améliorer la prise de décision, la planification et la communication.

Aujourd’hui une entreprise comme Conveyal est capable d’intégrer dans un calculateur les données temps réel des transports publics aux Pays-Bas (tous géolocalisés et en Open Data). Ce projet est financé par le Ministère des Transports.

Il est aussi possible de prédire et de visualiser les effets sur les temps de transport et l’accessibilité de modifications du réseau de transports publics (modification de lignes de bus, ajout de lignes de tramway ou métro).

Analyse de l'impact de Sandy sur les transports à New-York - Andrew Byrd, avec OpenTripPlanner
Analyse de l’impact de Sandy sur les transports à New-York – Andrew Byrd, avec OpenTripPlanner

Il est même possible de rendre compte et d’analyser des évènements disruptifs pour le réseau de transport, comme l’ouragan Sandy à New-York. Les visualisations démontrent comment MidTown Manhattan s’est retrouvé isolé et peu accessible en transports pour l’essentiel de la population, au lendemain de l’ouragan, du fait des tunnels inondés et des transports en commun désorganisés.

Enfin un développeur, Philippe Lacour, a fait une démonstration d’utilisation des données de la SNCF au format GTFS pour visualiser l’ensemble des trains se déplaçant en Ile de France au cours d’une journée. Il a atteint ce résultat avec des outils Open Source déjà disponibles, les données de la SNCF et un traitement des données pour ajouter des informations sur le réseau de voies ferrées. La source se trouve ici.

Un jour en Transilien – Site SNCF Open Data

La donnée géographique, carburant de l’Open Transport

Pas d’Open Transport et ses applications sans données géographiques, c’était le message de Gael Musquet, d’Open Street Map. Avec une problématique réglementaire spécifique à la France : l’accès à la donnée adresse n’est pas ouvert. Il doit donc être reconstitué.

Pourtant cette donnée existe, elle est gérée par le SNA (Service National de l’Adresse), piloté par La Poste et l’IGN. Malheureusement le couple adresse postale / latitude-longitude n’est pas une donnée publique. La principale raison invoquée par le SNA, ce sont des questions de vie privée. Il est indéniable pourtant qu’il y a une problématique d’ouverture des données publiques, surtout à l’heure où des véhicules du type Google Street View parcourent les rues et reconstituent cette information. Le service SNA fournit uniquement des données correspondant aux portions de voies (avec les numéros de voie à chaque extrémité). C’est pour cela qu’il y a une approximation (interpolation par l’outil cartographique) lorsque l’on cherche une adresse précise dans une rue.

Actuellement on peut dire que le SNA participe de la position monopolistique de La Poste sur la distribution du courrier, avec des conséquences pour la société qui vont bien au-delà de l’activité postale malheureusement. Pour mieux comprendre la problématique et ses conséquences, je vous recommande ce très bon article publié par Open Street Map France.

Base Adresse Nationale : À côté de la plaque ?

C’est dans ce contexte qu’Open Street Map cherche à reconstituer l’information sur l’adresse pour la mettre à disposition de tous, c’est le projet BANO (Base d’Adresse Nationale Ouverte). Les fonds cartographiques et de nombreuses données à l’échelle de l’adresse sont actuellement issus des plans du cadastre, qui doivent être retraités puisqu’il s’agit de plans numérisés avec des informations sur chaque parcelle. Les données sur l’adresse sont dans un format souvent abrégé qui nécessite une normalisation et un rapprochement avec les données d’autres sources. Le autres sources sont les données déjà présentes dans Open Street Map et celles ouvertes progressivement en Open Data par des collectivités locales (une douzaine a déjà franchi le pas !) ou les Services Départementaux d’Information et de Secours (SDIS – les pompiers quoi !).

Le projet avance vite, plusieurs caps ont déjà été franchis et de premiers fichiers sont disponibles (plus d’infos ici). Un BANOcamp est organisé le week-end du 28 juin pour ceux que cela intéresse d’approfondir. Ci-dessous la carte d’avancement à date (cliquer dessus pour la version mise à jour en temps réel). Quand c’est rouge, c’est qu’il y a un travail de rapprochement à effectuer entre données du cadastre et données Open Street Map, quand c’est orange, merci aux villes et aux SDIS qui ont ouvert leurs données, quand c’est vert la donnée est dans Open Street Map.

Etat d'avancement du projet BANO Open Street Map
Avancement du projet BANO – Open Street Map

Les présentations se sont conclues sur ce sujet majeur de la donnée adresse ouverte, malheureusement non disponible par les services publics censés la produire pour le bien commun. L’initiative Open Street Map pourrait apporter plus de réactivité, d’ouverture et de flexibilité au projet, à condition qu’ils obtiennent les moyens humains, matériels et financier de le faire. Les collectivités territoriales et les SDIS pourraient bien devenir un contributeur précieux de ce projet.

Advertisements

8 réflexions sur “L’Open Transport, Open Data appliqué à la mobilité

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s