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-09-08)	PR drafted in fork

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.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[tzujenchanmbd]

primary key seems incorrect for this file.

[tzujenchanmbd]

Seems inconsistent with the "Dataset files" section

[derhuerst]

I'm curious... Why isn't this PR in the google/transit repo, where almost all of the GTFS proposals are discussed?

[skalexch]

@derhuerst this was just a draft PR that I did prior to raising the PR on Google's transit repo back in September (google#578).

I will close this one. If there's any place where I linked this instead of the Google transit repo PR please let me know.