Success Story: GTFS-Fares v2 base implementation

After months of work, GTFS-Fares v2 has reached base implementation! 🎉 Transit riders want to know their ride’s cost and other pricing options available to them – that is what GTFS-Fares v2 represents. This enables transit riders to make better decisions on how and when they travel to do what they need to – whether it is work, school, shopping, healthcare, leisure, or anything else.

Background

Fares are complicated. Only a limited number of transit agencies were able to describe their most basic fares, while many more agencies found it impractical to describe any of their fares using the previous GTFS model. All of this made it difficult for transit riders to get the information necessary to make decisions about their journeys. It is important to note that Interline and MTC were the original data producers and Transit was the original data consumer in this process. 

The scope was not clear for the first iteration of GTFS-Fares v2 and focus was lost. It took several trials to regain focus and momentum. Once the scope was refined, things were able to move forward. A vote re-opened on May 9th, 2022, and with 9 votes in favor and none against, GTFS-Fares v2 base implementation was passed. How exciting! 🌟 

Making a change was crucial

There was a major difference between the first and the last vote – a change of process and mindset. Previously, discussions were kept in GitHub, however, MobilityData opened the door for a virtual roundtable discussion. This was offered to anyone who wanted to participate, giving the opportunity to both data consumers and data producers to engage with each other. MobilityData acted as a facilitator while data consumers and data producers discussed their challenges. This process really made the difference. 

A success for everyone 

Not long after the vote passed for base implementation, MobilityData hosted the International Mobility Data Summit in June 2022. There was a workshop on GTFS-Fares v2 [GTFS Developer’s Workshop on Transit Fares] and the session was successful. Attendees discussed the future of GTFS-Fares, and the diversity of stakeholders in that session was tremendous. The session allowed attendees to discuss the current state and next steps for GTFS-Fares v2, and identify collaboration opportunities. The result of that session is that there is now a list of identified features that should be implemented next. Now, there is a priority list: 

• Allowing multiple routes to behave as a single route (transfer rules ignored)
• Variable pricing by time of day, or by day of the week, month, or year
• Zone-based fares
• Inter-agency transfers (using fare_leg_rules.transfer_only)
• Distance-based fares
• Rider categories
• Fare containers
• Fare bundles and passes
• Fare capping
• Transfer sequences
• Min/max range to approximate trips costs
• Inter-agency fares (using shared identifiers)

We also had two points raised that are worth having a conversation on:

• Creating a message field for how to use the fare system
• Which files and fields from GTFS-Fares v2 should have shared identifiers

Going forward

The biggest learning from this process was that we need to instill clarity of what is in and out of scope. The team at MobilityData encourages stakeholders to continue out-of-scope conversations in another forum to keep the momentum going. MobilityData will continue working on GTFS-Fares v2 by adding more functionalities into the specification. This comes as a successor to the base implementation, which added fare legs, fare areas, complex transfers, and tickets. 

We are now working on the second implementation of GTFS-Fares v2, which covers the following features:

– Variable pricing by time of day, or by day of the week, month, or year

– Fare containers

– Allowing multiple routes to behave as a single route (transfer rules ignored)

– Zone-based fares

Inter-agency transfers (using fare_leg_rules.transfer_only)

We are also very excited to announce that for the second implementation of GTFS-Fares v2 the data producer is Interline and the data consumer is Apple. 

You can consult all the details on the plan for this next iteration on GitHub.

Conclusion

After many years of discussion around Fares, MobilityData is happy to see this extension moving forward. The process and its outcome are the main key learnings that we want to apply to future specification extensions. 

If you have any thoughts or comments on the process or Fares, please feel free to reach out to us at specifications@mobilitydata.org.