[GTFS Fares v2] Add network sets and relax constraint on networks in fare_leg_join_rules.txt

[skalexch]

Summary

This proposal:

1. Adds network set predicates which allow for matching with collections of networks in fare_leg_rules.txt
2. Relaxes the constraint that only legs with the same network can be joined in fare_leg_join_rules.txt, thus allowing joins across networks.

Describe the Problem

1. There needs to be a method to define how a fare leg rule should match an effective fare leg (resulting from a fare_leg_join_rule.txt join) that spans multiple networks.
2. The current spec says in fare_leg_join_rules.txt that a leg with a network_id can only be joined to another leg with the same network_id, which is restrictive and does not represent multiple real-world cases,

Use Cases

Network sets can be used in cases where routes from different networks can be priced together under the same fare scheme.

Three real-world cases are detailed in the Network sets real-world case research document, including STM's Airport bus, the ORCA fare scheme in Seattle, and the multiple fare tiers of LeCar in the Aix-Marseille-Provence region.

Proposed Solution

The full proposal can be found here. It includes:

1. Adding Network Set Predicates to match effective fare legs to rules in fare_leg_rules.txt. These network sets are defined in network_sets.txt and mapped to routes in network_set_elements.txt.
2. For Network Sets to be usable, it is necessary to relax the constraint that only legs with the same network can be joined in fare_leg_join_rules.txt. By allowing leg joins across different networks, the effective fare leg will contain multiple network_ids.

This proposal was discussed and its scope was defined in multiple Fares v2 Working Group meetings. For further details, please check:

• Meeting notes - 2025/05/27
  
• Meeting notes - 2025/07/22

Type of change

GTFS Schedule

• Functional Change
• Non-Functional Change
• Documentation Maintenance

GTFS Realtime

• Specification Change
• Specification Change (Experimental Field)

Additional Information

Proposed Discussion Period

We propose that the discussion period last 14 calendar days from the date this PR is raised.

Testing Details

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

Proposal Update Tracker

Date	Update Description
(2025-12-05)	Vote-to-test initiated

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.

[skalexch]

As per the new governance guidelines, we will soon begin the vote-to-test. Before that, we are starting a one-week review period today.
Please review the proposed changes and share your feedback here.

[skalexch]

Following a review within MobilityData, we have updated the proposal:

• Renamed the Network Set predicates to travels_through_network_set_id and travels_strictly_through_network_set_id.
• Added both fields to the primary key of fare_leg_rules.txt.
• Defined mutual exclusivity between network_id, travels_through_network_set_id, and travels_strictly_through_network_set_id to prevent ambiguity and misinterpretation; only one of these three fields may be specified at a time.

Regarding the last change:

• If network_id exists with any of the other predicates, it can be confusing or even contradictory.
• If travels_through_network_set_id and travels_strictly_through_network_set_id both exist, travels_through_network_set_id would have to be included in travels_strictly_through_network_set_id, causing a redundancy. If not, the leg rule will never be matched.

To maintain clarity and ensure the integrity of the process, we propose to relaunch the discussion period for a duration of 14 days, followed by a 1-week review period.

The discussion period will conclude on 26 November 2025 at 23:59:59 UTC.

[skalexch]

We are starting a one-week review period today before beginning the vote-to-test. The review period will conclude on 5 December 2025 at 23:59:59 UTC.
Please review the proposed changes and share your feedback here.

[skalexch]

I am initiating the vote-to-test for this proposal.

This is the first functional change proposal using the new governance, therefore, for the vote to be valid, it must include at least five contributors, with a minimum of two Producers and two Consumers. The voting period must last at least 14 days.

Voting ends on 19 December 2025 at 23:59:59 UTC.

[skalexch]

The vote to test did not meet the requirements (at least five contributors, with a minimum of two Producers and two Consumers) to pass, we will relaunch another vote-to-test in early January 2026.