add multi-agency support to transfers.txt

[Devin Braun]

I'm resurrecting this proposal because now that Google Transit is
becoming more regional, transfers between regional services operated
by different coordinated entities are becoming important in trip
planning. In some areas, local agencies could work together to submit
their routes in the same feed and satisfy current GTFS requirements
for transfers, but as often is the case, not all agencies are willing
or able to cooperate or there is a technological barrier.

I'm not going to provide a concrete proposal because I'd like to see
what everybody thinks. Suggestions have included linking transfers
between agencies to specific route_short_names, route_long_names, etc.
that don't change very often. Stop_ids shouldn't change dynamically,
so linking to another stop_id in another feed could work.

I think an easy way to implement the proposal would be to allow for an
agency to specify a radius around a stop in which all stops from any
agency within that radius shall have the transfer requirement
applied. Since transfers.txt doesn't [currently] support transfers
between routes, this is a solution using only stop_ids.

Devin Braun
San Diego MTS

[Tom Brown]

On Fri, Nov 13, 2009 at 19:03, Devin Braun <devin...@sdmts.com> wrote:

I'm resurrecting this proposal because now that Google Transit is
becoming more regional, transfers between regional services operated
by different coordinated entities are becoming important in trip
planning.  In some areas, local agencies could work together to submit
their routes in the same feed and satisfy current GTFS requirements
for transfers, but as often is the case, not all agencies are willing
or able to cooperate or there is a technological barrier.

I'm not going to provide a concrete proposal because I'd like to see
what everybody thinks.  Suggestions have included linking transfers
between agencies to specific route_short_names, route_long_names, etc.
that don't change very often.  Stop_ids shouldn't change dynamically,
so linking to another stop_id in another feed could work.

I'm not so sure that stop_id values are stable between versions in all feeds. They certainly do change occasionally which would either break transfers or require careful synchronization to reduce the chance that a consumer fetches a mix of old and new versions of the feeds. Of course, the human readable names such as route_long_name and stop_name change too, in some cases more than the ids. When a human readable name changes dramatically it may be more obvious that dependent schedules need to be changed too. The spec will need to define exactly how similar names must be to be considered identical.

I think an easy way to implement the proposal would be to allow for an
agency to specify a radius around a stop in which all stops from any
agency within that radius shall have the transfer requirement
applied.  Since transfers.txt doesn't [currently] support transfers
between routes, this is a solution using only stop_ids.

Matching on distance alone avoids the problems above regarding matching human readable name, which is very nice. This could serve as a good starting point. In places where this is too broad (such as a timed transfer for one trip or direction of travel) matching on human readable names can be added later.