Who doesn’t care about money?
Everyone cares about money.
What is the cost of my ride? What discounts am I allowed to use? What discounts are available to me? In the transit standardization world, GTFS-Fares have been a long time discussion, since 2013 and with a proposal in 2018. It is with great excitement that we are presenting GTFS-Fares v2 🎉.
Fares are complicated
When we think of a ride fare, we often think of the price of a single ride or a monthly pass. Unfortunately, fare structures can get much more complicated. The result is that only a limited number of transit agencies are able to describe their most basic fares, while many more agencies find it impractical to describe any of their fares using the current GTFS model. Moreover, the rigid model currently in place proves difficult to extend with the crucial information that transit riders need in the decision making process. This is why GTFS-Fares was ready for a major update.
GTFS-Fares v2 proposal supports a better and clearer description of the complexity of fares.
This new version is addressing:
- Time-based fares (i.e., peak hour vs off-peak hour)
- Distance-based fares
- Rider category discounts
- Fare containers (i.e., magnetic cards to load money or fares onto)
- Fare products (i.e., passes that can be used for travel at a cheaper rate, such as a monthly pass)
- Fare capping
- Detailed payment methods and locations of payment
Isn’t that wonderful? 🌟
Read the rest of the blog post to learn about the status of the proposal and get more precise details.
State of the project
Over the past few months MobilityData has been supporting early implementors in getting this project up and running. As of now, we have at least 3 producers and 1 consumer for a subset of the proposal. All the details on what exactly is being produced & consumed are here.
Modeling fares introduced complexities greater than GTFS Schedule itself. Being a large proposal, collaboration with external stakeholders is key for making the proposal thorough and actionable from conception to implementation. Moreover, GTFS does not benefit from having regular releases since changes are made based on community-wide consensus. This means that changes take time to model and get right.
MobilityData will continue the efforts in seeking more producers and consumers to stabilize the extension and allow its adoption as widely as possible. Can your organization be an implementer? Reach out to specifications@mobilitydata.org.
GTFS-Fares v2 in details
GTFS Schedule currently describes transit fares using files fare_attributes.txt and fare_rules.txt. File fare_attributes.txt describes a basic fare price, payment, and transfers. File fare_rules.txt associates fares to Origine – Destination itineraries along a route.
To better represent the puzzle of fares for the agencies, many extensions are being included in GTFS-Fares v2. Here is a summary:
| Extension name | Description |
| GTFS-FareData | Processing of fare cost of individual legs of travel and transfers for different conditions of travel: networks, areas, distance, and timeframes. |
| GTFS-RiderCategories | Rider categories that are eligible for certain fares. |
| GTFS-FareContainers | Descriptions of fare media (i.e., paper tickets, smart cards, digital wallets) that can be used to load and use fares. |
| GTFS-FareProducts | Fare products that describe the different passes that can be purchased by a rider. |
| GTFS-FareCapping | Fares that can be capped after a price threshold has been spent within a timeframe. |
| GTFS-TravelRules | Travel rules for time prior and locations that certain actions can be done: booking or purchase, show-up or check-in time, validation or stamping, boarding. |
GTFS-Fares v2 finds the cost of travel by processing individual legs of travel on an overall journey.
Using file fare_leg_rules.txt, the cost of each individual leg is determined and the corresponding transfer rules between legs are calculated using file fare_transfer_rules.txt.
Example A: Basic fare with transfer
First the cost of the leg is defined in fare_leg_rules.txt
Then, the transfer rules are defined in fare_transfer_rules.txt
In this example the cost to travel a leg is 3.30 CAD, and the fare can be used to transfer for free to other legs of travel for 5400 seconds (or 90 minutes).
Example B: Flat fare but free for children (rider categories)
[Source: https://www.sts.qc.ca/117-Tarifs—Transport-urbain.html]
STS (Sherbrooke, CA-QC) has a flat fare for 90 minutes but is free for some categories of population. We can use GTFS-RiderCategories and GTFS-FareData to describe such categories of population:
For more examples, such as special fare for location, fare containers, choice between fares and many more, consult the open proposal here: GTFS-Fares v2.
Some uses cases to consult:
