Add maximum waiting time to transfers.txt about transit

[jiracekz]

Thanks for your comment. I completely understand the model you suggest. In the future, we would like to implement this in a similar way, so that the passengers on the waiting trip are informed that the vehicle will be delayed, in advance.

However, the purpose of this ticket is more to describe the static data and to complete the static information for instance for cases where I search for a connection for tomorrow. Today I can present the passenger with an assurance "The second trip waits for the first time for some limited amount of time". But using only GTFS-specification I cannot present the specific time. I understand that this may be a lot Czech-specific, but some of these ensured transfers are just 5 minutes of waiting time, therefore there is still some risk it will be missed.

[derhuerst]

A more general (but also more effort to implement) option that doesn't require an additional field: Why not express this using GTFS-Realtime?

If trip B waits for trip A, and if trip B was planned to leave before trip A will arrive now, trip B will be delayed too. As long as trip B has a "large enough" delay required to wait for trip A expressed via GTFS-Realtime, realtime-capable route planners will likely calculate a transfer to still be possible.

For the waiting scheme used in Czechia (up to 20 minutes), trip B's delay would match trip A's delay (minus the planned transfer time), up to 20m. If trip A's delay increases beyond that, trip B's delay would either stay at 20m or "switch back" to 0m, depending on how this works in Czechia.

---

However, I would like to add the perspective of German lond-distance trains on this topic: It is common practice for the on-board staff to clarify with (staff at) the station the train will arrive at next and confirm which other trains will wait. For those trains that have been confirmed to wait, it is announced via intercom that passengers will very very likely catch them.

One could express this situation using delays (GTFS-Realtime StopTimeUpdates) only, but in reality, such a transfer confirmation is of a more binding nature, as the subsequent train will wait until the vast majority of passengers have successfully boarded it. Therefore it might make sense to express this explicit transfer confirmation in GTFS-Realtime too.

In Czechia, as soon as the first train is known to be delayed >20m, this explicit "transfer assurance" could be canceled or removed from the GTFS-Realtime feed, and thus considered outdated.

I have also witnessed situations like these in long-distances buses, where the drivers arrange "assured transfers" via radio or phone.