[GTFS-Fares v2] Add duration limit to fare_leg_join_rules.txt

[skalexch]

Summary

This proposal:

• Adds duration_limit and duration_limit_type to join rules in fare_leg_join_rules.txt.
• Suggests situations where it's possible to use either fare_leg_join_rules.txt or fare_transfer_rules.txt.
• Forbids overlap between fare_leg_join_rules.txt and fare_transfer_rules.txt for joins based on network_id.

Describe the Problem

This was part of the distance-based fares proposal. We decided to separate it in its own proposal for a few reasons:

1. The addition can actually help the fare implementation of many fare structures that are not distance-based (mentioned in Use Cases).
2. The distance-based fares proposal is moving slower than is required by the need for adding duration parameters to fare_leg_join_rules.txt.

Use Cases

This is mainly to allow the usage of fare_leg_join_rules.txt as a simpler way to define transfers in fare structures such as:

• Regions with complex point-to-point or zone-based fares in which only the first and last stop determine the fare.
• (Upcoming) Regions with cumulative zonal-fares that have timed passes.
• (Pending Network Sets and the relaxation of the single network join constraint) Integrated fare systems with multiple agencies.
• (Upcoming) Regions with distance-based fares.

Proposed Solution

Adding duration_limit and duration_limit_type to join rules in fare_leg_join_rules.txt and forbidding overlap between fare_leg_join_rules.txt and fare_transfer_rules.txt for joins based on network_id.

Type of change

GTFS Schedule

• Functional Change
• Non-Functional Change
• Documentation Maintenance

GTFS Realtime

• Specification Change
• Specification Change (Experimental Field)

Additional Information

More research can be found in the research document.

Proposed Discussion Period

We propose a discussion period of at least 2 weeks before starting an official review period. We will start the review period later in June.

Testing Details

• Consumer(s):
• Producer(s):
• Estimated Testing Period:

Proposal Update Tracker

Date	Update Description
(2026-06-03)	(Discussion period opened)

Checklist

• I have read and understood the GTFS Change process.
• I have read and understood the GTFS Guiding Principles.
• I understand the Role of Advocate and the Responsibilities attached to it.
• I have signed the Contributor License Agreement (CLA).
• I have ensured that this proposal is not covered by an existing Pull Request.

[etienne0101]

Hi @BodoMinea @jfabi, @felixguendling, @jasonad123, @halbertram @skinkie @bdferris-v2 @miklcct @jll01 @davidlewis-ito

Following previous Fares Working Group discussions in 2025, we have decoupled the duration limit fields from the distance-based fares proposal into a standalone Pull Request.

We believe this addition is broadly useful for various fare structures beyond distance-based ones, especially for simplifying transfer definitions.

We are planning to initiate a "vote-to-test" in mid-July.
Please take a look at the PR and let us know if you have any feedback or if you are interested in testing these new fields.

Thank you in advance for your contribution!

[felixguendling]

The router doesn't know when exactly the ticket will be validated (i.e. walking time between fare gate and departure/arrival of the vehicle vice versa).

So I would change departure fare validation to departure time (same for arrival).

[skalexch]

Thanks for sharing your feedback @felixguendling. In fact, the wording is copied verbatim from the definition of duration_limit_type in fare_transfer_rules.txt. Therefore, both need to be changed if need be.

However, this was talked about in a few 2023 Fare Working Group Meetings when timeframes were being discussed.

The consensus seemed to be that in a real-world situation, the timeframe (or fare product transfer duration since it's similar) starts when tapping on the bus (0 min of delay) or at a fare gate (a few minutes of delay based on the size of the station, how long the rider will linger or if they are taking the first train). So the time limit for a fare product starts counting down when the rider taps. Therefore, the wording "fare validation" accurately describes the mechanism in real life.

In terms of router behaviour, there are ways of approximating the duration of the journey's walking-legs to be able to compare directly with duration_limit, among others:

• Using pathways if they exist.
• Approximating in-station walking time using OSM.
• Providing default in-station walking times.

This is left to trip planners to choose how they approximate it.

[felixguendling]

This is left to trip planners to choose how they approximate it.

A good standard doesn't leave room for interpretation.

So I would propose to:

• either state that the timetable times (arrival / departure) can be used as they are. E.g. because the ticketing system itself leaves some room for walking by having more permissive limits or an average walking time is already subtracted from the duration limit
• or it's clearly stated that in-station walking times have to be calculated using GTFS pathways from fare gates (probably pathway_mode=6?) to tracks (or vice versa for arrival) - which would require a Fares v2 feed to always come with proper GTFS pathways.

I think that adding a duration_limit without a clearly defined way to measure durations (e.g. based on GTFS pathways; OSM is out-of-scope here I guess) isn't helpful if you want to consume the data.