proposal: represent intercity and commuter routes

[Joe Hughes]

Summary:
Add a way to distinguish longer-distance bus and rail routes from
local service, either by adding new route_types, or by adding a
"route_range" field that works in conjunction the existing
route_types.

Motivation:
As Mike Ness has previously pointed out in this forum, riders tend to
use commuter and intercity services in different situations than local
transit services. Fares are handled differently (typically
subscription/pass for commuter, and advance booking for intercity),
and departures are presented differently in official literature and
signage. In order to replicate these distinctions in GTFS-using
applications, we need a way to represent them in GTFS feeds.

Here are two alternate proposals on how to accomplish this:

Proposal A (additional route_type values):

The following additional values would be defined for the route_type
field in the routes.txt file:
* 8 - Commuter Bus
* 9 - Intercity Bus
* 10 - Intercity Rail

In addition, the meaning of value "2" (currently "Rail") would be
further specified as "Commuter Rail", as that best matches most
existing uses of that value.

Proposal B (range field):

The following field would be added to routes.txt file.

route_range (optional):
Specifies the range of this route. The possible values are as follows.
1 - Facility - Operates mostly within the scope of a single facility.
Airport people movers, campus bus shuttles, and amusement park/zoo
tour trains fall within this category.
2 - Neighborhood - Operates within a single neighborhood
3 - City (default value) - Operates mostly within the bounds of a
single city. Most local bus and rail routes have this range.
4 - Commuter Service - Serves an extended metro region. These routes
often run on or near limited-access roads, and have infrequent stops
as they're mostly used for travel from outlying suburbs to and from an
urban center.
5 - Intercity - Travels between cities, often over very long distances.

Any range could be used in conjunction with any route_type.

Discussion:
* Which approach do current data providers and application authors prefer?

Joe Hughes
Google Transit

[Nicholas Albion]

> Fares are handled differently (typically
> subscription/pass for commuter, and advance booking for intercity),

This isn't the case in Europe. In the UK and Switzerland many people
will commute between cities on a daily basis and travel on season
passes. (although those passes are I think different to suburban
season passes).

> The following additional values would be defined for the route_type
> field in the routes.txt file:
> * 8 - Commuter Bus
> * 9 - Intercity Bus
> * 10 - Intercity Rail
>
> In addition, the meaning of value "2" (currently "Rail") would be
> further specified as "Commuter Rail", as that best matches most
> existing uses of that value.

I'm reminded of the discussion we had some time ago on route_type,
Joe. I think it would make sense, in some way to "melt down"
route_types into the fundamental modes they use - rail, road, water,
air, private & human and then further elaborate on each:

eg: Rail includes underground, monorail, inclined rail, inter-city
train.
In some locales (or even class of user) "inclined rail" may be
referred to as funicular, "underground" may be referrered to as
"tube", "metro", "city train" etc.

This approach would probably work well with Proposal B. Note also
that routes.range bares some similarity to TransXChange's "exchange
points" concept which enables agencies to identify that "Central
Station" can be used to travel to different cities/regions.

[Roger Slevin]

Joe

Mike Ness is on holiday right now, so may not be in a position to respond
for a couple of weeks. Best wishes

Roger

Proposal B (range field):

Joe Hughes
Google Transit

--
This email has been verified as Virus free
Virus Protection and more available at http://www.plus.net