Different fares on different days / times

[Aaron Antrim (Trillium Solutions, Inc.)]

We (Trillium staff) have started to go through our feeds and see which agencies have fare schedules that cannot be expressed, or expressed well, within the existing GTFS.

One of the cases we found several of are fares that are different on different days of the week (mostly different weekday or weekend fares).  There are three of those examples in Oregon: two intercity services (OC&W Coachways and Valley Retriever) and one city-ski hill transportation service (Greasebus).

Right now, our approach for representing these different fares is to create two (or more) entries in routes.txt, each with its own route_id, for the identical route.  Then, we can set different fares for these routes.  It doesn't conform to the Spec, but it works.

One way of working with this case would be to be able to specify a service_id in fare_rules.  Another approach would be to add a new field in trips.txt and fare_rules.txt -- fare_category_id -- which could be used to define various fare categories like "peak", "off-peak", "weekday", or "weekend."

-- 

Aaron Antrim, Principal

Trillium Solutions, Inc.

www.trilliumtransit.com

Portland, Oregon

503.567.8422

[David Turner]

That's an interesting case.

I think this presents an interesting question for the group. Many
unusual fare structures can be emulated using hacks like this one
(peak/off-peak times is another example of this). Should we include
features in the fare spec that will make these things simpler? Or
should we just assume that people will understand and be capable of
creating this sort of structure?

I vote in favor of a more complicated fare system to avoid complicating
feeds in other ways. That's because I think it will aid in GTFS
adoption and completeness.

But I think we ought to come to some sort of guiding principle on this
before we get into the details.

Any other thoughts?


On Mon, 2012-10-08 at 16:03 -0700, Aaron Antrim (Trillium Solutions,

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

[Aaron Antrim]

I also vote in favor of revising the spec with a more complicated system for describing fares.

How about this for a few guiding principles to start off?

• Several (3+) agencies have to use a fare system feature -- no designing the Spec just around one agency.
• The fare system should minimize complications within other parts of the feed data; it should be easily possible to look at the .txt files or import into a relational database and see what's going on without much analysis.  For example, by this criteria the fare_category_id approach I suggested/brainstormed would preferable to using service_id in fare_rules.txt.  Here's why: With Valley Retriever, they have separate Mon-Thus and Fri-Sun timetables, but fares are different for Mon-Fri and Sat-Sun.  If we used service_id to assign fare_rules, we would have to create 3 different service_ids, and Mon-Thurs and Fri would actually have the exact same trips.  So, it makes the situation a bit less obvious and more complicated in the data.
• I think we should base these proposal only on real fare schedules agencies are using.

Maybe someone else can think of some better guiding principles.

-Aaron

To unsubscribe from this group, send email to gtfs-fare-wg...@googlegroups.com.

[David Turner]

+1 to all of these.

On Wed, 2012-10-10 at 11:31 -0700, Aaron Antrim wrote:
> I also vote in favor of revising the spec with a more complicated
> system for describing fares.
>
>
> How about this for a few guiding principles to start off?

> * Several (3+) agencies have to use a fare system feature -- no

> designing the Spec just around one agency.

> * The fare system should minimize complications within other

> parts of the feed data; it should be easily possible to look
> at the .txt files or import into a relational database and see
> what's going on without much analysis. For example, by this
> criteria the fare_category_id approach I
> suggested/brainstormed would preferable to using service_id in
> fare_rules.txt. Here's why: With Valley Retriever, they have
> separate Mon-Thus and Fri-Sun timetables, but fares are
> different for Mon-Fri and Sat-Sun. If we used service_id to
> assign fare_rules, we would have to create 3 different
> service_ids, and Mon-Thurs and Fri would actually have the
> exact same trips. So, it makes the situation a bit less
> obvious and more complicated in the data.

> * I think we should base these proposal only on real fare

[Brian Ferris]

I definitely agree that routes.txt hacks and the like are things we want to discourage when it comes to modeling fares.  I'm +1 on all your guiding principles as well, though I'll admit that if the agency is big enough, I might be will to stretch the rules on #1.

Brian