Fares

[Brian Ferris]

I'm always a little torn when a proposal to extend the GTFS fares model comes up, because it sometimes feels like rearranging deck chairs on the Titantic ; )  Which is to say, if you've worked much with the fares model at all, you've probably realized it:

a) doesn't cover a lot of fare models used by agencies in practice

b) has a number of ambiguities in the spec for the cases it does cover

I recognize that fares are hard in the "here there be dragons" sense and I definitely appreciate the efforts of those to extend the existing model, but I'm wondering if it might be worth stepping back and taking a large look at the GTFS fares model in general.

Here's the idea:

We put together a GTFS Fares working group.  This would be a motivated subset of the larger GTFS-changes community, tasked with the following:

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.

I recognize that this is a process fraught with peril that very may well up as "it is not possible to model all the fare systems we care about" but I do think it's worth taking a more focused look.  I think we've been pretty fortunate that GTFS has managed to grow so organically based on the strong foundation laid by our transit-nerd-ancestors, but I think fares are one place we can do better.

Thoughts?  Any fare nerds out there?

Brian

[David Turner]

On Fri, 2012-06-29 at 14:55 +0200, Brian Ferris wrote:
> I'm always a little torn when a proposal to extend the GTFS fares
> model comes up, because it sometimes feels like rearranging deck
> chairs on the Titantic ; )
>

That's definitely true. However, one of the advantages of the current
proposal is that it integrates well with the current model, which, for
all its limitations does model a number of systems. I think that even
if we start a working group, it might make sense to accept the current
proposal in the interim.

> Here's the idea:
>
> We put together a GTFS Fares working group. This would be a motivated
> subset of the larger GTFS-changes community, tasked with the
> following:

> Thoughts? Any fare nerds out there?

I'm willing to participate in this. I would like to try to agree to a
reasonable time schedule to help us keep on track and to prevent scope
creep. To that end, we may need to decide on a reasonably extensible
fare standard, and backfill missing parts after the initial release.

[Aaron Antrim]

I would participate. I could offer an inventory of fare schedules in Trillium's client base, and cases where we cannot describe the fare schedule in the current GTFS.

> --
> You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
> To post to this group, send email to gtfs-c...@googlegroups.com.
> To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.
>

[Wojciech Kulesza]

Same here.
Count goEuropa in. We got at least two agencies that have distance-based fare system that we could try and model

Wojciech

--
Wojciech Kulesza,
Właściciel

goEuropa Polska
ul. H.Szafran 1
60-693 Poznań Polska

[m] +48 609 689230
[t] + 48 61 6248682
[@] wojciech...@goeuropa.eu

[David Turner]

OK, 4 is a crowd, so I've set up a list:

http://groups.google.com/group/gtfs-fare-wg

On Fri, 2012-06-29 at 13:59 -0700, Frédéric Thouin wrote:
> We manage schedules of a group of long-distance bus operators. Most of their pricing systems cannot be represented easily (or even not at all) with current GTFS. I would be happy to participate in these discussions.
>
>
> On Friday, 29 June 2012 08:55:45 UTC-4, Brian Ferris wrote:
> > I'm always a little torn when a proposal to extend the GTFS fares model comes up, because it sometimes feels like rearranging deck chairs on the Titantic ; ) Which is to say, if you've worked much with the fares model at all, you've probably realized it:
> >
> >
> > </div>
> > a) doesn&#39;t cover a lot of fare models used by agencies in practice</div>
> > b) has a number of ambiguities in the spec for the cases it does cover</div>
> >
> > </div>
> > I recognize that fares are hard in the &quot;here there be dragons&quot; sense and I definitely appreciate the efforts of those to extend the existing model, but I&#39;m wondering if it might be worth stepping back and taking a large look at the GTFS fares model in general.</div>
> >
> >
> > </div>
> > Here&#39;s the idea:</div>
> >
> > </div>
> > We put together a GTFS Fares working group. This would be a motivated subset of the larger GTFS-changes community, tasked with the following:</div>
> >
> >
> > </div>
> > 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&#39;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.</div>
> >
> >
> > </div>
> > 2) Run the results of #1 by the larger community to see if we&#39;ve missed anything. Iterate and repeat.</div>
> >
> > </div>
> > 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.</div>
> >
> >
> > </div>
> > 4) Assuming heads don&#39;t explode in step #3, profit.</div>
> >
> > </div>
> > I recognize that this is a process fraught with peril that very may well up as &quot;it is not possible to model all the fare systems we care about&quot; but I do think it&#39;s worth taking a more focused look. I think we&#39;ve been pretty fortunate that GTFS has managed to grow so organically based on the strong foundation laid by our transit-nerd-ancestors, but I think fares are one place we can do better.</div>
> >
> >
> > </div>
> > Thoughts? Any fare nerds out there?</div>
> >
> > </div>
> > Brian</div>
> >
> > </div>
> >
> > </div>
>

[Aaron Steinfeld]

One thing to consider, which may or may not help simplification, is the intersection of fares, peak/off peak, and user demographics. For example, seniors and people with disabilities are often in different fare classes. Some college students have bus passes for some of the local agencies, but not all. Primary and secondary students might have free rides during busing hours, but not during other times, etc. Therefore, looking at fares from an multidimensional array perspective, rather than a flat list, might help. 

This would also make it easier for client software to report fares based on end user preferences (e.g., Calculate fares using senior rates Y/N).

Aaron

[Aaron Antrim]

On Fri, Jun 29, 2012 at 2:17 PM, Aaron Steinfeld <aaron.s...@gmail.com> wrote:

One thing to consider, which may or may not help simplification, is the intersection of fares, peak/off peak, and user demographics. For example, seniors and people with disabilities are often in different fare classes. Some college students have bus passes for some of the local agencies, but not all. Primary and secondary students might have free rides during busing hours, but not during other times, etc. Therefore, looking at fares from an multidimensional array perspective, rather than a flat list, might help. 

I think considering fares based on customer qualifications (senior, youth, etc.) is a different problem.  First we need to figure out how to define fare structures (defined through zones, time-based: peak/off-peak, routes, transfers).  Then, if there's a need to define separate fare structures for different customers, another part of the spec can be added that defines eligibility criteria.  I think eligibility criteria will be pretty complicated; it may be difficult to define a universal spec.

[Roger Slevin]

The most comprehensive study on the requirements for a fares protocol that I am aware of was undertaken in the UK (where we have particularly complex fares systems because they are essentially commercially determined by each operator).

 

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

 

This work has been an input to the Eiuropean work currently under way to define a Fares Exchange protocol within NeTEx.  This is on-going work - and I will need to find out what, if anything, is available to describe what is envisaged within that emerging European Standard.

 

What both pieces of work confirm is that a universal protocol for the handling of fares is far from trivial.  And whilst the UK work tried to cover all approaches to fares structures worldwide, I suspect that there are some local variations that may not have been fully covered in the Farexchange work.

 

Roger

--

[Brian Ferris]

I have looked at this work as well, and it's definitely something I plan to include in our synthesis.

[Neil Taylor]

Just picking up on David's point... does anyone object if, in the interim, the current proposal is accepted in order to enable us to move forward with the definition of distance-based fares for use in the Metro Manila GTFS database we are creating?

[David Turner]

The fare working group is likely to take a reasonably long time to come
to a final spec. Looking at our list of concepts so far, some require
clarifying the spec, while others may require entirely new methods of
fare description.

I think none of the concepts we have discovered so far would complicate
or be complicated by this addition to the spec. And, of course,
whatever spec we come up with will likely be backwards-compatible
(except that some compatibility-breaking changes may need to be made to
some interpretations of the spec). Requiring backwards-compatibility
with this proposal as well will not make things any worse.

> --
> You received this message because you are subscribed to the Google
> Groups "General Transit Feed Spec Changes" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/gtfs-changes/-/f4IY19CvdzgJ.

> To post to this group, send email to gtfs-c...@googlegroups.com.
> To unsubscribe from this group, send email to gtfs-changes

> +unsub...@googlegroups.com.