I’m writing this issue to get an overview of what kind of transfer functionality is supported in GTFS, NeTEx, OTP 1.x and start a discussion about what should be supported in OTP2. It is important to have this discussion now, as this kind of functionality has to be tightly integrated with the core routing algorithm.
https://developers.google.com/transit/gtfs/reference/#transferstxt
https://gtfs.org/best-practices/#transferstxt
https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728760393/timetable#timetable-Interchange.1
https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728727661/stops#stops-StopPlace.1
REGULAR TRANSFER NETWORK
These transfer that are not explicitly defined or guaranteed in any way we will call “regular transfers”. There are several different ways to describe these:
- Use the straight line distance between stops
- Use OSM street routing (micro-mapping stations)
- Define transfers in GTFS file (transfer type 2)
- Use GTFS pathways to describe stations in detail
SPECIAL TRANSFERS
In addition we sometimes want to define some kind of special transfers. These are special ways the operator wants people to transfer and provide more information than the physical descriptions of the stations and walk paths.
NeTEx ServiceJourneyInterchange is defined between specific trips (ServiceJourneys), while GTFS transfers are defined between stops, but there is a widely used extensions that allows you to specify routes or trips.
Stay seated
The trip/route/operator changes, but the passenger stays seated. This can be to show it as different trips in the journey planner or because the parts use different real time systems.
NeTEx: Supported (interchange->StaySeated)
GTFS: Supported (trip->block_id)
This block_id method is heavily debated. The last time the discussion came up, the end conclusion seemed to be that we should use a new transfer type to represent in-seat transfers instead of implying them with blocks.
Andrew
Guaranteed transfers
The vehicle will wait a specific amount of time for another arriving trip. The operator wants to show this information as well as favor journeys containing guaranteed transfers.
These are used more for low-frequency routes, and not so much for high-frequency routes inside city centers.
This also leads into the discussion about delay propagation, which should probably be a separate issue.
NeTEx: Supported
GTFS: Supported (transfer type 1, no maximum wait time)
Travel guarantee
The operator will guarantee that you reach your final destination if you account for a specific amount of time for each transfer. Different transfer times depending on stops and trip combinations. A travel planner client might want to include a special search where this increased transfer time is taken into account. In the case where the wait time required is the same at all the stops, this can be solved by setting the transfer slack parameter and would not require defining any special transfers.
NeTEx: Not supported
GTFS: Not supported
Forced transfer
In some cases an operator wants to connect trips together with transfers, but disallow either alighting from the arriving trip or boarding the departing trip. This might be a in the case of a replacement service, where the replacement service is only meant for passengers from a specific arriving trip.
NeTEx: Might be modelled using StopPointInJourneyPattern->ForBoarding false
GTFS: Might be modelled by using pickup_type 1
Note: It seems like this is not a good way to model it in either NeTEx or GTFS. @vpaturet is looking into ways to model it in NeTEx.
Prohibited transfers
For various reasons you might want to disallow transfers between specific trips. This usually seems to be in the case of risky transfers where the passenger is transferring to a low-frequency service.
NeTEx: Supported (Interchange->Priority -1)
GTFS: Supported (transfer type 3)
Recommended transfers
Between specific trips the operator wants to control where transfers will happen. For various reasons an operator might want passenger to transfer somewhere other than what the routing criteria and/or stop weighting implies.
NeTEx: Supported (Interchange->Priority 1 and 2)
GTFS: Supported (transfer type 0)
STOP WEIGHTING
Some stops are more suited for transferring than others. If you have the choice between transferring at a bus stop along a heavily trafficked road or a central station, you might want to choose the latter.
We can solve this by classifying each stop according to its suitability for transferring. The router can then favor using these stops for transfers, regardless of which trips or operators are used.
NeTEx: Supported (StopPlace->Weighting (allowed/recommended/preferred))
GTFS: Not supported (Possible using recommended transfers, but it requires you to enumerate all the possible transfers (boolean))
In the case of NeTEx there are 3 priority levels both at the StopPlace level and the Interchange level. Both should probably be taken into account.
I’m writing this issue to get an overview of what kind of transfer functionality is supported in GTFS, NeTEx, OTP 1.x and start a discussion about what should be supported in OTP2. It is important to have this discussion now, as this kind of functionality has to be tightly integrated with the core routing algorithm.
https://developers.google.com/transit/gtfs/reference/#transferstxt
https://gtfs.org/best-practices/#transferstxt
https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728760393/timetable#timetable-Interchange.1
https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728727661/stops#stops-StopPlace.1
REGULAR TRANSFER NETWORK
These transfer that are not explicitly defined or guaranteed in any way we will call “regular transfers”. There are several different ways to describe these:
SPECIAL TRANSFERS
In addition we sometimes want to define some kind of special transfers. These are special ways the operator wants people to transfer and provide more information than the physical descriptions of the stations and walk paths.
NeTEx ServiceJourneyInterchange is defined between specific trips (ServiceJourneys), while GTFS transfers are defined between stops, but there is a widely used extensions that allows you to specify routes or trips.
Stay seated
The trip/route/operator changes, but the passenger stays seated. This can be to show it as different trips in the journey planner or because the parts use different real time systems.
NeTEx: Supported (interchange->StaySeated)
GTFS: Supported (trip->block_id)
Guaranteed transfers
The vehicle will wait a specific amount of time for another arriving trip. The operator wants to show this information as well as favor journeys containing guaranteed transfers.
These are used more for low-frequency routes, and not so much for high-frequency routes inside city centers.
This also leads into the discussion about delay propagation, which should probably be a separate issue.
NeTEx: Supported
GTFS: Supported (transfer type 1, no maximum wait time)
Travel guarantee
The operator will guarantee that you reach your final destination if you account for a specific amount of time for each transfer. Different transfer times depending on stops and trip combinations. A travel planner client might want to include a special search where this increased transfer time is taken into account. In the case where the wait time required is the same at all the stops, this can be solved by setting the transfer slack parameter and would not require defining any special transfers.
NeTEx: Not supported
GTFS: Not supported
Forced transfer
In some cases an operator wants to connect trips together with transfers, but disallow either alighting from the arriving trip or boarding the departing trip. This might be a in the case of a replacement service, where the replacement service is only meant for passengers from a specific arriving trip.
NeTEx: Might be modelled using StopPointInJourneyPattern->ForBoarding false
GTFS: Might be modelled by using pickup_type 1
Note: It seems like this is not a good way to model it in either NeTEx or GTFS. @vpaturet is looking into ways to model it in NeTEx.
Prohibited transfers
For various reasons you might want to disallow transfers between specific trips. This usually seems to be in the case of risky transfers where the passenger is transferring to a low-frequency service.
NeTEx: Supported (Interchange->Priority -1)
GTFS: Supported (transfer type 3)
Recommended transfers
Between specific trips the operator wants to control where transfers will happen. For various reasons an operator might want passenger to transfer somewhere other than what the routing criteria and/or stop weighting implies.
NeTEx: Supported (Interchange->Priority 1 and 2)
GTFS: Supported (transfer type 0)
STOP WEIGHTING
Some stops are more suited for transferring than others. If you have the choice between transferring at a bus stop along a heavily trafficked road or a central station, you might want to choose the latter.
We can solve this by classifying each stop according to its suitability for transferring. The router can then favor using these stops for transfers, regardless of which trips or operators are used.
NeTEx: Supported (StopPlace->Weighting (allowed/recommended/preferred))
GTFS: Not supported (Possible using recommended transfers, but it requires you to enumerate all the possible transfers (boolean))
In the case of NeTEx there are 3 priority levels both at the StopPlace level and the Interchange level. Both should probably be taken into account.