Calculs d'itinéraire de gare à gare
publié le , mis à jourActuellement, quand on lance un calcul de transport en commun entre une ville et une autre, et que l'une de ces villes est dans un territoire dont les transports en commun ne sont pas encore intégrés à noter serveur, ça foire.
Pourtant, le serveur est tout à fait capable de faire le calcul de gare en gare, si Motis reçoit en entrée le stop GTFS exact. Or, on dispose de tout ça grâce aux données GTFS de la SNCF.
Il serait donc possible de faire un système qui remplace A ou B par la grande gare de la ville. Le mieux me semble être d'afficher les gares SNCF sur la carte quand on rentre en mode itinéraire, de façon très imposante quand le zoom est haut, ce qui permet à l'utilisateur de les choisir.
Il faudrait aussi, quand il n'y a pas de transports en commun dans la zone, lui conseiller de partir de la gare. C'est dommage que Motis ne le fasse pas automatiquement, en mode "si tu arrives à rejoindre cette gare à 20 km, y a un trajet" mais je ne crois pas qu'il soit cablé pour ça. Potentiellement, pour traverser la France en TGV, même un trajet d'1h en voiture pour rejoindre la gare est justifiable. C'est là qu'on voit la complexité, et l'intérêt qu'on a à travailler ce sujet pour apporter des solutions nouvelles.
Dans l'interface, on aurait : [si pas de transports trouvés depuis A, tester depuis A-bis qui est la grande gare la plus proche de A].
Ce serait aussi très logique que les gares apparaissent sur le mode itinéraire. Les gares sont incontournables dans ce mode. Que ce soit sur un trajet local où les gares deviennent les plus importants pôles multimodaux, ou sur un trajet région ou national où le passage par les gares est inévitable.
laem L'algo "collant" est assez simple : en fonction du zoom, quand mon curseur est trop proche d'une gare, alors elle s'affiche en relief et le clic la choisit elle, pas l'endroit du curseur. C'est un poil invasif, mais à mon avis pas trop, et le même code peut être réutilisé pour le mode itinéraire par recherche de lieu.
laem Autre idée, le faire de façon plus automatique.
Même si motis me trouve un bus de Auray à Penthièvre, ça restera une contrainte pour le trajet total Rennes - Penthièvre : il ne m montrera pas des trains que je pourrais choper avec un ami qui me dépose à la gare ! Et même s'il montre un résultat full TeC, il est peutetre super mal cadencé. D'où l'intérêt de calculer en parallèle Gare de Rennes - Auray. Dans ce cas là c'est évident pour trouver les gares a et b.
Donc au-delà d'une certaine distance, proposer automatiquement un calcul de gare à gare et l'intégrer à la frise. De plus, sur ces distances le vélo et marche sont inutiles, donc on a de la place.
C'est pas très compliqué a priori à faire ainsi, on peut en avoir une version rapidement. Et ensuite permettre à l'utilisateur de choisir le mode pour les derniers km.
Par contre le choix des gares n'est pas toujours évident. Si je suis à équidistance de deux gares principales, on fait comment ? C'est là que Motos avec une option "vol d'oiseau jusqu'à la gare" serait intéressante mais est-ce qu'elle existe ? Est-ce qu'il ne faudrait pas faire le calcul avec 1h de voiture mais ne pas montrer la voiture ? Ainsi Motis choisirait la gare la plus intéressante ? Mais risque aussi de proposer des trajets full voiture, donc le paramètre serait à régler pour faire max 1/3 par exemple de la distance en caisse. Même pb si gare proche pas bien cadencée contre gare cadencée à 10km en plus. Motos est sensé gérer ça. Ça vaut le coup d'essayer donc un calcul supplémentaire avec caisse de x heures comme premier segment.
Le train est sensé aller plus vite que la bagnole, donc ça ne devrait que favoriser une part plus importante de trajet en train, sauf que la bagnole permet de rattraper un train plus loin ! Dans ce cas le vélo peut être une bonne option qui maximise, reste à voir si 2h de vélo comme option c'est possible.
laem Il faut que je me replonge dans la doc de motis.
Ici https://motis-project.de/docs/features/routing.html
Est-ce qu'on utilise bien le mode "pretrip" ? Faut-il utilise le mode intermodal routing ou timetable routing ? Edit : non, timetable (ou station to station) ne résout pas notre problème ici.
laem OK j'ai fait marcher OSRM dans motis, c'est cool. On couvre maintenant tout le grand ouest, Bretagne PddL Normandie en termes de osm.pbf.
En effet, comme prévu, la voiture est plus rapide que nombre de bus donc ça créée des trajets 100% voiture, voir que les trains en ville donc ça fait prendre la voiture jusqu'une gare secondaire plutôt que la principale !
En vélo donc, ça semble mieux.
laem Note : peut-être qu'avec PPR mais en version duration_limit = très longue ça aurait marché aussi bien !
En tout cas, le bike à 1h permet d'aller de 6T09h00&choix=1&allez=Point+sur+la+carte%7C%7C2.3504%7C48.8393-%3EPoint+sur+la+carte%7C%7C6.0677%7C46.4918#6.94/46.32/4.993">Paris aux Rousses en cliquant approximativement sur la carte.
Ou encore un trajet TER local et un autre avec correspondance.
Ou un trajet
Par contre, il me sort des dingueries sur un Paris - Troyes.
laem - faire marcher le calcul via le module osrm vélo
- résoudre le pb de la date
- corriger les textes "march" par exemple 68-%3EPoint+sur+la+carte%7C%7C3.5280%7C46.9182&mode=commun&choix=4#6.02/45.813/3.98">ici
- inspecter les trajets erronés qui passent par des coordonnées nulles ?
- gérer l'affichage : par défaut, c'est vélo / voiture / taxi, afficher au survol / clic futur les infos de temps
- plus tard, avec une interaction, décliner le trajet précis sur la carte
laem Bon, l'implémentation mise en ligne pose un problème : si le bus est plus lent que le vélo, il ne sera pas proposé. Je pensais pas que ça arriverait mais évidemment que si. Voir 14.12/48.39032/-4.52174">ce trajet.
Bien sûr, le vélo est évidemment plus efficace que le bus. Mais de nombreuses personnes vont préférer y aller en bus. C'est plutôt une bonne liaison. Elle est lente, mais elle permet de s'y poser. Et puis si on n'a pas de vélo, ça évite 20 minutes de marche.
Autre exemple sur un trajet similaire : Motis va faire faire une partie du trajet en vélo alors que le bus permet presque de faire du porte à porte.
Finalement, à terme je pense qu'il faudra faire deux appels à Motis. L'un qui demande des transports en commun en mode "flemmard" qui maximise la distance en TeC, et un autre qui ajoute le vélo dans l'équation.
En attendant, je teste une ruse : si le trajet est inférieur à une certaine distance, aucune raison de suggérer le vélo : il y a un onglet pour ça. Le combo vélo + transport ne devient intéressant que pour un trajet de plus de 5 km par exemple. Ça pourrait résoudre notre souci :)
Autre solution : une deuxième requête automatique avec plus de vélo, ou alors une requête au clic après un premier résultats "rien pour le mode marche + TeC" : exemple trajet dans Rennes. En miroir, si on trouve un trajet en vélo + transport, alors laisser une option "porte à porte" : exemple cette requête.
D'après mes tests sur Bretagne + IdF + train, les 60 minutes de vélo ajoutent une grande complexité de calcul, donc des temps jusqu'à 30 secondes, quand le réseau de transport à destination est dense : Paris. Or, c'est sûrement l'endroit où le vélo, qui nous sert à simuler un trajet multimodal vers la gare, est le plus inutile. Alors que pour 15 minutes de vélo, c'est très rapide, comme la marche, qui devient alors négligeable dans le calcul final. À l'inverse dans un endroit peu dense, comme la pointe du raz, demander 1h de vélo voir plus ne pose aucun problème, la combinatoire étant très faible.
Ainsi on pourrait :
- commencer avec un mode marche et calculer le vélo par la suite / en parallèle
- se renseigner sur la densité des modes à destination et ainsi ne pas appeler au mode vélo long si réseau dense.
Après quelques réflexions cependant, peut-être qu'il suffit de tester si la destination est proche de Paris. C'est vraiment Paris, peut-être 10 x plus denses en transport que la métropole moyenne, qui fait exploser le temps de calcul. Ça se teste très facilement et ça pourrait nous faire notre v1 :)
Marseille semble tendu aussi ! Ce qu'on peut tester aussi, c'est de diminuer le temps de marche dans les réseaux denses. Il me trouve des résultats finissants par 19 minutes de marche alors que je lui en ai demandé 5, je pige pas pourquoi...
dolmen J'ai testé sur un itinéraire Sainte-Marguerite-d'Elle à Saint-Cyr-l'École. Ça trouve bien le TER Lison-Paris. Mais il semble encore manquer l'application du routage pour remplacer les trajets vélo des extrémités de façon à obtenir le trajet Paris-St-Cyr (mais c'est peut-être qu'il manque les données nécessaires au routage en Île-de-France, et je comprends bien que c'est une autre échelle de complexité et de besoin de ressources de calcul et stockage).
laem L'IdF arrive bientôt :)