bliksemlabs
trip-to-trip guaranteed transfers
Yeah the one open @ otp as well. Test feed @ http://gtfs.ovapi.nl/ns/beta/gtfs-iffns-20130218.zip
Trip-to-Trip transfers should be guaranteed by the timetable, but may have implications for a dynamic scenario. Hopefully the departure time is lagged by the operator. This is not tested, therefore not a testset requirement.
Discussion: Ignoring all assumptions about guaranteed transfers (that they are always on facing platforms etc.) Imagine 10 trains each arriving at different platforms at different times in a large station with 10 platforms. The trip with a guaranteed transfer we need to board will leave from a specific platform, say number 5. A sort of contest occurs within one round, with each of the 10 arriving trains calculating transfers to all other platforms in the station. Only one of the train "wins" the race to platform 5, and we currently store a walk link back to that "winning" trip and platform.
Now, boarding the trip with the guaranteed transfer happens in the next round, after the "walk race" has already happened. If the trip-platform-walk combination that gets you to platform 5 earliest is not the same one from which the transfer is guaranteed, we miss the chance to examine that guaranteed transfer and
One option: while considering boarding a trip with a guaranteed transfer, we re-traverse all walk links for its platform backward, checking that the source trip is not among those found in the previous round. Instead of using the single "best" walk option we re-consider all of them in these special cases. This would probably work but is elaborate, does not feel elegant.
Second option: consider that guaranteed transfers always happen on facing platforms. The distance between these platforms should always be the shortest that exists in the station, so in practice the transfer will usually be made. But we do have to be careful not to add any stair-climbing, slack, or fixed transfer cost constants of any kind between facing platforms on which guaranteed transfers are defined. This basically promotes trip-to-trip guaranteed transfers to platform-to-platform guaranteed transfers.
Discussion question: is it OK/harmless to mark all facing platforms as having no slack, essentially no transfer cost?
NS mainly has these trip-to-trip transfers as they have no quay-based routing but station-based routing with a transfer time per station. These journey transfers are mainly there as there are quite a few transfer-relations where it's possible to transfer below that time. Many of these transfers are cross-platform.
I'm mainly worried about the other kind of trip-to-trip transfers, transfer not allowed btw. The other transfers are mainly of the type "possible" and not "preferred".