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