Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
laem opened this issue Sep 20, 2024 · 3 comments
Open

Comments

@laem
Copy link

laem commented Sep 20, 2024

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
Copy link
Member

felixguendling commented Sep 20, 2024

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
Copy link
Member

felixguendling commented Sep 20, 2024

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
Copy link
Author

laem commented Sep 23, 2024

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants