transfers.txt use cases - transfer between two distant stations?

[orhazal]

Hello everyone,

I'd like to ask about the intended scope of transfers.txt in the GTFS spec, and whether a specific use case I have falls within it.

Context

I'm working with the SNCF (French national railway) GTFS feed. Paris has 7 major train stations serving different regions of France and Europe. Within this feed, these stations are technically connected to each other, but only through very long detours via other cities - not through the actual urban transit network (metro, RER, buses) that passengers use in practice. That urban network is published in a separate GTFS feed (IDFM) that we cannot integrate into our trip planner.

As a result, for itineraries like Lille -> Bordeaux, the trip planner has no practical way to route the transfer leg: the passenger would take a train from Lille to Paris Gare du Nord, use the Paris metro/RER to reach Paris Montparnasse, then board a train to Bordeaux, but that middle leg doesn't exist in the SNCF feed.

To solve this, I'm trying to convert proprietary SNCF minimum transfer time data into a transfers.txt file that I would append to the SNCF GTFS feed. This data is not in GTFS format, it was originally published by SNCF to comply with the European Passenger Rights Regulation (PRR). These minimum transfer times define which connections SNCF considers guaranteed, but also which ones are considered infeasible. The data covers both transfers within a single station and transfers between distinct stations in the same city. I need to understand whether transfers.txt can represent this.

Questions

1. Does the spec allow transfers between distant stops? In my case, Gare du Nord and Gare Montparnasse are ~5 km apart (crowfly). Is there anything in the spec (explicit or implicit) that limits the geographic distance between two stops in a transfer record?

2. Can transfer_type=2 work without a connecting feed? Specifically: can I define a transfer_type=2 record between two stops in different stations to express "a passenger can transfer here in X minutes", even though no GTFS trip models the actual journey between them?

3. In practice, do trip planners handle this? Beyond what the spec says, are there known implementations that support or reject transfers between stops that are far apart or not connected by any trip in the feed?

Thank you for any insight.

[felixguendling]

1. The spec restricts neither the distance nor the min_transfer_time.
2. I think "no faster trips" is even a hard requirement for most routing engines. Once you have a trip that allows you to undercut the minimum transfer time, most routing engines will produce additionally the trip (i.e. two transfers) and not just the direct transfer.
3. MOTIS by default adjusts transfers that are not feasible with an average fast walking speed and in general has a max transfer time setting to clean data from data errors, but this can be turned off.

[orhazal]

Thanks for the answer @felixguendling

I'm testing the max_footpath_length and adjust_footpaths parameters in Motis.

So here is my understanding :

• max_footpath_length : used at runtime ; seems to be the parameter you mentioned here "in general has a max transfer time setting to clean data from data errors" , and it seems that it is in fact a duration (defaulted at 15min) and not a length.
• adjust_footpaths : used at import only? when true, nigiri calculates the crowfly distance and adjusts the footpath with a walking speed. For my tests, it adjusts a 5km distance from 4min to approx. 50min, which seems more "realistic".

Bonus question : Motis seems to always add 2 or 4min to transfers, is it a buffer of some kind?

Thank you

[felixguendling]

If this is specific for MOTIS (and not general GTFS), maybe we move the discussion to the MOTIS (or in this case nigiri) bug tracker.

Can you maybe define a unit test that fails? And then we can work from there backwards.

Regarding your general question about GTFS, the answer is clear that such a transfer is allowed in transfers.txt - if MOTIS has a different interpretation we should adapt that to be aligned with the GTFS standard.