• [^] # Re: Multimodal et autres questions

    Posté par . En réponse à la dépêche Libération de navitia : un calculateur d’itinéraire pour les transports en communs. Évalué à 9.

    • Le principe c’est de trouver les N arrêts accessible en 15 minutes de vélo/marche/vls selon le mode choisi et les M arrêts à l’arrivée, c’est la partie Dijkstra. Ensuite entre ces ×ばつM couples d’arrêts, on cherche les itinéraires en transports en commun. Est-ce que c’est multimodal ça ? Je ne me prononcerai pas, les avis virent vite au troll sur cette question là ;)
    • Oui, le calcul est bien à l’horaire exact (avec des temps de battements et de correspondance configurable). L’algorithme Raptor a un graphe implicite où chaque arc correspond au trajet entre deux arrêts d’un véhicule. Il n’y a donc pas de graphe au sens « plan de métro ». Si tu veux plus d’informations sur la représentation des horaires pour le calcul d’itinéraire, je vais faire un peu de mégalo, et t’orienter vers le chapitre 1 de ma thèse http://tel.archives-ouvertes.fr/tel-00553335
    • Flask
    • Oh ! Question tricky. Voici mon interprétation : il n’y a pas d’agrégation des base OSM et GTFS et il n’y a pas de rediffusion. Lors de la restitution de l’itinéraire avec le tracé piéton et TC, la quantité de données exposée n’est pas « substantial » http://wiki.openstreetmap.org/wiki/Open_Data_License/Substantial_-_Guideline Par contre, il y a bien de l’agrégation des données GTFS de plusieurs transporteurs (sinon ça peut pas marcher). Par exemple RATP+SNCF. Dans ce cas, Canal TP rediffuse (pour l’instant de manière très amateur, mais ils m’ont promis de s’améliorer sur le process) sur http://data.navitia.io
    • Effectivement OSRM est uniquement routier. Les problématiques sont assez différentes dès qu’il y a des notions d’horaires

    J’espère pas dire trop de conneries (je ne travaille plus chez Canal TP depuis un an, mais j’ai suivi cette ouverture puisque ça me tenait à cœur).