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.

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:

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 référencer 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…)

Qualité des données OpenData RATP

Ce petit billet à l’attention des ré-utilisateurs de l’API http://navitia.io et des consommateurs des données RATP de http://data.ratp.fr

Vous avez dû constater que les données de Paris proposées par l’API n’étaient ni stables, ni de qualité. Nous essayons de redresser les données proposées par la RATP sur leur serveur d’openData, mais certains cas sont difficilement gérables:

  • le jeu de donnée actuellement à disposition ne décrit pas la majorité des calendriers de ce début d’année 2014. Du coup le métro est fourni comme ne circulant pratiquement pas. Nous avons donc dû prendre une semaine type de l’année dernière sur le jeu de données précédent et ré-appliquer les horaires sur 2014. On comprend bien que du coup, la qualité globale n’est pas satisfaisante.
  • Les correspondances fournies ne semblent pas être celles utilisées par le site ratp.fr : on trouve par exemple une correspondance de 2 minutes entre les stations de metro Montrouge et St Jacques par exemple. (ligne « 3442548,3449469,2,69″ du fichier transferts.txt). Erratum sur ce cas, autant prendre un exemple avéré ! 2 minutes entre la station des Abbesses et le Funiculaire de Montmartre. Du coup, on a préféré faire un calcul de correspondance basé sur les coordonnées pour le moment et ne pas tenir compte du fichier transfert. Pareil : pas très qualitatif tout ça.
  • Nous avons fréquemment des lignes de bus qui ne circulent plus et pour lesquelles nous devons attendre des mises à jours de données. Mais la fréquence de mise à jour des exports est encore très faible.

Quelqu’un d’autre constate-il les mêmes problèmes ? Comment les contournez-vous ? Et surtout : quelqu’un a-t-il déjà obtenu des réponses depuis la page de contact de http://data.ratp.fr ?

Je continue le débat, ouvert par turblog, mais j’aimerais que les contributeurs du premier article du labs qui abordait ce sujet puissent me donner leur avis après 6 mois de recul.

 

Interopérabilité des systèmes d’informations

Je profite de la mise à disposition par Canal TP d’un calculateur d’itinéraire transfrontalier sur le site www.simplicim-lorraine.eu pour me fendre d’un petit billet sur l’état des lieux de ce genre de service (jolie phrase :) ) .

Tout d’abord, le service sus-cité permet de calculer des itinéraires depuis la région Lorraine vers l’ensemble des régions participant au projet Européen EU-Spirit. On peut partir de n’importe quelle adresse dans la région Lorraine pour rejoindre n’importe quelle adresse en Suède par exemple.

Démonstration: le calculateur de la région Lorraine est ici: www.simplicim-lorraine.eu/Itineraires-Europe/Recherche, Et voici un exemple d’itinéraire.

On peut constater que, pour le moment, c’est un peu lent, que les itinéraires ne sont pas toujours optimaux, bref que c’est en « béta ». Mais pourquoi est-ce si compliqué de faire dialoguer des systèmes de calcul d’itinéraire existant et de s’affranchir des frontières?

Contexte

Tout d’abord le système EU-spirit utilisé est basé sur l’échange de service et non l’échange de données. C’est un système réparti, un peu comme une encyclopédie en plusieurs volume dont chaque volume est comparable dans notre article à une région EU-Spirit.

Chacun des acteurs (chacune des régions, donc) n’a connaissance que de ses propres données horaires et de l’organisation de ses propres données sans contexte global.

C’est très important, et c’est la différence avec une encyclopédie.

En effet, dans une encyclopédie, la répartition des articles est alphabétique, un tri choisi en toute connaissance de la totalité des articles. Si tous les articles ne parlaient que de géopolitique, le tri aurait été différent: géographique ou historique, par exemple, mais toujours par rapport à un contexte global. A contrario, dans une bibliothèque, l’organisation ne peut se faire de façon globale: les livres n’ont pas été écrit les uns par rapport aux autres. Mais c’est là qu’est l’hic: qui sait retrouver facilement un livre dans une bibliothèque? ;-)

 

Donc la répartition des horaires dans un méta-système n’est pas algorithmique. Les horaires sont répartis dans les différentes systèmes d’information locaux selon les transporteurs, les règles politiques de subvention… On trouve le système de la région Lorraine, celui de la région Alsace, opéré par Cityway, celui de la SNCF, celui de citroën!

Attention à bien noter que je n’aborde pas ici le sujet d’un calculateur d’itinéraire qui reposerait sur des données consolidées et qui serait composé de plusieurs noeuds (cluster) de calcul afin d’optimiser les performances. Une répartition des horaires dans des clusters faite en toute connaissance de l’ensemble des horaires et en fonction de l’algorithme de recherche global est une implémentation de calculateur d’itinéraire consolidé sur une architecture technique répartie.

Le calculateur réparti n’est, quant à lui, pas du tout comparable à un cluster technique à cause de cette répartition erratique des données et de l’hétérogénéité des algorithmes de chacune des régions.

Fonctionnement

Le système réparti EU-Spirit est donc composé d’un système central et des sous-systèmes régionaux. Dans le cas d’EU-Spirit, le système central  découpe chaque demande d’internaute en 3 sous-demandes: région de départ, calculateur « longue distance » de la DB, région de destination.

Le système central répertorie également l’ensemble des points de correspondances inter-système. Sans la connaissance complète des horaires de chacune des régions, j’insiste, cette répartition est forcément empirique, et les résultats ne sont pas toujours optimaux. Il est néanmoins possible d’améliorer les résultats en administrant manuellement les données de correspondance sur le système central. Ainsi, les itinéraires proposés sur simplicim seront de plus en plus satisfaisant au fil du temps, mais il restera toujours des résultats non-optimaux.

Si vous voulez savoir très exactement comment ça marche, de la doc est disponible sur le site d’EU-spirit. Le projet utilise une version simplifiée de l’algorithme de delfi.

Mais du coup, quel est l’intérêt d’un calculateur d’itinéraire réparti par rapport à un calculateur consolidé contenant l’ensemble des données? Ce sujet fera l’objet d’un billet à venir très bientôt!!

Conclusion

Les intentions des régions Lorraine et Alsace avec EU-Spirit sont louables: au final ce type de service est attendu par les voyageurs. Des acteurs comme Mappy le proposent au niveau mondial depuis des années pour les itinéraires en véhicules personnels.

L’AFIMB a bien compris qu’il fallait bousculer les acteurs et accélérer la mise en œuvre d’un système à l’échelon national. L’un des objectifs est d’améliorer la qualité des itinéraires transfrontaliers dans les méta-systèmes. Cityway et Canal TP travaillent en partenariat dans ce cadre pour proposer des axes d’améliorations algorithmique. L’idée étant de proposer des itinéraires plus qualitatifs que ceux issus d’EU-Spirit.