Proposal Revival: Expanded Route Types

[Devin Braun]

There has been some discussion, lengthy and detailed, about expanding
route_types. Recently, I found out that Google's implementation of
the spec allows users to get driving directions to a train station,
helping with the "last mile" implementation. This would make sense
for commuter bus or intercity routes as well and marking routes as
these types could foster a client to make these types of
determinations. Here is a recap of the proposals:

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.

Proposal C (route_subtype):
An optional route_subtype field would be added to routes.txt,
identifying the type of route in finer detail. For example:

route_type 3, route_subtype 0 (or omitted) would mean local/generic
bus
route_type 3, route_subtype 1 would mean commuter bus
route_type 3, route_subtype 2 would mean intercity bus (or "coach" in
UK English)
route_type 4, route_subtype 0 (or omitted) would mean local/generic
ferry
route_type 4, route_subtype 1 would mean long-distance ferry
route_type 4, route_subtype 2 would mean catamaran ferry
etc...

While it would depend on the implementation of the spec, giving
driving directions to an intercity or commuter bus stop would be
helpful for many who live in suburbs. By tagging a route as one of
these types, it would help to signify which stops serve long-distance
routes. I would also support adding a new field to stops.txt to
support these types of services, and it can be merged into the stop
amenities proposal, but I'll mention it here:

parking_available (optional, in stops.txt)
0 or blank-no parking available
1-free parking available
2-paid parking available.

Thoughts?

Devin Braun
San Diego MTS

[Joe Hughes]

In this context, it's also worth mentioning the TPEG-derived proposal
that we discussed last time this issue came up:
http://groups.google.com/group/gtfs-changes/msg/9f1c27e827eda843

So far, this issue has languished for a lack of feed publishers
interested in supporting & testing any of these proposals, but it
would be great to more toward a more comprehensive range of
route_types.

Joe

[Nicholas Albion]

I think it would be good to combine the "range field" which reminds me
of the "trunk" routes in TransXchange with the TPEG-inspired scheme.
While we're at it, it would be useful to have a similar range/trunk
flag in the "stops" table to easily identify which stops enable inter-
city travel and should be shown at a coarser zoom level.

[Jehiah Czebotar]

I think it's good to try to map to a subset of the TPEG route type
options. One part of the previous discussion was about mapping it to
the existing route types so that you would know it's a 'bus' by
looking at the most significant digit. This allows consumers of data
multiple granularities of route type which i think is important.

I think proposal C is an excellent way to implement that.. ie:
existing route_types (probably with the addition of proposal A) and a
route_subtype that maps to a more specific type. (i'm saying that the
0,1,2... in subtype would not necessarily always mean the same thing)

I think i'd rather see C over B even though they are not quite
mutually exclusive, they are quite related.

as for uses, i like the current granular ability of route_types
because i use route_types 1 and 2 currently, and so i parse those out
of feeds. (yes i would be able to do the same for a longer list if
they were 3 digit fields)

I think the parking_available idea is worth exploring, but i don't
like that 0 means both undefined/default and no-parking available..
ie: there is a zero in the feed. is it unknown if there is parking, or
is there no parking? (there are also probably other similar types of
fields like wheelchair_accessible, bike_parking, ...). There is also
the question of how this relates to stops and the parent_station
field.

--
Jehiah

[Edward Vielmetti]

Here's a TPEG page if you don't know that acronym:

http://en.wikipedia.org/wiki/TPEG
http://www.tpeg.org/

it's coordinated by TISA, which has this fabu tagline:

"Ensuring synergy and adding market-driven impetus to traffic
information technologies."

yours for impetus,

Ed

--
Edward Vielmetti
Ann Arbor, MI 48104

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

[Aaron Antrim]

Like Jehiah, I would prefer C over B, or a similar variant (like using three digits for more specific route_type designations).

It seems that there are several aspects we're exploring as part of route_type: vehicle, service type, and range.

I don't fully understand the need to specify the range of a service.  How would this designation affect the results returned by a trip planner, or be used by other consumers?  It's also possible to determine range in terms of area covered or miles traveled by looking at stop locations and trip lengths.

What do people think of using separate fields to address vehicle and service type?  Take California's Capitol Corridor as an example: I believe the best service type designation for Capitol Corridor would be as a "Commuter" service.  The vehicles are standard heavy rail/passenger trains.

I am particularly interested in separating out vehicle type and service type as it relates to the open discussion on flexible routes (http://tinyurl.com/cwxjzw).  Three possible service types I can think of would be dial-a-ride, deviated fixed route, and point deviated service.  These kinds of services might be delivered with a standard-length transit bus, short bus, van, or even taxi.

If people are interested in how this would look, I could review current route_type proposals and post a list of vehicle types and service types.

Thoughts?

Aaron

[Devin Braun]

I am in favor of Proposal C. It would provide easy backwards-
compatibility while allowing the feed publisher to specify a more
exact service subtype. Furthermore, the service subtypes could be
changed over time or they could be matched up with TPEG taxonomy.

Devin

[Joe Hughes]

It sounds like people are generally in favor of a hierarchical type
system (proposal C at the top of this thread). The next step is to
put together a more complete proposal for the change, including a more
complete set of type values. We should also debate whether we want to
go with a single field where the hundreds digit is the high-level
type, or having a separate subtype field.

Joe

[Nicholas Albion]

Devin has a good point - why not have the coarse route_type as per the
existing GTFS spec, with an optional (if only for the sake of
backwards compatibility) route_subtype which directly maps to TPEG
codes (and additional codes if necessary). Internally, applications
could combine the two fields if it suited them with something like:
"combinedRouteType = route_type | (route_subtype << 8)"

On Apr 9, 2:31 am, Devin Braun <devin.br...@sdmts.com> wrote:
> ...the service subtypes could be changed over time or they could be matched up with TPEG taxonomy.

[Joe Hughes]

Here's a question for those of you who are most familiar with the TPEG
taxonomy: does it have a type that's suitable for distinguishing
Russian "Marshrutka" minibus/route-taxi service from other service
types?

http://en.wikipedia.org/wiki/Marshrutka

Joe

[Chas_Belov_SFMTA]

I'm not familiar, but I wasn't able to grop marshrutkas solely on the
basis of the Wikipedia entry. I wonder whether they are closer to the
red or green Hong Kong minibuses
http://en.wikipedia.org/wiki/Public_light_bus

Hope this helps,
Charles "Chas" Belov

On Jun 9, 9:09 am, Joe Hughes <joe.hughes.c...@gmail.com> wrote:
> Here's a question for those of you who are most familiar with the TPEG
> taxonomy: does it have a type that's suitable for distinguishing
> Russian "Marshrutka" minibus/route-taxi service from other service
> types?
>
> http://en.wikipedia.org/wiki/Marshrutka
>
> Joe
>

[Aaron Antrim]

Google Transit Partners Help lists 32 supported "expanded route types" here:

https://support.google.com/transitpartners/answer/3520902?hl=en

This is from the TPEG-derived proposal for expanding routes.route_type.

Quick survey: Do other applications support some of these route types?

Thank you,

Aaron

-- 
Aaron Antrim
www.trilliumtransit.com
Portland, Oregon