Split up minimal transfer time in router in physically necessary walk duration and delay and QSim alighting buffer

[vsp-gleich]

This issue was mentioned in #1118.

Typically we have something like 1s per alighting passenger set in the TransitVehicle type and in QSim passengers alight one after the other. So the last passengers alights multiple seconds after the scheduled arrival of the transit vehicle even if the vehicle was running on time. Then the passenger has to walk to the stop where he plans to board a connecting bus service. That walk leg has a fixed travel time set by the pt router. That travel time is calculated with minimal transfer time (a router parameter) as a minimum https://github.com/matsim-org/matsim-libs/blob/d6d325356effda6597d6f281c8d248347f1dfa31/matsim/src/main/java/ch/sbb/matsim/routing/pt/raptor/SwissRailRaptorData.java#L245-L248

So that travel time does not represent only the physically necessary walk duration to reach the transfer stop. Instead it includes some buffer time to ensure the connecting bus is not missed. However, although it makes sense that the router adds some kind of buffer time during routing and thereby excludes connecting services which depart too shortly after the agent arrives at the stop, during mobsim that buffer time cannot be used as a buffer time, because the walk has exactly the duration set by the router which includes the buffer time. So the router should rather return the transfer leg without the buffer time.

The mixing of real physically necessary walk time between stops and buffer time for slow alighting and delays makes things complicated. However, that is how minimal transfer times are defined right now and how they can be defined TransitSchedules for TransitStop pairs. Probably GTFS also mixes those things up, so it would be hard to find a data source which separates physically necessary walk duration and buffer time. But maybe we could come up with that ourselves (calculate physically necessary walk time between stops and deduct that from the transfer time set in GTFS, interpret the result as buffer time to be used by the router only and not to be included into the transfer walk travel time).

[sebhoerl]

Just as a note, the GTFS reference says "Transfer requires a minimum amount of time between arrival and departure to ensure a connection. ", so indeed, it may not only include the bare walk time, I guess.

Not sure how is the availability in other places, but for Île-de-France the schedule contains "pathways.txt" which describe in detail the walk network between the stops. I already thought that it may be an interesting component to include (especially in Paris where walking underground can be 10 minutes or so).

Edit: Just thinking of it, this could of course also be pre-processed. Everywhere where there is a minimal transfer time, and where we find a path, we can use the assumed walk time on that path instead. If the data is available, this would solve the problem, wouldn't it?

Edit 2: In any case, maybe it would be wise to rename "minimumTransferTime" to "minimumWalkTime" so the current behaviour becomes explicit in a way?