proposal: add agency_id column to fare_attributes.txt

[Clancy]

Summary:
Add an agency_id column to the fare_attributes table so that fares can
be unique to agencies in feeds with multiple agencies included.

Motivation:
For feeds that contain multiple agencies within, that have different
fare structures, it is necessary to identify which agency a fare
applies to.

Proposal:
Add "agency_id" as an optional column (but required for feeds that
have multiple agencies) to fare_attributes.txt A fare rule or
attribute entry only applies to trips on routes that are assigned to
the agency_id that is referenced in this field.

[Joe Hughes]

Thanks for the proposal, Clancy.

A few thoughts for discussion:

1) This seems to be another rule for deciding which trips a fare is
applicable to; if so, it would be a better fit for fare_rules.txt
rather than fare_attributes.txt

2) Since a route is always attached to a particular agency, it seems
like it'd be redundant to specify this on fare_rule entries that
already specify a route_id. Should an agency_id value be prohibited
in this case?

3) Requiring this extra column in any feed with multiple agencies
would be a non-backward-compatible change, since it would suddenly
make existing feeds non-compliant. The new column has to be
completely optional.

Joe

[Aaron Antrim]

I've started including agency_id in fare_attributes.txt for all feeds, after the Google Maps parser didn't pass my feeds with multiple agencies.

Using agency_id in fare_attributes is easier than using fare_rules.txt to specify that a particular fare applies to all of a given agencies routes.

My understanding is that the Google Maps parser already requires an agency_id in fare_attributes.txt for multi-agency feeds.  One limitation of this requirement I see is that it wouldn't be possible to specify inter-agency fares in cases of inter-agency transfer agreements.

[Joe Hughes]

Thanks for your comments, Aaron.

The Google Maps parser is a client application that can change based
on what we decide here; that is, just because Google has chosen to
implement a proposed extension a particular way during testing doesn't
mean that it should come under any less scrutiny from this group when
we're deciding what to add to the spec.

It seems to me that specifying an agency_id for a fare is basically a
shortcut that's functionally equivalent to specifying that that the
fare applies to each individual route in the agency individually. Is
that right, Clancy?

Joe Hughes
Google

[Clancy]

That is right, Joe.

I guess it does make sense to amend this proposal to:
Add an optional agency_id field to fare_rules.txt

A fare with this rule would only apply to trips which run on routes
that are associated with the named agency.

The absence of a fare_rule with agency_id would then imply that the
fare applies to all agencies in the feed.

This would require Google to do some work on the parser to take into
account that field (but that shouldn't be an issue as Google will
follow the guidance of the feed spec group). For feeds that currently
specify an agency_id in the fare_attributes (which does not officially
conform with the spec), we can interpret that as an implicit fare_rule
that assigns the fare_id to the agency.

[Aaron Antrim]

The proposal (optional agency_id in fare_rules.txt) would work well from my perspective.

[Jehiah Czebotar]

I understand that the current gtfs specification allows for more than
one agency in a feed, but I haven't ever understood a good reason for
that.... so I'll bring it up now. With adding an agency_id to
fare_rules, what are we trying to solve that can't be solved by
keeping the spec as is, and simply publishing separate feeds for each
agency?

As a gtfs consumer, i find it a fair bit more difficult to handle
feeds that have more than one agency in them, and i have a gut feeling
that says if we really want to remove all ambiguity about fields for
datasets with more than one agency we would also need an agency_id on
transfers (as it references stops which is not agency unique) and some
things like stop_url might be different between agencies (ie: each
agency has their own page describing the stop) and so on and so forth.

to me, all those things are better solved simply by publishing a
separate feed for each agency, and leaving the spec as is, where
'simple' combination's of multiple agencies into a single feed are
allowed.

(but of course that's just my 2 cents.. i also couldn't find any
relevant discussions on multiple agencies in the archive so if it's
there please point me to it)

--
Jehiah

[Nicholas Albion]

In some cities, there are bus stops which are served by multiple
agencies (with contracts covering different regions within the city).

In many cities, you might also have train stations (the parent stops)
shared by train and bus operators.

The break-down of modes and regions to multiple agencies does not
necessarily imply different ticketing and fare structures. In
Brisbane, Aust it's possible to purchase an all-day ticket and travel
anywhere within X zones on any bus, train or ferry.

It might be more of a challenge to deal with as a programmer, but it's
certainly a better system from a user's point of view.

[Edward Vielmetti]

The specific case I am interested in solving is where the current
Google Transit patchwork does not generate a route where a
route actually exists if only you knew about a connecting service.

E.g. you should be able to merge Ann Arbor AATA with Detroit and suburban
SMART/DDOT if you can pick up a current Michigan Flyer or Greyhound schedule;
that gets you to East Lansing CATA too. And then you have what
looks like a system that you can optimize, not just a mishmosh
of isolated islands.

If then you pick up Indian Trails intercity bus routes you can get the
Arnold Ferry transit line and all of a sudden you get passenger service
(on half a dozen lines) from Ann Arbor to St Ignace. (Sign me up!)

No one transit operator is going to post that entire schedule, but you
do need to get enough integration at the edges of each system so
that you can make a through connection by dint of cleverness or
dogged exploration. In particular, naming and locating the edge stops
and saying as much as you can about where you need to walk when
you need to make a walking connection is going to be key.

thanks

Ed

--
Edward Vielmetti
Ann Arbor, MI 48104

Google Voice: +1 734 330 2465
Web: http://vielmetti.typepad.com

[Aaron Antrim]

Publishing multi-agency feeds has resulted in some validation errors for me, but I think I've got it down now.  The confusion I've seen and experienced surrounding multi-agency feeds has made me aware of the potential complexity for GTFS consumers (even though I am not one).

However, the capability to publish multi-agency feeds offers these benefits:
1. It is possible for more than one agency to reference the same stop records
2. Stops that are served by various agencies can be grouped into one station
3. Inter-agency fare rules can be defined (actually not yet, but it looks like the group is working on it)
4. Inter-agency transfer preferences can be defined (ie: for an intermodal transit center)

[Clancy Childs]

To revisit/revive this proposal:

It is true that the Google Transit importer does (currently) require an agency_id field in fare_attributes.txt for multi-agency feeds, however this is not compliant with the spec and is something we can work on changing.

Because any feeds that have an agency specified in fare_attributes already have those records as dataset-unique, it should not cause conflicts or bad data if we were to stop looking at that column.

It is a valid point that it might be possible to have cross-agency tickets/fares in a multi agency feed. To do this we need to remove the restriction on having this column in fare_attributes.

Here is the only case that I can think of that might affect existing data (but not sure if it does):

(current non-spec but used by Google) fare_attributes.txt
fare_id,agency_id,price,currency_type,payment_method,transfers,transfer_duration
1,AGENCY1,0.25,USD,0,0,0
2,AGENCY2,0.50,USD,0,0,0

fare_rules.txt

fare_id,route_id,origin_id,destination_id,contains_id
1,,ZONE1,ZONE2,
2,,ZONE1,ZONE2,

In such a case, a trip between ZONE1 and ZONE2 on a service by AGENCY1 would be .25, where as the same trip on a AGENCY2 service would be .50. If Google stopped using agency_id entirely in fare_attributes.txt, this would lead to incorrect calculations.

So, I propose the following:

- Adding an optional field to fare_rules.txt for agency_id. (as previously mentioned). When specified, the fare_rule would only apply to trips on that agency. This would be redundant for route_id based fares, but it would allow for zone-fares to be locked down to an agency. (If not specified, it means the fare rule could apply to any agency trips).

- Google will begin supporting this, but for back-wards compatibility, will consider fare_attributes that are locked to an agency to imply the agency_id in associate fare_rules columns (as mentioned above). (Or we will check to see if this impacts any existing feeds and take action directly.)

Does that work for everyone? 

Jehiah, I understand your concern, but the benefits of multiple agency feeds do include some very valid points (fares, transfers, etc.). I think that a possible work around for you could be to write a script that simply splits multi agency feeds into smaller single-agency feeds. However, you would lose these cross-agency features.

Thanks,

Clancy

--

Clancy Childs

Sales Engineer

Google UK

e: cla...@google.com 

p: +44 (0)207 184-3408 

Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London
SW1W 9TQ
Registered in England Number: 3977902 

This information contained in this email may be confidential or
privileged. If you received this communication by mistake, please erase
all copies and attachments and let the sender know that it went to the
wrong person.

The above terms reflect a potential business arrangement, are provided
solely as a basis for further discussion, and are not intended to be
and do not constitute a legally binding obligation. No legally binding
obligations will be created, implied, or inferred until an agreement in
final form is executed in writing by all parties involved