GTFS Fares v2

[scmcca]

Hi everyone,

We (MobilityData) are opening this issue in regards to fare information in GTFS.

Currently, fares in GTFS are described using fare_attributes.txt and fare_rules.txt. We noticed 2 main issues regarding this current specification:

1. It falls short of detailed payment descriptions, discoverability of fares, points of sale, rider eligibility criteria, transfer rules, and travel conditions (e.g., timeframes, distance).
2. It has not been widely produced or consumed by the GTFS community, perhaps in part because this specification does not reach its full potential for describing fare information.

Therefore, we would like to know your thoughts on describing fares with the current GTFS:

1. Are fare_attributes.txt and fare_rules.txt enough to describe fares? Do they allow accurate fare representation?
2. What are your needs for fare descriptions that are not handled or are badly handled by the current specification?
3. What is your interest in having a new way to describe fares in GTFS?

As you may know, MobilityData has drafted GTFS-Fares v2 to allow for broader descriptions of simple or complex fare structures. But before going further with this project, we would like the input of the GTFS community to know if we are capturing all needs as much and as accurately as possible.

Don’t hesitate to voice your concerns, needs, or general feedback in this issue!

Thanks!

Edits
2021-08-18: Issue renamed from "Fares in GTFS" to "GTFS Fares v2"

[skinkie]

@scmcca within OTPv1 we have implemented a specific fare model for the Dutch (overly complex national) fare systems. I think the primary thing that currently lacks within GTFS fares is the ability to have to have distances (or virtual distances) as part of the fares. In addition to that our national train system even uses a degenerative fare, the longer you travel the cheaper the cost per meter gets, eventually having a price cap.

Even if a fare system could be consolidated to an A-B matrix, things like transfer allowances mess everything up. In my ideal situation the fares should be consolidated to a URI that can be send to a remote system exposing the trip cost. I think we already have discussed this in in #190

[e-lo]

We (The California Integrated Travel Project) believe that travelers should have complete and accurate information about:

• discovering their travel options, including one of the main determinants: the price; and
• how to make a selected trip, including how to pay for it.

1. Are fare_attributes.txt and fare_rules.txt enough to describe fares? Do they allow accurate fare representation?

The current GTFS fares is lacking in several dimensions to be able to achieve our objective above.

2. What are your needs for fare descriptions that are not handled or are badly handled by the current specification?

• Fare typologies such as distance-based and fare caps
• Sufficient information about how to purchase fares
• Some information about fare categories beyond base fares (senior fare, etc)

cc: @mcplanner

[scmcca]

Update on Fares v2:

• The proposal document has been updated with improved syntax, structure, and minor logical corrections for legibility
• We have at least one producer and consumer
• Pull requests for stable pieces of the proposal will be made within the coming weeks to accelerate conversations around different features and to come to a resolution

@skinkie The Fares v2 extension project tries to address the complexity you described. If you see any needs not handled or handled badly by the proposal please feel free to comment on the document or reach out to specifications@mobilitydata.org for your input. It should be kept in mind that Fares v2 aims to significantly broaden the ability to describe fares in GTFS from what is possible in Fares v1, ultimately to provide many more transit riders with this important information. As for the discussions in #190, GTFS-Ticketing is a separate project that will redirect riders to purchase tickets for their travel directly, while Fares v2 aims to display the cost of travel and other fare information in-app. Further work on GTFS-Ticketing will likely come later.

@e-lo There are now proposals for distance-based fares, fare caps, and rider categories in the Fares v2 document. I invite Cal-ITP to review these and whether they cover your use cases. As for how to purchase fares, there is currently a proposal in the Fares v2 document called GTFS-FareDistributions. However, we (MobilityData) want to re-evaluate the proposal to provide more descriptive payment methods and points-of-sale. This may involve a separate but closely related proposal, GTFS-TravelRules, and will likely come after the initial Fares v2 PRs.

[mcplanner-zz]

The current draft covers the use cases with which Cal-ITP is concerned and I don't anticipate any compatibility issues.

[skinkie]

@scmcca which part of the spec handles virtual distances, with a degenerative fares per operator, applied over certain operators including transfers?

[scmcca]

@skinkie

I think the primary thing that currently lacks within GTFS fares is the ability to have distances (or virtual distances) as part of the fares.

Fares v2 handles distances in fare_leg_rules.txt with fields fare_leg_rules.min_distance and fare_leg_rules.max_distance using fare_leg_rules.distance_type to define stop-based distances or as-the-crow-flies distance intervals for a given leg of travel.

In addition to that our national train system even uses a degenerative fare, the longer you travel the cheaper the cost per meter gets

Speaking to the duration of travel, these are modeled using fare_products.txt to describe the valid duration of a given fare product. Duration lengths can be used to define different fare products for progressively longer durations. Linked with fare_leg_rules.min_distance and fare_leg_rules.max_distance you can describe a fare (i.e., cost) that can be used to pay for a leg over X amount of time over distance interval A to B. If modeling every possibility is exhaustive, fields fare_leg_rules.min_amount and fare_leg_rules.max_amount can be used to provide a price estimate interval for many of such combinations.

eventually having a price cap.

The current proposal for fare_capping.txt handles fare capping by defining a certain threshold cost that will not be exceeded for a given time period (i.e., daily cap at $27.00).

Even if a fare system could be consolidated to an A-B matrix, things like transfer allowances mess everything up.

Using the concept of defining fares for individual legs of travel in fare_leg_rules.txt, transfers between individual legs and the resulting price are processed in fare_transfer_rules.txt. See fare_transfer_rules.fare_transfer_type for the different processing options.

In my ideal situation the fares should be consolidated to a URI that can be send to a remote system exposing the trip cost. I think we already have discussed this in #190.

This will be handled distinctively in a subsequent project. The goal of Fares v2 is to display the cost or estimated cost of travel in-app. GTFS-Ticketing will provide the redirect link to purchase tickets.

which part of the spec handles virtual distances, with a degenerative fares per operator, applied over certain operators including transfers?

For an example dataset of Fares V2 with multiple agencies, see MTC's Regional (RG) GTFS dataset produced by Interline (cc: @drewda).

If we missed something major, we are always open to scope emergent needs and produce a needs analysis for modeling additional features.

[jakluk]

Hi, @scmcca is there any reference implementation/tool where producers can check if their fare definition works correctly in various scenarios?

[gcamp]

Similar to @jakluk, we're looking for sample data set to work with for our implementation on the consumer side.

[drewda]

Hi @jakluk and @gcamp, for an example feed created following the draft spec, see the SF Bay Area's Regional GTFS Feed. Overview in this blog post (with download instructions at the end): https://www.interline.io/blog/mtc-regional-gtfs-feed-additions/#fares-and-transfer-discounts

[jakluk]

Maybe I didn't explain myself well, we (Prague Integrated Transport) would like to try Fares v2 with our GTFS feed, but we need a tool or existing routing engine where we could check if the data produced by us is correctly understood by the consumer. The spec is quite comprehensive and there could be misunderstandings about correct behavior on both sides.

[drewda]

An update from Interline and MTC. We have now released a new version of fares v2 data for 8 of the San Francisco Bay Area's key transit agencies. This is an update to both our tooling (to support the latest version of the proposed spec) and to the data itself (to reflect some changes to agency's fares since last year).

Quick instructions on how to download the Bay Area Regional GTFS Feed, including the latest fares data, are as before at the bottom of the blog post at https://www.interline.io/blog/mtc-regional-gtfs-feed-additions/#using-fares-and-transfer-discounts

We are assembling a few notes on the experience of implementing data in the current version of the spec, as well as running a "rules engine" against it to calculate the costs of journeys. Will share some bullet points for others shortly.

[scmcca]

Hi everyone, here's a quick update on GTFS Fares v2.

Producers and Consumers

Over the past few months MobilityData has been supporting early implementors in getting this project up and running. I'm pleased to say that as of now we have at least 3 producers and 1 consumer for a subset of the proposal.

Here is a collection of producers, consumers, and open data sets with a detailed account of what exactly is being produced/consumed: https://bit.ly/gtfs-fares-adoption.

If there are any other producers and consumers out there please contact specifications@mobilitydata.org with the subset that you are producing/consuming so we can take inventory!

A summary of whats in the spreadsheet:

• Producers
  • Interline (cc @drewda, MTC Bay Area)
  • Cal-ITP (cc @mcplanner @e-lo, 50+ agencies!)
  • Maryland DOT (cc @SteveGladstone)
• Consumers
  • Transit App (cc @gcamp)

Note that only the base of Fares v2 is covered (and technically adoptable), but is already more detailed than the current fare_rules.txt and fare_attributes.txt found in v1 of fares. For example, the use of O-D areas and passes (i.e., fare products). We're hopeful that coverage of the functionalities modelled in Fares v2 will improve as more data get produced and consumers expand their code.

Transit's Fares v2 Validator

Transit App has made public their internal Fares v2 validator. It covers the subset that they are consuming, and may be useful to producers putting together data.

Slack

I highly recommend everyone join the #gtfs-fares MobilityData Slack channel. A ton of great brainstorming and problem solving has been happening over there that has been integral to the progress made on fares thus far. If you aren't already a part of MobilityData's slack workspace, contact specifications@mobilitydata.org and we'll send you an invite :)

Next steps

Fares are a key part of rider decision making. Being able to model fares properly using GTFS has the potential to improve that decision making and improve the rider experience. With this, the end goal here is to have an official way to model fares in GTFS where the current model lacks. We've seen a ton of effort and collaboration across parties to solve this problem with the detailed proposal of Fares v2.

With a base implementation in effect, the potential to expand Fares v2 as the way to model fares in GTFS is clear. However, it is up to the community what becomes official. If there are any concerns about the proposed model and what it covers or will be able to cover, now is the time to voice those concerns. I invite a thorough review of the proposal document if you have not done so already, and to add any comments or suggestions.

Otherwise, we are continuing the momentum to support implementors in anyway we can. Feel free to reach out!