GTFS-Fares v2 - Second implementation

[omar-kabbani]

Update on GTFS-Fares v2

Hello everyone, this issue is to present MobilityData's next steps on GTFS-Fares v2 to keep the community updated as well as to hear everyone's thoughts on this.

We are very happy to announce that 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 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, proposal here)

The data producer and consumer for the second implementation of GTFS-Fares v2 are:

• Consumer: Apple
• Producer: Interline

Timeline:

We are planning to open separate pull requests for features that do not overlap to keep focus on the discussions and facilitate the consensus building process.

Week of August 1:

Open pull requests for:

• Variable pricing by time of day, or by day of week, month, or year
• Fare containers

The above two features are straightforward, and MobilityData does not foresee any challenges to reaching consensus within the community. We are comfortable with opening pull requests and going through the GTFS change process leading up to a vote at this time.

For the remaining features, more time is needed for conversations to close out open issues and come to consensus. Hence, below is the plan for moving forward with regards to these features:

Open GitHub issues for:

• Allowing multiple routes to behave as a single route (transfer rules ignored)
• Zone-based fares
• Inter-agency transfers (using fare_leg_rules.transfer_only, proposal here)

Week of August 8:

• Discussions with the community on the three open GitHub issues.

Week of August 15:

• MobilityData will share a summary of the GitHub discussions.

Week of August 22:

• If the items are still unresolved, MobilityData will host three meetings with interested stakeholders to close them out. Full details on the days and times of the meetings will be posted in each issue.

Week of August 29:

• MobilityData will share a summary outlining the outcomes from the stakeholder meetings.

Week of September 05:

• For the issues that have been resolved, MobilityData will open pull requests and go through the GTFS change process leading to a vote.

Week of September 12:

• If there still are unresolved issues, MobilityData will facilitate another round of community discussions to close out any outstanding issues.

Week of September 19:

• MobilityData will share a summary outlining the outcomes from the stakeholder meetings. If the issues have been resolved, MobilityData will open pull requests and go through the GTFS change process leading to a vote.

[omar-kabbani]

Summary of discussions on GTFS-Fares v2 second implementation:

Hey everyone, as mentioned before; MobilityData is working on adding 5 new features to GTFS-Fares v2, below is a brief summary on the discussions around those features:

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

• Discussion on whether timeframe_id should be tied to a service_id (should the times where the different fares are in place be tied to service days when they are being defined in calendar.txt or in timeframes.txt?).
• In the current proposal, the modified fares are in effect if the trip starts in from_timeframe_id and ends in to_timeframe_id. The discussion on whether two fields are necessary is ongoing as well as if there is a different way to model this.
• Discussion on whether information regarding the time and days that affect fares should be in fare_leg_rules.txt or fare_products.txt.
• Should additional information such as when is the fare activated be included (on tapping, boarding, departing, etc.)?

Fare containers

• Ambiguity regarding the cost of fare containers (the fields amount and minimum_initial_purchase are unclear).
• Discussion on the scope of the proposal (describing fare products vs. integrating information on loading the fare container with additional funds)
• Ability to add information on the type of fare container.

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

• There is an ongoing discussion on the scope of this proposal. MobilityData envisions the field to be used to describe transfers that do not require any fare validation (no fare checking, tapping, or going through fare gates).

Zone-based fares

• After a short discussion, there is a general agreement to proceed with this proposal by Transit.

Inter-agency transfers (using fare_leg_rules.transfer_only)

• There has not been any discussions around this proposal. MobilityData sees this as a sign that there is a general agreement around this.

Next steps: Roundtable discussions

In order to effectively resolve these issues above, MobilityData will host 2 roundtable calls next week:

• Wednesday 24 August 11:00 AM ET: Variable pricing by time of day, or by day of week, month, or year + Allowing multiple routes to behave as a single route (transfer rules ignored)
• Thursday 25 August 11:00 AM ET: Fare containers

If you want to attend those meetings - please react to this message or send an email to [email protected] and we will send you the meeting invite!

[isabelle-dr]

Hello everyone, I will continue the work Omar started with the second implementation of Fares v2, on MobilityData's behalf.
We are thrilled to see that GTFS-Fares v2 is being implemented, and we hear the need to continue moving this extension forward, so that collaboration is more efficient for everybody.
MobilityData will work on the 5 features listed here, to hopefully have most of them adopted by the end of the year.
We are picking up where we left off, and just as Omar did, I will:

• open different Pull Requests for each feature to keep the focus for each discussion
• post summaries of the discussions happening on GitHub and in roundtable discussions
• host meetings to resolve issues, as needed
• post what the next steps are

You'll find below what MobilityData is planning to do in the following weeks. As we move forward, this comment will be the source of truth for knowing what will happen and when. I used a table in an attempt to make this as clear as possible.
As we move forward, I will edit this table with the latest information, and add notes at the bottom to inform what has changed.
We also have a slack channel dedicated to Fares v2. If you'd like to join, please fill out this form to get an invite, and join the #gtfs-fares channel.

	Fare Containers	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)	Allowing multiple routes to behave as a single route (transfer rules ignored)
Week of October 31	Re-open a Pull Request	Re-open a Pull Request
Week of November 7	Discussions in the Pull Request	Discussions in the Pull Request
Week of November 14	Solve outstanding issues, leading to a vote	Solve outstanding issues, leading to a vote
Week of November 21	Solve outstanding issues, leading to a vote	Solve outstanding issues, leading to a vote
Week of November 28	Roundtable discussions	Roundtable discussions	Roundtable discussions	Roundtable discussions	Roundtable discussions
Week of December 5	Modify proposal according to feedback
Week of December 12	Solve outstanding issues

Changes

2022-12-06 Modify based on roundtable discussion feedback: added vote for fare containers for the week of December 12
2022-11-22 Update timeline based on community feedback and level of consensus with current proposals
2022-11-10 Updated timeline to reflect that no producer/consumer is confirmed for Zone-based, Inter-agency, On-route, and that the requirements need to be clarified first.

[isabelle-dr]

Summary of discussions on GTFS-Fares v2 second implementation:

Hey everyone, MobilityData is continuing to work on adding 5 new features to GTFS, below is a brief summary of the progress made for each of these since the last Summary was posted by Omar.

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

• The 2 fields from_timeframe_id and to_timeframe_id are required to effectively describe time-based fare calculations.
• Most time-dependant fares only depend on the start time, it seems more intuitive to only specify from_timeframe_id and have to_timeframe_id default to “all day” in fare_leg_rules.txt if left blank, but this would go against the default behavior of other blank fields in fare_leg_rules.txt and this might add complexity.
• The “event” that starts the clock for the special fare to apply can be triggered by the rider (joins a trip or joins a station) or by the trip (when the vehicle leaves). Ongoing discussion around how to model this.
• On-going discussion on whether information regarding the time and days that affect fares should be in fare_leg_rules.txt or fare_products.txt.
• Discussion around more general issues with the blank field behavior in fare_leg_rules.txt and fare_transfer_rules.txt.

Fare containers

• Discussions around increasing the scope of this feature to display how a fare can be paid (using a fare container, credit card, or cash).
• Some transfer rules depend on the fare container or payment type used. Because the container is defined in fare_products.txt, we need to revisit how fare_products.txt, fare_transfer_rules.txt, and fare_products.txt work together.

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

• Nothing new since the last message

Zone-based fares

• There is a general agreement to proceed with this proposal by Transit. The public Google Doc has been modified to reflect it.

Inter-agency transfers (using fare_leg_rules.transfer_only)

• It seems like having inter-agency transfers within the same dataset doesn’t add much value for the community, and there is a need to model inter-agency transfers between two different datasets.

Next steps: roundtable discussions

In order to effectively resolve these issues above, MobilityData will host 2 roundtable calls next week. You can access the two events on this calendar.

• Wednesday 30 November 11:00 AM ET: Discriminating factors and design principles for GTFS Fares-v2
• Thursday 1 December 11:00 AM ET: Variable pricing by time or day, Fare containers

[drewda]

Thank you for all these notes, @isabelle-dr.

For reference, here are the proposed spec additions to GTFS-Fares v2 for which Interline and MTC are producing data in the SF Bay Area Regional GTFS Feed: https://www.interline.io/blog/mtc-regional-gtfs-feed-fares-updates/#gtfs-fares-v2-base-implementation-and-future-additions-to-the-specification

As we do not currently have need for variable pricing by time and our needs for fare containers are already met by the existing proposal, we won't plan on joining these two calls.

Note that the SF Bay Area Regional Feed does make use of the extensions proposed in #346, #344, and #345 and we look forward to those also being brought up again for adoption.

[isabelle-dr]

Summary of the roundtable discussions

Sorry, it's a long post. This is an overview of the progress made on GTFS-Fares v2 last week. It covers a wrap-up of the two roundtable discussions, and the proposals drafted and shared right after.

A word about the meeting agendas

The first discussion was dedicated to aligning on: major fare discriminating factors, where to represent them, and design principles for how fare_leg_rules.txt, fare_transfer_rules.txt, and fare_products.txt work together.
For the second discussion, we decided to pivot from the original agenda and work on a visualization of all the issues and needs discussed, and prioritize what to solve next based on value for travelers, commitment to implement, and the “easiness” to reach consensus and adopt.

Results from the prioritization exercise

From top to bottom. For more details about these features and how we ended up with this order, read the rest of this post.

Feature	State
Fare Containers	Actively working to adopt. MobilityData will open a vote as soon as consensus is reached and the payment type concept has been tested by producing and consuming stakeholders.
Variable pricing by time of day, or by day of the week, month, or year	Actively working to adopt. MobilityData will work on modifying the proposal based on feedback and open a vote in Q1 2023
Separation of fare fields & files from schedule fields & files so they can be produced separately	Workin on design and building soft consensus
Implement a way to capture the state of legs in journeys (state machine)	Workin on design and building soft consensus
Multi-leg sub-journeys with origin-destination pricing (“as-route” behavior)	Workin on design and building soft consensus
Zone-based fares	Workin on design and building soft consensus
Empty fields semantics	Workin on design and building soft consensus
Override ability (when multiple rules match)	Workin on design and building soft consensus
Inter-agency transfers	Scope needs to be defined (same dataset, or cross-dataset references?)

Overview of discriminating factors that come into play to calculate the accurate price of a journey

• The type of fare product bought (monthly pass, single ride, bundle)
• Zonal factors
  • Zones where the rider starts, ends or goes through (group of neighborhoods, cities, etc)
  • Length of the trip (number of stops traveled, length traveled, crowd-fly)
  • Routes traveled, networks traveled
• Temporal factors
  • Time of day, day of week, day of year
  • Price for a special event
• Payment method (credit card, cash) and fare container where tickets are loaded (transit card, paper ticket)
• Rider category (age, social or physical conditions)

These factors interact with one another. The price of a journey can be described with only two of these factors, or all of them.

Where to represent discriminating factors + how fare_products.txt, fare_leg_rules.txt and fare_transfer_rules.txt interact with one another

• Fare Products
  • Discussion around what we mean by "fare product" (a list of physical tickets a user can buy, or a list of products that have unique behaviour when modeled into a journey (physical or virtual).
  • Since the current focus is to represent accurate pricing in trip panning, there seems to be consensus around having fare products as a group based on their behaviour when modeled into a journey. A group of fare products with the same fare_product_id is considered a group.
  • Fare products can be grouped when needed (when the same leg and transfer rules apply to several products) and separated when needed (if two products can’t be used in the same zones or during the same time of day).
  • In a later iteration, we can imagine using fare products to display a list of “physical” products sold by an agency.
• Zonal factors: they were modeled in fare_leg_rules.txt in the base implementation. To preserve backward compatibility, this will not be modified.
• Temporal factors: modeling off-peak and peak time fares may require temporal factors to be in a separate file.
• Payment methods, fare containers, and rider categories are modeled into fare_products.txt.

Design principles for the leg and transfer rules files

• We need to introduce an override ability to simply represent cases when some matching rules need to take precedence over others. Proposal shared by ITO World: Ito Fares Proposal: Override.
• Empty field semantics pose a problem when handling two different fare networks in the same feed. Proposal shared by Brian Ferris at Google: https://bit.ly/gtfs-fares-v2-fare-leg-rules-scope-proposal.
• We need to be able to capture a transfer that already happened, and the “state” of legs in a journey.
  • Proposal shared by ITO World: Transfers -with-output_leg_group.
  • Proposal shared by Brian Ferris at Google: https://bit.ly/gtfs-fares-v2-finite-state-machines.
• There is a need to improve what we can capture with transfers, especially when modeling discounts between agencies.
  • TransitApp previously proposed fare_leg_rules.transfer_only and fare_transfer_rules.filter_fare_product_id to handle inter-agency transfer discounts within the same dataset, and it's used in Interline's MTC dataset.
  • ITO World shared a broader proposal to refer to features in other datasets Ito Fares Proposal: Cross Dataset Namespaces. This could be compared against the existing GTFS-References proposal by Cal-ITP: http://bit.ly/gtfs-references.
• Multi-leg sub-journeys with origin-destination pricing are difficult to model.
  • The experimental routes.as_route field is part of the next iteration.
  • Another proposal was shared by Brian Ferris at Google https://bit.ly/gtfs-fares-v2-fare-leg-join-rules-proposal.

Fare Containers

We ultimately want this to be able to:

• Show riders what they can bring with them to pay for the rider (transit card, contactless credit card, cash, etc).
• Be able to represent that a fare product price can be different if loaded on a transit card or not.

We need to explore how fare containers and payment types can work together, and possibly merge these concepts. This means that “Fare Container” would need to be defined more clearly and renamed.

Other discussion points

• Need for separation of fare-related fields from routes.txt and stops.txt so fares can be published separately from schedules.
• There is an interest in having regular synchronous discussions about the advancement of GTFS Fares v2. MobilityData will make a proposal on how these regular check-ins could work with the GitHub discussions and time zones. If the community generally thinks this is easier, MobilityData will put them in place in early 2023.

[isabelle-dr]

Hello all,

We at MobilityData are excited to continue to work towards the adoption of GTFS-fares v2. In the last meeting we had about the topic, we heard you on the value of having synchronous meetings, and having predictability in how/when your attention is needed.
We will be hosting monthly meetings every third Tuesday, to work through the open proposals, and MobilityData commits to preparing them, allow who can’t attend to share their input easily, publishing summaries, helping draft solutions, and make sure proposals are in-line with GTFS.

The first meeting of the year is tomorrow, Tuesday January 24th at 11 AM ET.
You can find the meeting agenda and Zoom link here: https://mobilitydata.org/event/specifications-discussions-gtfs-fares-v2-january-meeting/.

[isabelle-dr]

Here is a summary of the call we had yesterday.

Subject: fare payment options Pull Request #355 and proposal (previously called Fare Containers)
Main takeaways (see all the meeting notes here)

• We confirmed the need to create fare payment option groups that we can reference to in fare products so that we don't duplicate records in fare_products.txt to enumerate fare payment options.
• The current proposal with one added fare_payment_options.txt table has the following caveat: if not all fare product prices vary in the same way regarding fare payment options, this creates a conflict: either we need to have the same payment option in more than one group (which creates a problem the day we want to expand fare_payment_options.txt with additional info regarding payment options), or we end-up with some enumeration of fare payment options in fare_products.txt (which is what we are trying to avoid).
  • solution: adding a fare_payment_option_groups.txt table, and associating either a single fare payment option or a fare payment option group to fare products.
• We discussed the case where a transfer only applies when the same payment option is used (such as a credit card), and figured that this problem joins Transit's Should fare transfers require that the same fare product is used on both legs? argument.
• We discussed three cases around the fare_payment_option_type field:
  • Representing non-contactless bank cards
  • Representing specific bank cards accepted (MasterCard and VISA but not Amex)
  • Representing additional information around how to validate the fare product (scanning a code, visual validation, etc)
    • solution: since we didn't reach a consensus during the meeting, we are hosting another 30min call to clarify the representation of these use cases.
    • EDIT: We couldn't reach a consensus in the follow-up meeting, MobilityData will work on clarifying further stages of payment information in GTFS to ensure what we adopt now won't block further iterations.

Next steps:

• MobilityData modifies the proposal to add a fare_payment_option_groups.txt file for the grouping mechanism as discussed.
• A second 30min discussion on January 26th from 11 to 11:30 AM ET to make a decision for the fare_payment_option_type field. Please write to [email protected] if you're interested in joining. The meeting notes are in the same document.

[isabelle-dr]

Here is a summary of the working group discussion on February 28, 2023.
The meeting notes are publicly available here.

• There are no major outstanding blockers with the PR for fare media. Ready for a vote soon!
  • Some minor edits
  • Some topics ripe for best practices clarification (ex: can a paper ticket have a magnetic strip? What does none mean?)
• The group confirmed the current prioritization
  • Fare Media (nearly ready for vote)
  • Time variable fares
  • Separating out schedule info from fares info
    • Note: long-term desire is to be able to publish separate .zip folders. Group consensus is for phase 1 – separating the information in routes.txt and stops.txt so that those files don’t have fare info (only schedule).
• Everyone will review the variable fares (time of day, day of week, day in year) and comment on any nagging issues that need to be resolved

[isabelle-dr]

Hello all, now that we have a working group with monthly meetings and public meeting minutes, as well as a Fares v2 page on gtfs.org that contains the latest information & backlog, I propose we close this issue.

If anyone still sees value in the updates on this issue, please let us know in the next 7 days and we will continue posting updates here.

[isabelle-dr]

Closing this issue, please see the latest in the public meeting notes.
All high-level information about GTFS Fares-v2 is available at https://gtfs.org/schedule/validate/