A Leap in Transit Standards: Time-Based Fares
Better Rider Decisions with Discoverable Fare Structures
Public transit users deserve to know how much a trip is going to cost, but fares are complex.
A common model is time-based fares, where fares depend on the time of day a trip is made, resulting in distinct categories such as peak or off-peak fares, and weekday or weekend fares.
Let’s look at how modeling fares that vary by time has made its way into the General Transit Feed Specification (GTFS), an open data standard used by thousands of transit agencies across the world.
Context
GTFS Fares-v2 is an extension project that enables transit agencies to model complex fare structures in a standardized way, which makes it possible for riders to visualize accurate fare information that matches their trips. This project is being developed by a dedicated public working group composed of industry experts from across the globe and facilitated by MobilityData.
The working group follows an iterative approach, fine-tuning each individual component (i.e. time-variable fares, zone-based fares, fare media, etc.) to carefully analyze its use cases and ensure seamless integration with the rest of GTFS.
This process ensures that value is created with the adoption of each component.
Modeling time and day-varying fares:
Whether it starts at 6:30 AM in London, 7 AM in Santiago, or 8 AM in New Dehli, it’s common that peak-hour travel entails a special fare.
Variable time fares can now be defined in a standardized way in GTFS using timeframes.txt. This file makes it possible to designate time frames and associate them with applicable dates using the service_id field. Specific fares from fare_products.txt can then be assigned to these time frames using fare_leg_rules.txt to reflect the applicable pricing depending on when the rider plans their ride. It is also possible to specify whether the fare is solely based on the start time of the journey or if both the start time and end time are considered.
For our friends in Sydney who have fares that vary based on both time and geographical factors, not to worry! Time frames can also be used in tandem with other fare-discriminating factors.
The gtfs.org Fares v2 data examples page now features two new examples sourced from real data, and we hope it assists agencies and data re-users in their efforts to integrate and capitalize on the value offered by this addition!
- Define price differences based on time and day of trip
- Define time-variable fares along with zone based fares
The adoption process
The GTFS adoption process is open and allows anyone to participate and contribute in the evolution of the standard. The working group, consisting of dedicated individuals from different backgrounds, meets regularly to advance the extension process.
Before any addition becomes part of GTFS, at least one data producer and one consumer must commit to implementing the experimental feature. This ensures that proposed extensions are robust and practical, backed by real-world testing and feedback.
For the Fares-v2 extension, we are immensely grateful to ITO World for being the data producer and Apple Maps for being the consumer.
What’s next
The addition of time and day-varying fares into GTFS is a significant achievement, but the work is far from over. Our dedicated working group continues to actively refine and advance the proposal, seeking ways to enhance fare modeling further.
We welcome transit agencies, developers, and stakeholders to actively engage in the conversation surrounding the Fares-v2 extension. You can join our Slack community to connect with fellow enthusiasts, participate in working group discussions, and stay informed about the extension on the dedicated Fares v2 page in the GTFS Extensions section of gtfs.org.
With the Fares-v2 extension, we take another stride forward in building a more efficient and user-friendly transit ecosystem. We extend our gratitude to everyone involved in making this milestone possible.
