Cartoviz : Retour d’expérience sur l’utilisation de données opendata

En mars dernier, avec quelques uns de mes collègues de Canal TP, nous nous sommes portés volontaires pour pic-niquer devant nos PC le midi pendant un mois afin de relever le défi de @AgentNum lancé à l’occasion du concours Cartoviz.

C’est ainsi qu’est né KartoKartier, un outil, à destination des collectivités, pour préparer et imprimer des plans de quartiers à afficher sur des abribus, à partir de données opendata de diverses sources.

Cet article ne parlera pas vraiment de l’outil Kartokartier, mais est plutôt un retour d’expérience sur l’utilisation des jeux de données de ces différentes sources que nous avons utilisées pour fabriquer l’outil (mais si vous voulez tester KartoKartier, c’est ici : kartokartier.com, login kartokartier@canaltp.fr, mot de passe KartoCanal).

Nous souhaitions, dans un premier temps, visualiser tous les abribus où un plan devait être imprimé et affiché. Nous nous sommes donc concentrés sur les données abribus.

Sans trop réfléchir, nous sommes initialement partis sur les données RATP.

Mais assez rapidement, nous nous sommes rendus compte qu’il y avait un souci : la notion d’abribus (qui nous intéressait pour le projet) est différente de la notion d’arrêt de bus de la RATP. En effet, il peut y avoir des arrêt de bus qui ne sont pas des abribus (et il y en a plein), et des abribus qui ne sont pas desservis par des bus RATP.

En réalité, les abribus n’appartiennent pas à la RATP : ils ne sont donc pas la source idéale pour cet usage.

Qui gère ces abribus alors ?

Eh bien, c’est la ville de Paris !

Bon sang mais c’est bien sûr, on aurait dû commencer par là …

Bref, nous sommes donc repartis sur le jeu de données du mobilier urbain de transport de la ville de Paris.

 

On a été un peu dépaysés, car on pouvait retrouver alors les différents modèles d’abribus (avec une excellente géolocalisation), mais on perdait le nom de l’arrêt de bus, qui est une information qui nous semblait pertinente : on préfère dire l’abribus du Centre Georges Pompidou (même s’il n’est pas unique) que l’abri autobus Télécom grand modèle situé aux coordonnées 48,8610207 et 2,3497198…

On a donc entrepris de faire un rapprochement entre les abribus (données villes de Paris) et les arrêts de bus (données RATP, via l’API navitia.io)

Là, malheureusement, nous nous sommes heurtés à un autre souci : celui de la précision de la géolocalisation des données, dans les deux jeux.

Autant dans le jeu de données de la ville, c’est ok, autant dans le jeu RATP, c’est plutôt approximatif … on trouvait parfois l’arrêt de bus le plus proche d’un abribus à plus de 60 mètres …

 

Ne pouvant faire mieux, nous avons continué quelques temps avec cette solution …

Jusqu’aux premiers tests un peu approfondis, où nous nous sommes rendus compte que le jeu de données de la ville de Paris n’était pas à jour : on y trouvait encore, par exemple, des arrêts de bus qui servaient exclusivement à la ligne PC2, qui n’existe plus depuis la mise en circulation du tramway T3, fin 2012.

Là, c’est le drame : on construit un service sur un jeu de données périmées et qu’on complète avec des données approximatives. Difficile d’espérer construire un système qualitatif !

Puis, on a eu une illumination : on a voulu savoir ce que pensait OpenStreetMap, qu’on utilisait déjà par ailleurs dans l’appli comme source de données et comme fond de carte, de cette histoire d’abribus à Paris.

Et on a été impressionnés : on trouvait des arrêts où les contributeurs avaient fait la correspondance entre les deux jeux de données :

  • Ils étaient bien géolocalisés (à partir des données opendata Paris ou de la connaissance locale du terrain des contributeurs)
  • Ils avaient le nom de l’arrêt de bus RATP associé (à partir des données opendata RATP)
  • Ils avaient (souvent) le modèle d’abribus (à partir des données opendata Paris)
  • Et ils semblaient à jour (on ne retrouvait plus nos arrêts périmés de PC2)

Que du bonheur, on oublie l’opendata pas à jour et on migre vers OpenStreetMap !

Et puis comme ça marche si bien, poussons le délire jusqu’au bout : et si on récupérait les informations sur les bus qui passent à ces arrêts à partir d’OSM plutôt que l’opendata RATP (via navitia.io)

Mais ce fut une déception, la qualité est alors très inégale : on trouve des arrêts extrêmement complets, avec toutes les infos nécessaires bien cartographiés, et à l’inverse des arrêts où même le nom n’est pas renseigné.

 

Bref, au final, nous voulions faire deux choses :

  • Avoir la liste des abribus de la ville de Paris, avec des infos minimales (nom et modèle d’abri)
  • Avoir, pour chaque abribus, les lignes qui y passent

Et malgré le foisonnement des jeux de données disponible en opendata (ben oui, trois, c’est déjà énorme !), nous n’avons pas réussi à en trouver un qui soit suffisamment complet pour remplir ces missions … Et le manque de qualité (fraîcheur pour l’un et précision pour l’autre) a rendu difficile le croisement de ces jeux directement dans notre application.

Alors que faut-il penser de tout ça ?

Les initiatives autour de l’opendata (le concours Cartoviz, les démarches entreprise par la Région Ile-de-France et la ville de Paris à travers leurs plateformes opendata, etc) sont encourageantes et il faut continuer dans ce sens : nous avons à gagner à apprendre une nouvelle manière de travailler, et à co-construire des services publics entre collectivités, entreprises, étudiants, chercheurs, citoyens, etc

Mais beaucoup reste à faire pour avoir de la donnée de qualité et des mises à jour pertinentes et régulières.

Peut-être manque-t-on d’outils pour effectuer plus facilement les croisements et permettre aux différentes sources d’opendata de grandir en se complétant mutuellement ?

[EDIT : mon humble contribution à ce problème, un script d'intégration des noms des arrêts de bus RATP dans OSM, à partir de navitia.io]

Et peut-être que le prochain défi pour les collectivités sera de faire vraiment le choix d’OSM, tout en encourageant la contribution citoyenne et pourquoi pas en motivant leurs personnels à devenir eux-même des contributeurs OSM ?

Navitia 2 est OpenSource !

Ca y est ! Après un an de préparation, une ré-écriture complète du système (changement de technologies, d’algorithmes, de services…), 5623 cafés et un lobbying de malade, Canal TP a enfin sauté le pas. La nouvelle version de son calculateur a été conçue et écrite pour être OpenSourcé et dont acte !

https://github.com/CanalTP/navitia. Tada !

Du coup, ça signifie quoi ? Que vous pouvez nous aider à améliorer navitia 2. Ajouter de nouvelles fonctionnalités, améliorer les existantes, corriger les anos. Nous avons mis un an à gérer les « boring stuff » qu’il fallait reconduire depuis la version 1. En effet, la première version de navitia a plus de 10 ans, elle est capable de gérer des problématiques hyper-fines: Transport à la demande, passe-minuit, ITL, comparaison d’itinéraire, fiche horaire de lignes en boucle… ces milliers de micro-points qui font que navitia 1 est aujourd’hui le système d’information le plus utilisé en France: plus de 7 milliards de requêtes par an, dont 200 millions de calculs d’itinéraires, sur Lyon, Lille, Paris, Bordeaux…

Vous n’avez plus qu’à inventer avec nous les « cool stuff » à venir!

Bref vous approprier l’application.

So what’s next?

And the winner for the first external pull-request is… https://github.com/skywave : thanks & welcome into the project !

Grâce à lui, navitia compile aussi sur Ubuntu 14.04 en plus de Debian. Nous verrons par la suite quelles autres distributions seront supportées.

En plus de çà, on aimerait simplifier l’installation de navitia, renforcer et porter en anglais sa documentation.

On a plein d’idées dans le pipe, et quelques dévs déjà lancés : itinéraires inter-régionaux, amélioration de la gestion du temps réel, fiches horaires par période (et non plus par jour), dessin des lignes (shapes KML), statistiques évoluées… N’hésitez pas à en proposer d’autres ou à contribuer aux évolutions.

Et navitia.io ?

En même temps que nous ajustons ces aspects techniques, les projecteurs de l’actualité printanière s’orienteront vers l’API elle-même: https://api.navitia.io. La nouvelle infra est montée, nous allons donc migrer le service pour augmenter la pawa !

Ce qui nous permettra également d’ajouter plus facilement et de mettre à jour plus régulièrement les données. On a repéré beaucoup d’attentes là-dessus ! Attention, au passage, on rendra l’authentification obligatoire, ce qui ne changera pas grand chose pour les ré-utilisateurs, mais nous permettra d’améliorer la qualité des données et la répartition de la puissance sur l’infra.

Pour résumer

Vous allez nous aider à faire passer les voyageurs du « mass transit » à la « responsive locomotion » : nous allons transformer navitia en phénomène de société !

Détour du côté de CityMapper

Retour sur une application mobile de Transport Public qui a récemment buzzé et que j’ai testée sur Paris. Verdict…

CityMapper

Continue reading Détour du côté de CityMapper

Interopérabilité des systèmes d’informations 2

Cet article est la suite de http://labs.canaltp.fr/2013/10/interoperabilite-des-systemes-dinformations:

Itinéraire porte à porte: pourquoi choisir un système réparti ?

Nous avons précédemment présenté le principe d’interopérabilité des systèmes de calcul d’itinéraire.

Nous avons également abordé la raison pour laquelle les systèmes répartis ne peuvent en théorie pas trouver la meilleure solution à une recherche d’itinéraire.

Du coup, voici un petit comparatif des 2 méthodes : agrégation de données dans un service central consolidé ou agrégation de service dans un système réparti. Celui-ci va nous aider à comprendre la raison qui pousse Canal TP et Cityway à engager de la R&D sur un nouveau protocole, dans le cadre d’un projet de recherche commun subventionné par l’AFIMB.

Tout d’abord, il faut rappeler que les systèmes d’information voyageurs, les calculateurs d’itinéraires multimodaux, sont mis en place:

  • soit par des transporteurs (par exemple www.tcl.fr à Lyon)
  • soit par les collectivités locales : régions, département, commune, etc. (par exemple www.destineo.fr ou www.vianavigo.com)

On appellera ces calculateurs des SIM (Système d’Information Multimodal). Je passe volontairement sous silence les entités autonomes « non concernées par l’article » (http://www.mappy.com, http://www.multicity.citroen.fr, http://maps.google.com, etc.)

Quelques points de comparaison

Protocole d’échange

Ce point est le plus simple à identifier : afin de présenter des itinéraires de porte à porte entre 2 adresses situées dans des régions distinctes, 2 SIM doivent soit s’échanger mutuellement leurs données, soit offrir une interface compatible.

L’échange de données parait de prime abord plus contraignant que l’échange de service. En réalité le travail d’intégration des données d’une région dans une autre est simplifié par le fait que les données fournies sont globalement « propres » puisque déjà utilisées dans le SIM d’origine.

Par ailleurs les limitations des algorithmes de systèmes répartis nécessitent une administration fine des métadonnées. Ce qui induit des échanges fastidieux entre les acteurs : répartitions/fusion des lignes présentes en double (ou coupées comme le RER A) dans chacun des calculateurs régionaux, activation de points de correspondance manuels, le tout en faisant intervenir plusieurs acteurs et donc avec des lourdeurs de gestion de projet…

Ce tweet d’Herr Doktor Tristram en réponses aux annonces de Frédéric Cuvillier résume parfaitement la vision « hacker » de la chose: https://twitter.com/tristramg/status/433264080477233152

Bref, jusque là pour avoir essayer les 2, c’est plutôt kif-kif…

Qualité des réponses et performances

Je ne vais pas m’étendre sur le fait qu’intrinsèquement, seule la méthode par système consolidé permet d’obtenir l’ensemble des solutions optimales. Quant aux performances de calcul, les calculateurs consolidés sont forcément plus performants, n’étant pas contraints algorithmiquement, et n’ayant pas de latences réseaux. Pour ces points, malheureusement, il n’y aura pas de miracle : le système réparti que nous étudions, comme les existants, va rester un peu lent comparé à un service « all inclusive » comme vianavigo.

Souplesse des services à disposition

Les systèmes répartis existants ne proposent que le service de calcul d’itinéraires. A contrario, sur les systèmes d’information standards, reposant sur une base de données horaire complète, une multitude d’autres services peuvent être imaginés : fiche horaire de ligne, prochains passages, navigation dans le référentiel, mais aussi et surtout analyse de l’offre inter-transporteur. Ce dernier point est identifié comme un axe d’aide à l’amélioration de l’offre de transport, en particulier autour des points de correspondances. Il est temps en effet de révéler les « trous d’offre » qui se produisent régulièrement les dimanches ou en soirée ! Et pourtant ce service est difficilement implémentable sans base consolidée.

Maîtrise des itinéraires présentés

J’ai abordé ce point dans ce billet. Ce qui intéresse les collectivités locales, c’est la possibilité de contrôler les itinéraires sur leur territoire. Ainsi, les nouveaux calculateurs d’itinéraires s’orientent vers des solutions plus naturelles qu’auparavant : itinéraire confortable, itinéraire sportif, touristique, etc. Et les régions, qui organisent les transports, souhaitent chacune mettre leurs spécificités en avant, comme une marque de fabrique.

Cependant, ces nouveaux types d’itinéraires reposant sur des algorithmes personnalisés, ne suivent aucune norme. Ils ne suivent pas de cohérence entre deux régions, même très proches. Ainsi les régions Bretagne et Pays de la Loire, frontalières, présentent leur offre sous des formats très différents. Le site Destineo, des Pays de la Loire, propose un minimum de paramètre à l’internaute, et présente plusieurs types d’itinéraire différents. L’internaute fait son choix a posteriori. A contrario, le site BreizhGo propose plus de paramètres, mais les réponses ne s’écartent pas de la demande. Comment un système réparti pourrait-il réconcilier ces deux méthodes de présentation de l’offre de transport ? Forcément les itinéraires présentés entre les SIM locaux et ceux du meta-système seront différents.

Mais alors… pourquoi est-ce intéressant ?

Tout simplement pour répondre au problème récurrent de maîtrise des données. Si l’échange et l’intégration d’un jeu de données tiers dans un système n’est pas complexe techniquement, les acteurs rechignent toujours à fournir l’intégralité de leurs horaires. Le système réparti permet donc de simplifier les accords de réciprocité entre les collectivités locale ou nationale (grandes lignes, région, département, communes, etc.) puisque l’on maîtrise le périmètre d’utilisation des données.

Personnellement, j’y vois un autre intérêt : une concurrence plus forte et plus saine entre les différents calculateurs d’itinéraires. En effet, le maillage des SIM référencés par un système réparti est constitué de plusieurs types de calculateurs hétérogènes. Par conséquent, statistiquement, plus d’acteurs peuvent pénétrer les marchés de calculateur sous-jacent. On peut donc mettre en concurrence des calculateurs qui couvrent la même zone géographique. On permet également aux collectivités locales de travailler en collaboration avec leur propres universités ou PME dans le cadre de projets qui peuvent s’inscrire directement dans un système réparti.

Conclusion

Parallèlement, l’ouverture des données permet de déclencher des initiatives alternatives comme www.navitia.io, qui sont moins contraintes, puisque reposant sur la maîtrise de l’ensemble des données manipulées. Les services proposés seront forcément plus nombreux, plus créatifs, mais ne pourront pas combler le besoin d’interconnexion entre les systèmes si l’on souhaite adresser les itinéraires internationaux ou les acteurs qui conservent l’exclusivité de leur données.

 

Quelques liens: comment faire une belle API – DevEx

Ce billet permet surtout de rassembler sur une page ce qui s’écrit de plus intéressant pour designer au mieux une API.

Pour mémoire, une « belle » API permettra réutilisation simple par tout un chacun sans besoin de formation ou de connaissance métier. Mouais, en fait toutes les raisons sont mieux détaillées là http://pekelman.com/presentations/apidays

Architecture et Hateoas

De toute façon, une « belle » API est une API Hateoas, donc on va axer notre billet sur cette architcture. Et pour éviter de ré-écrire une nouvelle fois ce que moult évangélistes ont fait avec brio, je vous propose des liens.

On commence par la bible, hein, tant qu’à faire, autant se coltiner les articles imbuvables en premier!

Les plus accessibles:

http://jeremybarthe.com/slides/humantalks-hateoas > présentation assez simple en français :)

http://www.amundsen.com/blog/archives/1149 > Focus sur la définition de l’Hypermedia, concept utilisé entre autre par Hateoas.

https://github.com/interagent/http-api-design > Pleins de trucs et astuces qui ont le mérite de vous présenter la philosophie

Et sinon, un super exemple d’API hateoas: http://developer.marvel.com/docs. La classe.

Vous êtes paumés et rêvez qu’on vous aide à designer l’API qui permettra à votre service de se démarquer ? Rapprocher-vous de http://constellationmatrix.com <3

Versionning

http://blog.mikepearce.net/2010/08/26/why-do-i-even-care-what-version-your-api-is-versioning-your-api-with-hateoas > J’aime beaucoup la démarche, même si dans les faits, on devient exigeant vis-à-vis de l’intégrateur et c’est donc difficilement applicable.

http://barelyenough.org/blog/2008/05/versioning-rest-web-services

Testing d’API et documentation

http://swagger.wordnik.com > on ne présente plus cet outil de documentation d’API assez génial, cependant le support d’Hateoas n’est pas « in the box » pour le moment.

http://tools.ietf.org/html/draft-nottingham-json-home-02 > pas utilisé, mais ça semble beaucoup plus adapté à la documentation d’API Hateoas.

Et pleins d’outils à intégrer pour tester et superviser vos services:

  • http://newrelic.com > c’est ça qu’on a mis pour le moment dans navitia.io et c’est pas mal: simple à intégrer, compte freemium suffisant pour valider la santé du service et les extensions sont géniales pour analyser les applis modulaires
  • http://www.runscope.com, mais y’en a plein et je n’ai pas trop de valeur ajouté à vous les lister…

Et le transport public là-dedans ?

C’est le parent pauvre de l’Hateoas. Sauf navitia! Aller, on focus dessus, on est un peu fier du résultat quand même…

Historiquement on s’est rapproché des réutilisateurs pour designer l’API, puis on a vite vu que « Json vs XML » n’était pas le coeur du débat :) Et maintenant que vous avez 2 versions accessibles sur api.navitia.io, vous pouvez constater les intérêts d’une API Hateoas (http://api.navitia.io/v1) vs une API REST simple (http://api.navitia.io/v0)? Heu au passage, on arrête les évolutions sur la v0, on a du mal à l’assumer après avoir fait tout le taf dans la v1…

Quelques exemples (il suffit de s’inscrire pour récupérer un token gratos et l’insérer dans la boite « user » affichée par le navigateur)

En fait, notre plus gros problème se résume à bien configurer notre plateforme pour que les moteurs de google ne nous requêtent pas trop pour indexer tout le référentiel de transport disponible ;)

Et maintenant c’est la consécration du maître https://twitter.com/stifoon/status/408553170076303360 !

Du coup, pour le reste, j’ai glissé quelques liens intéressants, mais pas liés au fabuleux principe qui nous réunit tous en ce jour pluvieux autour ce billet :)

http://www.programmableweb.com/apis/directory/1?apicat=Transportation > présente l’ensemble des API transport référencées. Mais c’est un peu le souk…

https://developer.transportapi.com > la présentation est hyper tendance, mais l’API est un peu old school.

Bref. Hateoas is good. Navitia is Hateoas \o/ (ça fait un peu pub de déo dit comme ça…)