laem
commented
3 years ago Dans un 1er temps, ne peut-on pas considérer que l'utilisateur part de chez lui, donc qu'il connaît la gare de départ, ce qui enlève une grosse étape algorithmique ? A Paris, en général on sait à peu près quelle gare emmène où. Dans les plus petites villes il n'y a souvent qu'une gare principale et 1 ou 2 gares secondaires.
Il y a bien sûr le risque que l'utilisateur se plante et qu'il faille utiliser une autre gare (genre à Paris, penser que c'est Lyon mais c'est Bercy). Ou qu'il y ait une gare à genre 20km qui fasse mieux l'affaire. Ou que l'outil ne serve qu'aux urbains, mais ce serait déjà pas mal s'il leur était utile pour une 1ère étape.
Donc :
1)
Je saisis mon départ et mon arrivée, on géocode. On propose un bouton "trouver ma gare de départ" qui donne une liste des gares à proximité du départ. L'afficher en haut : "🚉 = Paris Lyon", qu'on nomme GA. Proposer un trajet vélo vers cette gare, ou même ne pas le faire dans un premier temps, c'est pas le plus important.
2) Je saisis les distances min et max de mon trajet vélo à l'arrivée. Peut-être le faire en heures ?
On calcule une liste de gares acceptables. On trouve des trajets réels entre l'unique gare de départ et la dizaine de candidates de fin, via navitia. Pour chacune des gares GBn pour lesquelles il y a des trains GA->GBn tous les jours (dans un premier temps on ne demande pas la date du voyage), analyser les trajets vélo de fin et proposer les solutions candidates GBn + fréquence demain + distance vélo GBn -> B.
J'ai listé dans ce document des voyages de test et leur saisie sans l'API Navitia SNCF avec rabattement vélo.
https://hackmd.io/Hp98YYc_Rjqu7M2AJCYbOw
Je note une chose importante : l'API semble faire l'affaire (avec quelques patch mais largement faisables) pour des trajets où le train fait le maximum de distance. C'est déjà bien, mais après réflexion j'ai l'impression que la valeur ajoutée de ce site est en grande partie ailleurs, dans la proposition de trajets où le vélo a toute son importance.