Using public transport in Nepal

Multimodal transportation, as known in occident, is the combination of various long distance modes of transport such as rail, bus, aero planes as well as short distance modes as taxis, bike sharing system or scooter. In Nepal you can also combine rickshaws, tempos, motor cycles in the same way as bicycles.

Choice of different modes of transport to be used from origin to final destination largely depends on the geographical situation, the infra-structure for the transport as well as the zonal practice of different modes in a country. Nepal is a land locked country lying between two giant countries: India and china. Transportation between China and Nepal is a very hazardous task because most of the border lies in the mountainous region and construction of transport infra-structure is very costly and difficult.

Freight containers used for international transport essentially use ship, train, and truck from and till India. The only means in Nepal is the Trucks. Once the container arrives at destination, products are then distributed towards many commercial actors using mini-trucks, jeeps as well as rickshaws.

Public multimodal transportation system is an integrated approach of different modes of transport, with the use of their efficient use from an origin to a destination in the urban as well as rural region of a country. Multiple government as well as private agencies should work together in harmony for efficient use of available transport resources. Being a land locked country most of the modes of transport are for road users.

A rickshaw in Kathmandu valley

800px-Rickshaw-katm-nepal

In Nepal public transport can be distinguished in two categories: urban and metropolitan transport. Citizens living in big cities can use different combination of modes as bus, mini-bus, micro-bus, tempos (three wheeled motored vehicle), motor cycles, rickshaws (tri-cycle) as well as bi-cycles for their daily use saving time and money. Most actors of transport are independent and there is little harmony among them. To insure a better utility and availability there has to be efficient connections among different modes of transport. Each mode has its own fixed routes and schedules but they rarely leave on time until full of passengers. Usually the modes of transport are crowded and without comfort. Rental cars with driver or taxis can be used as a comfortable means but remains very costly. Since there is no underground transport in the country, daily mobility of citizens brings a very congested traffic during peak hours. Information of transport modes, their routes as well as schedules is almost non-existent and each passenger will have to get the necessary information from each actor of transport personally.

Some micro-bus in Kathmandu valley

Transport_Kathmandu_2013

Long distance bus services are better organized and have more or less fixed courses and schedules. Bus services cover most of the road-accessible destinations. They are slow uncomfortable and often stop frequently to take short distance passengers as well as live stocks and vegetables. Tourist buses are another option to the public buses and are much more comfortable despite the elevated cost. Rental cars, taxis can also be used for greater distance.

Roads are very vulnerable to users as most of the roads are in the mountainous region. Flying is relatively safe. Many airline companies operate in the country. Availability of flights depends on the weather conditions. The flight has to be booked in advance. To visit remote areas chartered helicopters can also be used. The possibility of landing safely in a small space makes them very useful for an emergency transport. They are also widely used for sightseeing in the Himalayas and to have a close look of Mount Everest.

A long range public bus

Bus,_Nepal_(10678458684)

A long distance public bus

800px-Sajha_Yatayat

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.