motis-project / motis

Intermodal Mobility Information System
https://motis-project.de
MIT License
217 stars 51 forks source link

Retrieve next departures from Motis API for a transport in a chosen route #546

Open laem opened 2 months ago

laem commented 2 months ago

Hi,

I'm building the detailed trip steps for cartes.app and wondering how could I retrieve the next departures for a segment of a connection.

The aim is to implement what's become common in routing interfaces, e.g. nyc mta here, under the "More departures" section.

image

In case the transit option is the first of a series of correspondances, there should be a compatible next departure for the next transit modes too. In case it's the last, it doesn't matter.

felixguendling commented 2 months ago

There are multiple ways to implement this, especially when it's not the last transfer. Unfortunately, in your example it's the last transfer - so in this case the two following options would yield the same result in the majority of cases.

  1. departures that lead to the next stop at which you also transfer (or the final stop as in this case) in this particular connection. You would only search for an later alternative of the same leg, but the stop where you enter the trip and where you exit the trip would stay the same (no matter if there are better connections at this time where you would change at a different stop).
  2. departures are basically completely new connections computed from this point on. Interchange stops, etc. do not have to match (as there might be faster ways to get to the destination at this point in time than with the original pattern of transfer stops).

Option 2 would just be another routing query from the transfer station (giving you potentially completely different options on how to continue from there on).

Option 1 is not that easy to implement with the existing API. Without adding a new API, you would probably send a RailVizStationRequest (with direction = LATER), then check all returned trips with trip_to_connection requests if they also visit the stop where you would exit in the original connection. However, this doesn't really make sense to implement in the client (lots of ping/pong).

felixguendling commented 2 months ago

We had something similar in an old version of MOTIS that would directly return a "connection tree" instead of a single connection. This tree contains for each interchange the next connection if you miss the planned connecting train (and then the next and the next.. and so on until the probability based on historic delay messages would reach 100% that you reach your destination).

So this would basically be a recursive variation of Option 2 based on train delay probabilities as a stopping criterion for the recursion.

The UI looked like this:

image

As you can see, the connection can change significantly if you select the next departure. The UX was that you could "swipe" through later alternatives.

The advantage here was, that this connection tree can be saved offline - so no matter where you are (internet in subway tunnels is not always the best - at least in Germany), you have all your alternatives with you.

laem commented 2 months ago

Thanks, that's a very interesting answer, I'll see the best I can pick to implement a first version. You can see some dev captures here https://bsky.app/profile/cartesapp.bsky.social/post/3l4lrdldoty2x :)