Retour d'expérience transports : itinéraires, fréquences et choix des données
publié le , mis à jourBonjour à la communauté Cartes.app, Je poste ici à la suggestion de @laem, à la recherche de retours d'expérience sur le transport et particulièrement en train.
Nous développons bénévolement un site qui promeut le combo vélo+train pour aller grimper en falaise : velogrimpe.fr (repo). Pour cela, on essaie de trouver des solutions à plusieurs freins:
- Identifier les falaises accéssible à vélo + train et les renseigner (on a choisi une approche contributive pour cela)
- Permettre de choisir facilement une falaise selon les contraintes de chacun (je veux faire plus ou moins de vélo, je pars pour le week end donc un peu de train ne me dérange pas, je veux telles ou telles caractéristiques pour la grimpe...). Pour ça on a une carte interactive et des tableaux filtrables.
- Faciliter la logistique : quel itinéraire de vélo utiliser depuis quelles gares, où garer son vélo, quels trains prendre, à quelle fréquence passent-t-ils ?
Et c'est sur la partie train que le bas blesse, on souhaite renseigner des informations précises telles que la durée, le nombre de correspondances, la fréquence en semaine ou le week end. Et si possible, à jour...
- Initialement, on renseignait tous les itinéraires train à la main : on allait sur un site de réservation qui nous permettait de filtrer les trajets en TER uniquement, et on comptait les trains en semaine et le week end, de manière à renseigner un champ texte sur le site.
- Le nombre d'itinéraires à renseigner a augmenté, d'autant plus qu'on a multiplié les villes de départ (initialement seulement Lyon, on essaie maintenant de couvrir une petite dizaine de grandes villes). Alors on a tenté d'exploiter les données GTFS TER de la SNCF avec des jointures basiques pour calculer la fréquence en agrégeant les données du flux GTFS (3 mois). Pour les directs c'est facile et ça marche bien. Pour les trajets avec une correspondance, ça se complique déjà et on s'est heurté aux difficultés de savoir définir ce qu'est une correspondance acceptable. Plus les problèmes de temps de calculs qui deviennent importants.
- On en est restés là, peu satisfaits du résultat hormis pour les directs. Et en gardant en tête que si on voulait être exact il faudrait mettre à jour ces données manuellement dans le temps.
Entre temps on a vu le travail que vous avez fait sur Cartes.app, les calculs d'itinéraires multi-modaux, etc. C'est ce qui m'amène ici à vous demander quelques retours d'expériences et conseils sur l'approche à adopter.
J'ai déjà exploré un peu les différentes solutions de calcul d'itinéraire que j'ai pu trouver (OTP2, Valhalla, Graphhopper, et découvert Motis via cartes.app), mais j'ai encore du mal à voir ce que ça impliquerait techniquement (et financièrement) d'héberger ce genre de services. Et de plus, j'ai l'impression qu'ils ne couvrent pas vraiment notre besoin de calcul de fréquence.
Donc pour en revenir à ma question : est-ce que certains d'entre vous ont déjà eu à traiter ce genre de problématiques ? Comment avez vous fait / feriez vous ? Quels retours vous feriez de l'utilisation de Motis ? Qu'est-ce que ça implique pour vous de déployer ce service ?
Au plaisir d'échanger avec vous ! Yoann
laem
Salut Yoann ! Merci pour le contexte ! Alors déjà, je t'invite à lire https://codeberg.org/cartes/web/issues/620. Tu verras que l'origine de cartes.app était une idée similaire :)
Héberger Motis n'est pas très compliqué mais ça demande quand même d'être dev avec un peu de connaissance d'Ubuntu / Nginx, et 50 €/mois. Si votre trafic n'est pas trop important, utilisez l'instance serveur.cartes.app/motis2 ou celle de transitous.org.
Là comme ça, j'ai l'impression que le mode "longue vue" (c'est comme ça que je l'appelle, et c'est cet icône dans l'interface de cartes.app) de Motis convient à ton usage car il donne les trajets sur une journée entière, et tu lui mets en entrée les contraintes que tu veux (nb de correspondance, marche accessible entre les correspondances, temps de correspondance, vélo dans le train, etc.).
Par contre, le vélo dans le train dépend des données GTFS de la SNCF et je doute fortement qu'ils jouent le jeu !
Quels retours vous feriez de l'utilisation de Motis ?
Pour dire les choses simplement, je ne vois pas de raisons d'utiliser autre chose ^^ Si ce n'est pour faire des analyses statiques, pas du calcul d'itinéraire, mais tu auras alors justement les problèmes rencontrés : que des trajets simples directs.
On utilise aussi node-GTFS qui est tout un ecosystème. Et qui nous permet d'afficher les tables d'horaires pour un arrêt de bus et générer des plans de réseaux de transport.
Certains outils de la galaxie node-gtfs sont plutôt orientés décideurs je pense, mais ça vaut le coup de creuser. https://github.com/BlinkTagInc/gtfs-to-chart
ycouble
Par contre, le vélo dans le train dépend des données GTFS de la SNCF et je doute fortement qu'ils jouent le jeu !
Oui, il me semble qu'ils n'indiquent rien. On fait généralement le raccourcis que TER = vélo possible, TGV = possible mais très contraignant, même s'il parait qu'avec la LOM ça change (lentement).
Héberger Motis n'est pas très compliqué mais ça demande quand même d'être dev avec un peu de connaissance d'Ubuntu / Nginx, et 50 €/mois. Si votre trafic n'est pas trop important, utilisez l'instance serveur.cartes.app/motis2 ou celle de transitous.org.
Là comme ça, j'ai l'impression que le mode "longue vue" (c'est comme ça que je l'appelle, et c'est cet icône dans l'interface de cartes.app) de Motis convient à ton usage car il donne les trajets sur une journée entière, et tu lui mets en entrée les contraintes que tu veux (nb de correspondance, marche accessible entre les correspondances, temps de correspondance, vélo dans le train, etc.).
Ça me parait une super solution pour démarrer, on n'a pas les ressources nécessaires pour financer ça pour le moment, ni un volume suffisant pour que ça ait un intérêt (on est généralement autour de 25-30 visiteurs uniques / jour, et des pics rares à > 100 visiteurs). Et si on fait du pré-calcul, on veillera à ne pas surcharger le service (idem, volume assez faible pour le moment).
Merci beaucoup pour toutes ces informations, ça fait bien avancer nos réflexions sur ce sujet !
Et si on fait du pré-calcul, on veillera à ne pas surcharger le service (idem, volume assez faible pour le moment).
T'inquiète pas, Motis est un calculateur robuste et le serveur a 60 Go de RAM. Il faut faire plusieurs requêtes par seconde pour le saturer :)