[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.

[skalexch]

@felixguendling I am planning to add this to the proposal both in the fare_transfer_rules.txt and fare_leg_join_rules.txt sections. We wanted to clarify that the duration_limit strictly adheres to the time limit on transfers defined by the agency. It is better to not introduce any approximations to the field itself. Therefore, pathways is the only way provided by the spec to calculate the station crossing time by trip planners for large stations.

Snippet to be added:

Calculation of duration_limit

As implied by duration_limit_type, duration_limit starts and ends at fare validation events (e.g. a tap at a fare gate or onboard validator), not at the moment a rider physically boards or alights a vehicle. The duration_limit does not account for the time it takes a rider to cross between a fare gate and a platform.

This means duration_limit should be set to the same theoretical transfer time limit that the agency publishes to riders (e.g., "transfers must be completed within 90 minutes"), rather than to a measured or estimated travel time.

If the feed contains pathways.txt, data consumers can estimate this crossing time using pathways.traversal_time, pathways.length or pathways.stair_count.

I'd like to hear your feedback on this!

[felixguendling]

This is way better. However, it's still not on a level that would guarantee that if route planner (or any other consumer like a ticketing system) A and B both follow this definition it's guaranteed that the same ticket options will be shown in all cases. IMO this should be the goal with such a definition.

[skalexch]

@felixguendling thanks for the feedback! I've updated the description and committed the change. Aside from keeping the same definition of duration_limit as the theoretical transfer validity time, I emphasized that consumers should use traversal_time when pathways exist. This guarantees that if producers and consumers follow this best practice, they'll arrive at the same result in the journey planner.

We didn't restrict consumers from using other fields when traversal_time isn't available, for two reasons: 1) we wanted to preserve that flexibility for consumers, and 2) traversal_time is not always populated unfortunately. In an ideal state, traversal_time would be used universally to estimate.