Welcome to the GTFS Fares Working Group!

[Brian Ferris]

Thanks to David for setting up the group.  Let's get down to it.  As you may recall, here was the original proposed plan:

1) Do a literature search of existing fare models, fare data standards, and other existing work to map out the space of fare systems we'd like to cover.  The good news is that a lot of work has already been done in this space and we can stand on the shoulders of giants, so to speak.

2) Run the results of #1 by the larger community to see if we've missed anything.  Iterate and repeat.

3) Stare really hard at the wall to think about how we might model these fare systems in a GTFS-friendly way, either extending the existing fare model or coming up with something new as needed.

4) Assuming heads don't explode in step #3, profit.

Assuming that sounds reasonable, let's talk about step #1.  Our main task is to enumerate and categorize as many public transit fare systems as we can find.  As already discussed on gtfs-changes, I think there are two aspects to consider for a fare system:

1) The physical fare calculation model.

2) The various fare products that can be used by riders.

I think it's true that #1 is top priority for me and #2 is less so, but it may be difficult to separate the two in some cases, so we may have to consider them both regardless.

To get started, I propose we create a shared document that everyone can edit to add notes about the fare systems we know and care about, which the group can then organize and annotate with notes about what those fare systems have in common and what makes them unique.

https://docs.google.com/document/d/1gqR91vncy9SXPHvWmV9EKlqADW0tyQxqLMfQRV_3FWA/edit

I'm a big fan of Google docs, but I do work for Google, so if someone would like to propose something else, it won't hurt my feelings too badly.

Also, definitely check out the FareXChange link that Roger sent out:

http://www.dft.gov.uk/transxchange/farexchange/index.htm

Definitely a good place to start.

Brian

[Aaron Antrim]

Thanks, Brian.

I'll look at this next week.  I have this week blocked out to work on some other projects.

[David Turner]

Brian has shared a Google doc with group members. I just added NYC to
the sheet. I think we should only list systems if they cannot
reasonably be implemented using the existing fare rules. To provide
some background, this thread contains Google's interpretation of the
existing system:
http://groups.google.com/group/gtfs-changes/browse_thread/thread/8a4a48ae1e742517/4f81b826cb732f3b

The document mentions free ride areas. Couldn't these be implemented
using the current zone system? That's what TriMet used to do when
Fareless Square existed.

Finally, one concept that I would totally go for, but which probably
nobody else would like:

The Securities and Exchange Commission once had a problem where they
wanted to learn about certain complex transaction provisions. Rather
than generating a schema itemizing all of the possible provisions and
their interactions, they simply required banks to submit a Python
program that would take input assumptions and turn them into an
explanation of what the transaction would do.

We could totally do this for fares. It would be simple to specify, and
the individual fare models would be easy to code. For technically
less-sophisticated transit agencies, we could provide some standard
examples that they could modify. And volunteers could probably be found
for agencies that can't even do that.

[Frédéric Thouin]

Are the fare systems used by most intercity/coach/long-distance buses within the scope of this discussion or the focus is limited to public transit fare systems?

[David Turner]

I think we would like to cover as many cases as we can, including
long-distance cases.

Do you have some interesting examples there?

[Brian Ferris]

I'm +1 on that as well.

[Frederic Thouin]

Well, there are a few different models used by long-distance buses agencies.

• Origin-destination based: prices are generally driven by the first and last stop of the journey.  This is similar to zone-based system, but where each zone is a different city.
• Class-based: some buses have different ticket categories, such as first class where seats can be converted to beds for longer journeys.  This is different than discounts for students/seniors/etc because they could be combined (e.g. senior + first class fare).
• Service-based: the bus that leaves in the morning could have a different price than another service later in the day.  This is similar to a time-of-day fare system, but you could have simultaneous services with different classes available (i.e. one with sleeper seats and the other one without).
• Date-based: some companies have prices that vary based on the date of travel and how far ahead the ticket is purchased. Megabus is a good example: they have 1$ fares for some routes if the ticket is purchased weeks in advance.

[David Turner]

On Mon, 2012-07-09 at 16:04 -0400, Frederic Thouin wrote:
> Well, there are a few different models used by long-distance buses
> agencies.

> * Origin-destination based: prices are generally driven by the

> first and last stop of the journey. This is similar to
> zone-based system, but where each zone is a different city.

This seems possible within the current zone-based system.

> * Class-based: some buses have different ticket categories, such

> as first class where seats can be converted to beds for longer
> journeys. This is different than discounts for
> students/seniors/etc because they could be combined (e.g.
> senior + first class fare).

Do you think that people would want information about what the
differences between fare classes are? Or is it enough to have short
textual descriptors like "first class"?

Also, given that senior fares are likely to be somewhat idiosyncratic or
non-normalized, is it possible to simply flatten the list of fares to
the cartesian product of fare class x discount? This would account
better for cases like Amtrak, where "the senior discount does not apply
to Business class, First class or sleeping accommodation."

> * Service-based: the bus that leaves in the morning could have a

> different price than another service later in the day. This
> is similar to a time-of-day fare system, but you could have
> simultaneous services with different classes available (i.e.
> one with sleeper seats and the other one without).

Would it work to represent this by a service_class field in trips.txt
and a service_class limitation in the fare rules?

> * Date-based: some companies have prices that vary based on the

> date of travel and how far ahead the ticket is purchased.
> Megabus is a good example: they have 1$ fares for some routes
> if the ticket is purchased weeks in advance.

Yeah, Megabus is a bit closer to airline pricing, which is so
complicated that Orbitz needs an army of Lisp hackers just to find your
fare.

Fortunately, Megabus fares (at least in the US) can't be combined with
other fares. In this case, the right approach might be to encode
min/max fares in the GTFS, and, optionally, define an API for current
fares.

Whether Megabus or anyone else would publish to that API is kind of an
open question. I guess we should just leave that part of the spec open
until we have a producer.

[Frederic Thouin]

On Mon, Jul 9, 2012 at 5:23 PM, David Turner <nov...@novalis.org> wrote:

On Mon, 2012-07-09 at 16:04 -0400, Frederic Thouin wrote:
> Well, there are a few different models used by long-distance buses
> agencies.

>       * Origin-destination based: prices are generally driven by the

>         first and last stop of the journey.  This is similar to
>         zone-based system, but where each zone is a different city.

This seems possible within the current zone-based system.

Correct.  In the case where the price also depends on the route, can the route_id field in fare_rules.txt can be used jointly with destination_id and origin_id?

 

>       * Class-based: some buses have different ticket categories, such

>         as first class where seats can be converted to beds for longer
>         journeys.  This is different than discounts for
>         students/seniors/etc because they could be combined (e.g.
>         senior + first class fare).

Do you think that people would want information about what the
differences between fare classes are?  Or is it enough to have short
textual descriptors like "first class"?

I think there are some classes which are self-explanatory, but others, such as first class, are a little more vague and require more explanations.  

If class and discount are added to fare_attributes, there could also be a field called features with a normalized list of features available with this fare that help clarify what the class implies.

 

Also, given that senior fares are likely to be somewhat idiosyncratic or
non-normalized, is it possible to simply flatten the list of fares to
the cartesian product of fare class x discount?  

Yes, definitely.  

 

This would account
better for cases like Amtrak, where "the senior discount does not apply
to Business class, First class or sleeping accommodation."

>       * Service-based: the bus that leaves in the morning could have a

>         different price than another service later in the day.  This
>         is similar to a time-of-day fare system, but you could have
>         simultaneous services with different classes available (i.e.
>         one with sleeper seats and the other one without).

Would it work to represent this by a service_class field in trips.txt
and a service_class limitation in the fare rules?

I think that would work.  If a list of features is added to a given fare, that would be a good way to associate the same set with an entire service.

 

>       * Date-based: some companies have prices that vary based on the

>         date of travel and how far ahead the ticket is purchased.
>         Megabus is a good example: they have 1$ fares for some routes
>         if the ticket is purchased weeks in advance.

Yeah, Megabus is a bit closer to airline pricing, which is so
complicated that Orbitz needs an army of Lisp hackers just to find your
fare.

Fortunately, Megabus fares (at least in the US) can't be combined with
other fares.  

What do you mean?

 

In this case, the right approach might be to encode min/max fares in the GTFS, and, optionally, define an API for current

fares.

That makes sense.  What about median price?  Could also be useful if the [min-max] range is large.

[Brian Ferris]

Regarding the combination of route_id and destination_id/origin_id in fare_rules.txt, the spec doesn't actually specify what should happen.  It seems kind of logical to allow for it, but the case isn't spelled out in the Fare Examples page: http://code.google.com/p/googletransitdatafeed/wiki/FareExamples

There are a couple of other semi-ambiguities in the fare rules and fare attributes spec that are probably worthy of their own post.