Repository navigation
[Governance] Pull Request Template Example #543
Description
THIS IS MEANT TO SERVE AS AN EXAMPLE FOR A PR TEMPLATE
Summary
This proposal introduces a new "rider category eligibility" field to GTFS-Fares v2, allowing agencies to specify eligibility criteria for discounted or restricted fare categories (e.g., senior, student, low-income). This change improves clarity for both data producers and consumers, ensuring accurate fare application across transit systems.
Describe the Problem
Currently, GTFS-Fares v2 allows defining fare products and their pricing but lacks a standardized way to indicate who qualifies for certain fares. This leads to inconsistent implementations, requiring agencies and consumers to rely on non-standard methods like external documentation or assumptions.
Relevant issue: google/transit#XYZ
Use Cases
- Student Discount: A university transit pass is available only to students with a valid ID.
- Low-Income Fare Program: A city offers reduced fares for riders enrolled in a government assistance program.
- Senior Fare: Riders aged 65+ receive a discount but must verify their age.
With this proposal, transit apps can accurately display and enforce eligibility rules, preventing confusion and ensuring correct fare application.
Example:
A transit rider views a discounted fare in an app, but instead of uncertainty, they now see "Available for registered students only. Apply via agency website."
Proposed Solution
Add a new field to fare_leg_rules.txt and fare_transfer_rules.txt:
| Field Name | Type | Required | Description |
|---|---|---|---|
rider_category_id |
ID | Optional | References a new rider_categories.txt file defining eligibility criteria for certain fares. |
Introduce rider_categories.txt:
| Field Name | Type | Required | Description |
|---|---|---|---|
rider_category_id |
ID | Required | Unique identifier for the rider category. |
name |
Text | Required | Human-readable name (e.g., "Senior", "Student", "Low Income"). |
eligibility_description |
Text | Optional | Description of eligibility criteria. |
Type of Change
GTFS Schedule
- Functional Change
- Non-Functional Change
- Documentation Maintenance
GTFS Realtime
- Specification Change
- Specification Change (Experimental Field)
Additional Information
- Discussion in GTFS Slack: #fares-v2
- Related proposals: GTFS-Fares v2 adoption discussion
- Some agencies (e.g., MBTA, LA Metro) have expressed interest in standardizing eligibility representation.
Proposed Discussion Period
I recommend a minimum discussion period of 4 weeks to allow agencies, transit apps, and other stakeholders to provide input on the proposed changes.
Testing Details
- Consumers: Transit, Google Maps, Moovit
- Producers: MBTA, LA Metro
- Estimated Testing Period: 6-8 weeks
Proposal Update Tracker
| Date | Update Description |
|---|---|
| 2025-03-11 | Initial draft proposal submitted for discussion. |
| 2025-03-11 | Edited Testing details |
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.
Activity