Open laem opened 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.
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).
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:
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.
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 :)
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.
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.