Use times from transfers.txt #641

[abyrd]

This addresses #641. If transfers.txt is present it is currently expected to contain only stop-to-stop transfers of type 2, and those transfers completely replace the ones that would be generated from paths through OSM. It must be an exhaustive list of all transfers in the network (which is provided by some external GTFS-generating tools). Many of these characteristics must be made optional, but we'll need a mechanism to configure that (#644).

[abyrd]

One thing that remains here to make this production-ready is to ensure we handle the interactions with scenarios being applied.

[ansoncfit]

Let's make sure to test with the MBTA's feed, which includes transfers and pathways.

[RicoFio]

Hi @abyrd ! Is there a current roadmap on merging this into production by any chance? I'm asking since I noted a recent pick-up in interest here and here.

I'm working with @vvaye (OP of the R5PY issue) and the circumvention we took was to remove the transfers.txt all together for now from the MBTA GTFS feeds. However, I don't know the impact on the R5 routing when doing so. If you could share a few words on the implications, that would be super useful.

Thanks for all your work!

[abyrd]

Hi @RicoFio, sorry for the delayed response. We do not currently have a detailed plan for transfers.txt handling, but it is a good candidate for the upcoming roadmap.

For a long time most of our users were not relying on transfers.txt so it was simply skipped. But obviously there are an increasing number of cases where GTFS feeds rely on this file for correct interpretation.

The basic implementation is already here, but the problem is ensuring we've correctly identified the most common use cases and providing the right set of configuration options to give the intended results. Notably, we need to clarify whether transfers.txt replaces, complements, or restricts the auto-generated on-street transfers, and whether it does so per origin stop, per origin-destination stop pair, or fully replaces automatic transfer generation.

We also need to decide whether to handle the nuances of transfer specificity (e.g. trip to trip transfer rules) which may have some unwieldy interactions with the routing algorithm. And as noted above, scenarios can create and remove stops, leading to re-calculation of which transfers are available at all stops in the vicinity. We need to fully specify how this would interact with the various interpretations of transfers.txt mentioned above.

If you have any input on which approach(es) would be most useful please let us know.