GTFS Fares: One More Pass Before I Send to gtfs-changes

[Brian Ferris]

It's been a few months, which means it's time to take another pass at the GTFS Fares Proposal ; )

I'm trying to make the final push to get the proposal cleaned up enough that it can be sent to the larger gtfs-changes community for discussion.  As such, I've been fleshing out a few sections of the proposal doc that were previously marked as TODO.

Specifically, I worked on the following:

* Documentation of semantics for existing fare rules.

* Discussion of block transfers with respect to the definition of legs.

* Multi-Agency and Multi-Feed Fares

* Some additional semantics and analysis around the proposed contains_id refactoring

* Distance-Based Fares, including two proposed mechanisms for specifying user-defined distances.

* Support for pay-the-difference fares.

* Initial proposal for Fare Products and Eligibility

* Examples for a couple of agencies that use some of the newly proposed fare model features

If you've got some spare time, it'd be cool to get your feedback.  I'm especially interested in feedback on the Distance-based fares, pay-the-difference fares, and fare products proposals.

Also, I'm working on fleshing out the NYC MTA example, which I may ping some of you directly about.

Thanks,

Brian

[Nicholas Albion]

"There is currently no mechanism to specify fare rules to match leg sequences across feed boundaries.  Unfortunately, a number of agencies have requested the ability to define fares, transfers, and other aspects across feeds, but we have yet to come up with a consensus proposal for cross-feed references that would allow this functionality.

It might help if gtfs-data-exchange.com or transit.google.com could publish a GUID for each feed, and if that GUID was included in feed_info.txt. Maybe each GUID source could prefix their GUIDs with a catalogue ID

eg: "gde_001" != "gt_001"

[Nicholas Albion]

Sydney has recently introduced an NFC "Opal" card: https://www.opal.com.au/en/fare-information/

- cheaper than conventional paper ticket fares

- $15 daily travel cap from Monday - Saturday

- $2.50 travel cap on Sunday

- after 8 paid journeys in a week, all journeys after that are free

- 30% off-peak discount for all journeys taken before or after weekday morning or afternoon peaks (7-9am, 4-6:30pm weekdays)

- 60 minute transfer window (starts upon arrival at end of leg)

I think most of this could be addressed by the current proposal + the additions listed below.  The travel caps are a bit tricky - they'd relate to a service_id but might only apply to return trips.  It would be nice to at least have a note displayed by consuming apps.  The free travel after 8 paid trips feature would probably also an informational note, but ultimately it would be good if apps could inform daily commuters of all of the options with accurate pricing.

distance_mode=4 would not suit Sydney buses as currently proposed.  We would need to add zone_id (or section_id) to stop_times.txt and then define fares in fare_attributes.txt for 1-2,3-5,6+ sections/zones.

I'm not sure if distance_mode=5 would suit Sydney trains, but with some clarification perhaps it would.  Fares are calculated based on distance between stops (zones and stop_ids would not need to be considered) in pricing bands for 0-10km, 10-20km, 20-35km, 35-65km and 65+km

In the current proposal, transfer_duration is "from the start of the previous non-transfer leg."  We need to be able to distinguish the difference between "travel for x hours" and "transfer within y minutes of arriving".  Can we add "transfer_window"?

(I'm not too sure on the meaning of "previous non-transfer leg")

Transfer Window

File: fare_rules.txt

Columns: transfer_window

Matches Leg Sequences: Yes

Matches a transfer leg if the start time of the transfer leg is less than transfer_window seconds from the end of the previous non-transfer leg.

fare_rules.txt / route_type

Can we specify multiple route types in a single line using a delimiter?  This is an integer field, so either a pipe or slash should be an acceptable delimiter (we'd have to choose one before publishing the spec)

File: fare_rules.txt

Column: included_trips

Not to be confused with transfers, this is could document multi-use tickets/cards which can be used again on different days or on the same day after the expiration of the transfer_duration.

Fare Attributes

You mention a "priority" field in fare_products.txt.  I wonder how applications could interpret this for different users who had an NFC card, monthly pass or people visiting from out of town for the day.

extra column: included_days - eg: 7,28,90,365

extra column: included_trips - eg: 10

extra column: discount - could be positive, negative or a percentage. ("50%", "0%" or "free"?) would need to indicate which fares the discount is/not applicable to

extra column: start_time - an alternative to tying fares to service_id

extra column: end_time - eg: 28:00 indicates that a ticket is valid until 4am the following morning

Can we provide something more algorithm-friendly than "eligibility_desc" to indicate concession classes?

- disabled: 0/1

- pensioner: 0/1

- school_student: 0/1

- uni_student: 0/1

- min_age: years
- max_age: years

- conc_desc: "Student", "Pensioner/Veteran" etc

[Brian Ferris]

Just to clarify, for "transfer within X minutes of arriving", this means that you have X minutes from the time you tap out of the system (leave the station I'm guessing) to re-enter the system without penalty?

For multiple route types, I'd imagine you'd just have multiple lines in fare_rules.txt, one for each route type.

I'll be honest that I'm a little hesitant to go into a lot of depth describing the specific properties of different fare products and how they would impact the pricing of rides taken later in the day, week, or month.  Specifically, anything that requires knowing that a user just purchased a specific fare product X minutes ago seems to add a ton of complexity to the spec where it's not obvious that there is a big developer demand for this data (maybe I'm wrong)?  At a bare minimum, I'm looking for something that makes users aware that there are different fare products available.  I'd spend more energy fleshing out eligibility and other properties when it's clear that app developers would actually use it in their apps.

--
You received this message because you are subscribed to the Google Groups "GTFS Fare Working Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-fare-wg...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Nicholas Albion]

Yes, it's from the time you tap out.  The proposal currently only seems to allow for "from the time you tap in at the beginning".

When you travel to a new city and you know you're going to be spending a week or so there, it's good to be able to understand all of your options - especially when the zones and/or fare pricing system is complicated.

I know of one app in Sydney that attempts to provide a fare estimate, but I think it's currently a bit naive in that regard - it would be better if their algorithm could be fed by an authoritative data source and updated automatically by the operators, not when the developers got around to reading the new fares.  It sorts the top 5 itineraries based on user-specific criteria which involves a $ cost, but it currently does not take into consideration illegibility for various concessions or discounts.

There's another app for international tourists that would be greatly enhanced if they could let the user select one of the various multi-trip/day options and display it at the ticket booth in big, bold letters.

I'd like to be able to tell the app that I've got a weekly train ticket for all zones (or ultimately for it to read my NFC data via android.content.ContentProvider) and then bump up the train-based itineraries as opposed to trips that involve buses or ferries.  If I was visiting from out of town for the day, then I might be more willing to ride on a bus if it saved me a bit of money and took about the same amount of time.

It will be great for tourists to know exactly which ticket type to ask for, and how much it will cost, but we need to make it clear to them if they don't actually need to buy an extra ticket if they already have a multi-day or multi-trip ticket.  Sometimes though, it's better to buy a $2 ticket if you have, for example, a 10 trip ticket that you paid $30 for.

[T Sobota]

Brian-

  I am in agreement that until feed consuming apps have a robust enough interface to nail down the planned frequency of transit usage of passengers over x amount of time - that the fare rules are best restricted to what is essentially the "worst case" scenario for a single journey by a walk-up customer (typically full cash fare paid upon entry to the system, based on characteristics of a single one-way itinerary).

  On that note, it would be a nice extension to have the fare cost data throw out some warning language if a customer does need to make a special purchase upon entry to the system - to take advantage of say, a discounted supplement needing to paid for a transfer... or a ticket with x amount of zones/distance included.  Otherwise, the "worst case" scenario above could become worse yet - if the passenger tries to re-enter the system at a transfer location but is forced to pay a new full fare since they didn't pay the supplemental cost of a transfer at their origin system entry point.