Motis v2

TODO

The algo is giving me good results on "impossible" routes :)

E.g. http://localhost:8080/?allez=Point+sur+la+carte||-3.0752|48.3091->Point+sur+la+carte||-3.6383|48.0343&mode=commun

But the UI fails to explain it to the user because of the steps not appearing on the summary screen.

• make our algorithm work in the summary : should we run it in the background ? Or better, after a click on "search deeper". Looks done but can have bugs
• look for bugs and solve them, trying the UI for a while. this from summary to bike to summary fails.

Also, make the exploration optional from there ?

• message the user permanently if the transit option is bad in terms of speed (lower than walking ; lower than cycling) for distances that do not require trains. How to concile this with our auto-widening ?

• try the algorithm for my particular weekend use case --> works, cool, but with awful train names

• Use @Jean-BaptisteC 's work to test this new version of Motis with an online test dashboard Ajout d'un fichier TEC métropole serveur cartesapp/serveur#58

• think of edge cases

  • document the possible mis-results of the timetableView=false query and the potential necessity to enrich it with an arriveBy, as discussions on Motit's Matrix channel

• [ ] the "you'll take more time than walk" should only be a message, not remove the transit suggestions

Final

Switch the server to Motis v2 as the main, remove all motis v1 code and data. Switch the update script to motis v2.

Bonus for a second PR

• [ ] give some human sens to the results of this query : train names, train brands, train numbers
• implement the cycle suggestions as a distance in the UI : instead of talking about bike or car, just show the distance to the station in the results list to open the possibilities to e.g. a friend dropping you or taxi or transport unknown to Motis
• add accessibility pedestrian option & let the user come back to the "auto" mode
• add the "arriveBy" feature
• add the stops in the itinerary mode on the map. Not hard, but share code with the transit plans if possible
• The itineraries attribute is always there with potentially length === 0 It doesn't tell us if there's an agency here. But we could use our agency plans to check that, quite easily

Done

• handle motis request errors. Not sure v2 has error codes. Question asked.

• handle our transit options correctly

  • less trips suggested than v1 ?
  • losing the date on +x ?

• [x] we've tested on local transit systems (Rennes, Brest, Paris). Test on long routes : TGV, TER.

  • check that the SNCF icons are still working
  • implement the dual motis query to mix pedestrian and 1h cycling (20 km to train station) results
    • what about adding this request only if the bus + train option is inexistant or too slow (long detour bus) ? But wait for it to finish to avoid having a jumping UI

• [x] migrate app/itineraire/api/route.ts

• migrate TransitInstructions.tsx

• remove the call to our GTFS server on each transit calculation

  • we'll miss ""route_long_name", "Rennes (La Poterie) <> Vezin-le-Coquet (ZI Ouest)" but is it really used ? Shouldn't it be on-demande (clic for detailed instructions) ? Also, route_id
  • also : route_type. Is Motis' "mode" option enough ? https://github.com/motis-project/motis/issues/691. Check if motis' mapping is not too regressive compared to ours.
  • recode this call as a lazy enrichment on further screens ? Later

New features thanks to this migration :

• walk, cycle and car leg itineraries !

instead of

instead of

• bus GTFS real itineraries if they are input by the agency

instead of

Pauses between an itinerary step and the next transit to come are now shown to the user !

Immediate transit options are now displayed at a glance on the itinerary summary.

In case no simple immediate transit option is found, a button lets the user change the date and launch a deep search.