Re: proposal: Modify route_type to add new types and to group similar types together

2744 views
Skip to first unread message

Jacques chez stibus

unread,
Mar 20, 2008, 5:44:31 AM3/20/08
to Google Transit Feed Spec Changes
Bonjour,

While it is always helpful to standardize, especially when a standard
exists, we must be wary of the induced risk of rigidity.

For instance, here in Maubeuge, France we have a project that includes
separated bus lanes, high quality buses and specific stations... In
Douai (not so far of Maubeuge) what they call "Tramway" is in fact an
"optically guided" bus... Neither customers nor agencies would
consider them as simple buses. But I do not see how to classify thoses
systems in your taxonomy.

I think it would be better to use the TPEG list (which gets the credit
for being an existing standard), but please keep an ability for
agencies to define their own type of transportation mode.

Cordialement.

Jacques Lys

On 19 mar, 16:42, Joe Hughes <joe.hughes.c...@gmail.com> wrote:
> Does no one have any thoughts on whether they prefer:
>
> http://groups.google.com/group/gtfs-changes/msg/ed917a69cf8c5bef
>
> or
>
> http://groups.google.com/group/gtfs-changes/web/route-type-proposal
>
> Or does anyone have an alternate concrete proposal? For the sake of
> agencies with modes not represented in the current spec, it would be
> great to get an expanded route_type taxonomy of some sort out there.
>
> Thanks,
> Joe
>
> On Mar 5, 1:01 pm, "Joe Hughes" <joe.hughes.c...@gmail.com> wrote:
>
> > Thanks for the pointer, Roger. Based on the information at this URL (http://www.bbc.co.uk/travelnews/xml/pti/pti_index.html), I've put
> > together a proposed route_type taxonomy that would map closely to the
> > TPEG taxonomy.
>
> > To the agency folks on this list: do you prefer this to the proposal
> > that I originally posted? (That one is athttp://groups.google.com/group/gtfs-changes/web/route-type-proposal).
>
> > Here's the TPEG-derived list of potential route_type values:
>
> > 100 Railway Service
> > 101 High Speed Rail Service
> > 102 Long Distance Trains
> > 103 Inter Regional Rail Service
> > 104 Car Transport Rail Service
> > 105 Sleeper Rail Service
> > 106 Regional Rail Service
> > 107 Tourist Railway Service
> > 108 Rail Shuttle (Within Complex)
> > 109 Suburban Railway
> > 110 Replacement Rail Service
> > 111 Special Rail Service
> > 112 Lorry Transport Rail Service
> > 113 All Rail Services
> > 114 Cross-Country Rail Service
> > 115 Vehicle Transport Rail Service
> > 116 Rack and Pinion Railway
> > 117 Additional Rail Service
>
> > 200 Coach Service
> > 201 International Coach Service
> > 202 National Coach Service
> > 203 Shuttle Coach Service
> > 204 Regional Coach Service
> > 205 Special Coach Service
> > 206 Sightseeing Coach Service
> > 207 Tourist Coach Service
> > 208 Commuter Coach Service
> > 209 All Coach Services
>
> > 300 Suburban Railway Service
>
> > 400 Urban Railway Service
> > 401 Metro Service
> > 402 Underground Service
> > 403 Urban Railway Service
> > 404 All Urban Railway Services
>
> > 500 Metro Service
>
> > 600 Underground Service
>
> > 700 Bus Service
> > 701 Regional Bus Service
> > 702 Express Bus Service
> > 703 Stopping Bus Service
> > 704 Local Bus Service
> > 705 Night Bus Service
> > 706 Post Bus Service
> > 707 Special Needs Bus
> > 708 Mobility Bus Service
> > 709 Mobility Bus for Registered Disabled
> > 710 Sightseeing Bus
> > 711 Shuttle Bus
> > 712 School Bus
> > 713 School and Public Service Bus
> > 714 Rail Replacement Bus Service
> > 715 Demand and Response Bus Service
> > 716 All Bus Services
>
> > 800 Trolleybus Service
>
> > 900 Tram Service
> > 901 City Tram Service
> > 902 Local Tram Service
> > 903 Regional Tram Service
> > 904 Sightseeing Tram Service
> > 905 Shuttle Tram Service
> > 906 All Tram Services
>
> > 1000 Water Transport Service
> > 1001 International Car Ferry Service
> > 1002 National Car Ferry Service
> > 1003 Regional Car Ferry Service
> > 1004 Local Car Ferry Service
> > 1005 International Passenger Ferry Service
> > 1006 National Passenger Ferry Service
> > 1007 Regional Passenger Ferry Service
> > 1008 Local Passenger Ferry Service
> > 1009 Post Boat Service
> > 1010 Train Ferry Service
> > 1011 Road-Link Ferry Service
> > 1012 Airport-Link Ferry Service
> > 1013 Car High-Speed Ferry Service
> > 1014 Passenger High-Speed Ferry Service
> > 1015 Sightseeing Boat Service
> > 1016 School Boat
> > 1017 Cable-Drawn Boat Service
> > 1018 River Bus Service
> > 1019 Scheduled Ferry Service
> > 1020 Shuttle Ferry Service
> > 1021 All Water Transport Services
>
> > 1100 Air Service
> > 1101 International Air Service
> > 1102 Domestic Air Service
> > 1103 Intercontinental Air Service
> > 1104 Domestic Scheduled Air Service
> > 1105 Shuttle Air Service
> > 1106 Intercontinental Charter Air Service
> > 1107 International Charter Air Service
> > 1108 Round-Trip Charter Air Service
> > 1109 Sightseeing Air Service
> > 1110 Helicopter Air Service
> > 1111 Domestic Charter Air Service
> > 1112 Schengen-Area Air Service
> > 1113 Airship Service
> > 1114 All Air Services
>
> > 1200 Ferry Service
>
> > 1300 Telecabin Service
> > 1301 Telecabin Service
> > 1302 Cable Car Service
> > 1303 Elevator Service
> > 1304 Chair Lift Service
> > 1305 Drag Lift Service
> > 1306 Small Telecabin Service
> > 1307 All Telecabin Services
>
> > 1400 Funicular Service
> > 1401 Funicular Service
> > 1402 All Funicular Service
>
> > 1500 Taxi Service
> > 1501 Communal Taxi Service
> > 1502 Water Taxi Service
> > 1503 Rail Taxi Service
> > 1504 Bike Taxi Service
> > 1505 Licensed Taxi Service
> > 1506 Private Hire Service Vehicle
> > 1507 All Taxi Services
>
> > 1600 Self Drive
> > 1601 Hire Car
> > 1602 Hire Van
> > 1603 Hire Motorbike
> > 1604 Hire Cycle
> > 1605 All Self-Drive Vehicles
>
> > Deprecated Types
>
> > The values below are retained for backwards-compatibility with
> > existing feeds; feed-reading applications should continue to
> > understand these, but they shouldn't be used in new feeds.
>
> > Existing Value - Meaning - Corresponding New Value
> > 0 - Tram, Light Rail, Streetcar - 900
> > 1 - Subway, Metro - 400
> > 2 - Rail - 100
> > 3 - Bus - 700
> > 4 - Ferry - 1000
> > 5 - Cable Car - ?
> > 6 - Gondola, Suspended cable car - 1300
> > 7 - Funicular - 1400
>
> > Thanks,
> > Joe
>
> > On Sat, Mar 1, 2008 at 9:58 AM, Roger Slevin <ro...@slevin.plus.com> wrote:
>
> > > Joe
>
> > > I thinkhttp://www.bbc.co.uk/travelnews/xml/pti/pti_index.htmlactually
> > > shows the public transport (sorry, transit) modes in full detail. I think
> > > the reference which you mentioned is the multi-mode table for the original
> > > version of TPEG ... which has then been extended with TPEG-PTI as the public
> > > transport specialism. I will still check this out to make sure this is the
> > > latest version - and to confirm the usage rules.
>
> > > Best wishes
>
> > > Roger
>
> > > -----Original Message-----
> > > From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
>
> > > On Behalf Of Joe Hughes
> > > Sent: 01 March 2008 16:22
> > > To: gtfs-c...@googlegroups.com
>
> > > Subject: [gtfs-changes] Re: proposal: Modify route_type to add new types and
> > > to group similar types together
>
> > > Nicholas,
>
> > > Thanks for your proposal for trying to harmonize the TPEG taxonomy
> > > with the one I proposed--it's productive to be discussing details.
> > > Unfortunately, with your digits-reversed proposal, it would make it
> > > more complicated for applications that only cared about the high-level
> > > distinctions; it's no longer as straightforward to check if a code
> > > falls in 1000-1999 to see if it's rail or 2200-2299 to see if it's
> > > longer-distance coach.
>
> > > Roger,
>
> > > Does this page on the BBC site that Nicholas pointed to accurately
> > > represent your understanding of the TPEG taxonomy?
> > > http://www.bbc.co.uk/travelnews/xml/loc/loc_index.htm
>
> > > (It looks like table 05 could be read as a top level with tables 10-16
> > > as the second level.)
>
> > > Which systems produce and consume this taxonomy in production today?
>
> > > Joe
>
> > > On Fri, Feb 29, 2008 at 10:29 PM, Nicholas Albion <nalb...@gmail.com> wrote:
>
> > > > While there's a lot about TPEG that I like, I think that it could do
> > > > with some re-working - perhaps come up with a TPEG2?
>
> > > > I do like that TPEG reserves 0 and 255 for unknown/undefined. I also
> > > > like that it's language independant.
>
> > > > I like the hierarchical approach Joe has taken in the new GTFS
> > > > proposal, but suspect that the TPEG people would prefer to constrain
> > > > the values to 8 bits.
>
> > > > I've had a go at combining the best of both worlds:
> > > > GTFS (existing)http://mobojax.com/ctdm#a_gtfs_route_type_constants
> > > > TPEG:http://mobojax.com/ctdm#a_tpeg_mode_type_constants
>
> > > > into
> > > > CTDM:http://mobojax.com/ctdm#a_transport_mode_constants
>
> > > > Perhaps a better way for TPEG2 and GTFS2 to coexist would be to
> > > > reverse the order in Joe's proposal:
> > > > 2 - Rail
> > > > 3 - Bus
> > > > 8 - Boat
> > > > 9 - Air
> > > > 10 - Misc
>
> > > > 0002 - Generic Rail
> > > > 0012 - Generic Local Rail
> > > > 1012 - Tram, Light Rail, Streetcar
> > > > 2012 - Subway
> > > > 3012 - Metro Rail
> > > > 4012 - Monorail
> > > > 5012 - People Mover
> > > > 6012 - Funicular
> > > > 7012 - Cable Car
> > > > 0022 - Generic Longer-Distance Rail
> > > > 1022 - Commuter Rail
> > > > 2022 - Intercity Rail
> > > > 3022 - High-Speed Rail
>
> > > > 0003 - Generic Bus
> > > > 0013 - Generic Local Bus
> > > > 1013 - Regular Local Bus
> > > > 2013 - Trolleybus
> > > > 0023 Generic Longer-Distance Bus/Coach
> > > > 1023 Commuter Bus/Coach
> > > > 2023 Intercity Bus/Coach
>
> > > > 0008 - Generic Boat/Ferry
>
> > > > 0009 - Generic Air Travel
>
> > > > 0010 - Miscellaneous
> > > > 1010 - Suspended Gondola Lift, Aerial Tram
> > > > 2010 - Horse-Drawn Carriage
>
> > > > ...then again, perhaps TPEG applications could simply divide the
> > > > values in Joe's original proposal by 100 or 1000...
>
> > > --
>
> > > This email has been verified as Virus free.
> > > Virus Protection and more available athttp://www.plus.net

Roger Slevin

unread,
Mar 20, 2008, 7:34:04 AM3/20/08
to gtfs-c...@googlegroups.com
Joe and Jacques

I spoke to the chairman of the TPEG standards group a week or so ago and he
was keen to see this aspect of their standard adopted as widely as possible
... but equally keen to hear of modes which may need to be added, or
definitions slightly changed, to keep TPEG mode lists up to date.

I haven't yet had time to cross-check Joe's proposal against the TPEG
standard - and I would like to be sure that they are 100% consistent, or
that there is a very good reason why they are not! But with just that
proviso, I think the TPEG list is very comprehensive and will give a very
helpful consistency between Google's format and the formally adopted
standard in this area.

Best wishes

Roger Slevin
Traveline South East

Joe Hughes

unread,
Mar 20, 2008, 12:55:39 PM3/20/08
to gtfs-c...@googlegroups.com
Thanks for the comments, Jacques and Roger.

One question that I would still like to get an answer to is: which
software systems, and which agencies/operators currently represent
their routes using the TPEG taxonomy? I'd like for us to have a sense
of how this taxonomy has been exercised in real usage.

There are some things about my TPEG-derived proposal that worry me, namely that:

(1) It has some ambiguity--for instance, "Metro Service" is both a
top-level item (500) and a sub-item under a different heading (401).
Which should a data provider use?

(2) It has more items than I think are needed at this point in time
(for instance "Lorry Transport Rail Service"). Would it be a problem
to leave out several of the items as long as the categorization of the
rest remain TPEG-compatible?

(3) There are several modes missing that we would like to represent,
for instance "Monorail", "Cable Car", and "Horse-Drawn Carriage".

I hope that we can end up with something that has enough detail to
express what needs to be expressed, while not drowning implementors in
fine distinctions.

Again, I encourage the posting of concrete proposals by other group
members. Roger, since you have connections to the TPEG group, it
would be extremely valuable if you could ensure that we have the
latest TPEG taxonomy documentation.

Thanks,
Joe Hughes
Google

Joe Hughes

unread,
Mar 20, 2008, 1:18:43 PM3/20/08
to gtfs-c...@googlegroups.com
Here's a more minimalist proposal that's still based as closely on
TPEG as I can manage. Again, in the absence of a better reference, my
understanding of the TPEG taxonomy derives from:
http://www.bbc.co.uk/travelnews/xml/pti/pti_index.html

As a reminder, the other concrete proposals that have been posted so far are:
http://groups.google.com/group/gtfs-changes/web/route-type-proposal
http://groups.google.com/group/gtfs-changes/msg/ed917a69cf8c5bef

Here's the TPEG-derived list of potential route_type values, filtered
to a subset that's consistent with current needs, and with a few
additions for modes not found in TPEG:

100 Railway Service
101 High Speed Rail Service
102 Long Distance Trains

108 Rail Shuttle (Within Complex)
109 Suburban Railway

200 Coach Service


201 International Coach Service
202 National Coach Service

204 Regional Coach Service
208 Commuter Coach Service

400 Urban Railway Service


401 Metro Service
402 Underground Service

405 Monorail

700 Bus Service
701 Regional Bus Service
702 Express Bus Service

704 Local Bus Service

800 Trolleybus Service

900 Tram Service

1000 Water Transport Service

1100 Air Service

1300 Telecabin Service

1400 Funicular Service

1700 Miscellaneous Service
1701 Cable Car
1702 Horse-Drawn Carriage

Deprecated Types

The values below are retained for backwards-compatibility with
existing feeds; feed-reading applications should continue to
understand these, but they shouldn't be used in new feeds.

Existing Value - Meaning - Corresponding New Value
0 - Tram, Light Rail, Streetcar - 900
1 - Subway, Metro - 400
2 - Rail - 100
3 - Bus - 700
4 - Ferry - 1000

5 - Cable Car - 1701


6 - Gondola, Suspended cable car - 1300
7 - Funicular - 1400

Joe Hughes
Google

Nicholas Albion

unread,
Mar 21, 2008, 11:00:24 PM3/21/08
to Google Transit Feed Spec Changes
I think the best way to afford everybody the flexibility that they
require would be to build in a hierarchy and for each general mode
reserve a block for custom types:

TTXX: adopted from TPEG codes
XX0X: tourist services
XX1X: short distance services (fenincular, cross-river ferry...)
XX2X: suburban trips (bus, metro)
XX3X: inter-city, regional trips (train, coach)
XX4X: inter-regional trips (train, coach)
XX5X: international services
XX6X: commercial/freight services
XX7X: reserved - open for suggestions, maybe some blocks should be
widened?
XX8X: reserved
XX9X: custom types - description to be specified in feed


100 Railway Service
101 Tourist Railway Service
110 High Speed Rail Service
112 Rail Shuttle (Within Complex)
113 Rack and Pinion Railway
114 Additional Rail Service
121 Suburban Railway
130 Long Distance Trains
131 Regional Rail Service
140 Inter Regional Rail Service
141 Sleeper Rail Service
142 Cross-Country Rail Service
160 Car Transport Rail Service
161 Lorry Transport Rail Service
162 Vehicle Transport Rail Service
180 Replacement Rail Service
181 Special Rail Service
1FF All Rail Services
190 "Douai Tramway"

Joe Hughes

unread,
Jan 19, 2009, 11:00:27 PM1/19/09
to gtfs-c...@googlegroups.com
It's been a while, and I'd like to revive the discussion on how to
extend route_type. When we last left the subject, the proposal on the
table was to use a list corresponding to a subset of the TPEG
taxonomy. The details are quoted below, and can be seen on the web
here:
http://groups.google.com/group/gtfs-changes/msg/9f1c27e827eda843

To the feed publishers in this group, are any of you interested in
using this route_type scheme in the future? Are there types in TPEG
that I haven't included in the subset below that you'd use to
represent your own data? Is there an alternative scheme that you'd
rather use?

To the feed consumers in this group, what purposes do you use the
route_type values for today?

For reference, the entire history of this thread can be seen at:
http://groups.google.com/group/gtfs-changes/browse_thread/thread/91e4f9ad33d2ed8d

Thanks,
Joe

Jehiah Czebotar

unread,
Jan 19, 2009, 11:17:38 PM1/19/09
to gtfs-c...@googlegroups.com
On Mon, Jan 19, 2009 at 11:00 PM, Joe Hughes <joe.hug...@gmail.com> wrote:

> To the feed publishers in this group, are any of you interested in
> using this route_type scheme in the future? Are there types in TPEG
> that I haven't included in the subset below that you'd use to
> represent your own data? Is there an alternative scheme that you'd
> rather use?

I like the TPEG-derived list, so this is my vote for that. I think
it's the right granularity of being specific but not overly so, and
still groups things together, and allows for future additions if
needed within each category.

>
> To the feed consumers in this group, what purposes do you use the
> route_type values for today?

One use I have currently is to consume part of a gtfs feed: ie: use
only the 1xx or 4xx 'train' type schedule data
(and i could imagine doing the same thing if i had an application that
was geared towards bus schedules).

Another use (as a developer) is for understanding what type of routes
are in a feed when i'm inspecting gtfs files for areas i'm not
familiar with.

--
Jehiah

Marcy

unread,
Nov 17, 2011, 4:38:20 AM11/17/11
to gtfs-c...@googlegroups.com
I would like to advance the display for a mode & route_type not yet available through GTFS:  Scheduled Air Shuttle

as either adding: 9 - Air 
or 
1105 Shuttle Air Service with +1 to TPEG (or abbreviated TPEG's granularity) that could get us rolling to connect rural places with air options

(commuter/rural air carriers are challenged to stay in biz in these economic times and ground routing may be 2-4 hours of travel vs. less than 45 min. by air; with an integrated trip planner the traveler might see their options & consider them)

To promote functional options and inspire local tourism, we need the air as a route_type option through GTFS.

I would be prepared to create a datafeed that would overlay on a two to four agency trip option and help test the few air trips per day vs. bus+ferry connections.

I understand that GTFS is not used for Japan's trip planner, but is it sure handy to display and suppress options by mode, as mentioned by Jehiah.

Thank you for your revival of this discussion,
Marcy

David Turner

unread,
Jun 26, 2012, 7:25:27 PM6/26/12
to gtfs-c...@googlegroups.com
Of course, we need a consumer before the proposal can be adopted; I have
just started adding support to OTP, but I have a question about the
following modes:

109 Suburban Railway
401 Metro Service
402 Underground Service
900 Tram Service

These categories are rather fuzzy. Clearly the Times Square Shuttle on
NYCT is Underground Service (as it is underground for its entire
length). Most (all?) of the rest of the MTA's lines are both elevated
for at least part of their journey, and underground for at least part.
So are they "Metro", or "Underground"? Similarly, the Green lines in
Philadelphia (or Boston) are partly underground and partly streetcar.
Then there's the Berlin S-Bahn; on one hand, it does go out to the
suburbs, but on the other, there is another rail network in the Berlin
area which goes further into the suburbs (without qualifying as
intercity). The S-Bahn is partially underground, but it's also distinct
from the U-Bahn, the main underground system.

Of course, this problem is not unique to this proposal -- the correct
coding for the various Green lines are uncertain under the current text
as well.


I have two incompatible proposals:
Proposal A:

402: Riders consider the route part of an Underground system (so, this
covers all of the US examples above)
900: Riders consider the route part of a tram system
109: The route is used mainly for transportation between suburbs and a
city center, or is part of a system mainly used for this.
401: The route is described as "S-Bahn" or is the JR Yamanote line, or
is otherwise neither comfortably a subway nor comfortably suburban
rail.

I also have no idea what the difference between a coach and a bus is, so
this isn't addressed by this proposal. If nobody can explain the
difference, 700 and 701 can be eliminated and the remaining 7xxs can be
merged into 2xx (or kept in 7xx for compatibility with TPEG).

Proposal B:
It ought to be less complicated to figure out modes, but we ought to be
able to represent real systems like Jeepneys. So, a much more minimal
change is the following:

8: Subway-surface lines (the Green lines)
9: Water Transport Service
10: Plane
11: Helicopter
12: Horse-Drawn Carriage
13: Jeepney
14: AUV

This has the advantage that it does not make distinctions between
services that are contentious (is a bus from Jerusalem to Ramallah
national or international?), bizarre (what about a bus from Rome that
happens to pass through Vatican City?), or nitpicky (as in proposal A).
TPEG might be useful for someone, but I don't think it's necessarily
useful for any actual GTFS consumer.

So, upon reflection I have to say that I prefer proposal B.

On Tue, 2012-06-26 at 05:24 -0700, tay...@itpworld.net wrote:
> Hi All
>
> I also have an interest in this topic, so am seeking to revive the thread. First some background by way of an introduction...
>
> I am currently managing a project in Metro Manila to create an open public transit database and GTFS feed on behalf of the Philippine Department of Transport & Communications (DOTC), with whom we are working closely to build capacity so that a small team is able to take responsibility for the database and GTFS feed as an outcome of our work. The project has been funded by the World Bank and our project partners at the University of the Philippines National Center for Transportation Studies are about to embark on a substantial round of data collection (Collecting GIS data for circa. 1,000 PT routes in Metro Manila) in order to enable us to complete the sizeable task of building the PT database and creating a complete GTFS feed for the city. This will subsequently be opened up to 3rd party developers through an app development competition in Manila.
>
> The project is viewed by the DOTC as a launchpad for extending GTFS feeds to Mega Manila (and other Philippine cities in the future) as a precursor to restructuring and formalizing its largely informal transit services. The World Bank has funded the project because they can see how our open documentation of the processes involved (and accompanying development of an open source GTFS Creator tool) will assist other transition and developing cities with unplanned public transit networks to develop GIS-based public transport databases and GTFS feeds.
>
> One challenges we face is that the route_type field in GTFS does not currently enable us to differentiate between two common and distinct types of bus transit: Jeepneys (also referred to as Public Utility Jeepneys/PUJs) and metro line feeder services known as AUVs. These are specific to the Philippines, and have notably different operating schedules, fare systems and routes.
>
> Our proposal is that Jeepneys and AUVs be included as distinct types of bus service, under the 700 'Bus Services' grouping derived from the TPEG taxonomy, which was been proposed earlier in this thread.
>
> I would welcome your thoughts on our proposal. For our part we are eager to implement them through a real-world deployment of Google Transit /OpenTripPlanner for Metro Manila later this year, and are pleased to count OpenPlans as expert advisers to the project in Metro Manila.
>
> Best regards
> Neil
>



Roger Slevin

unread,
Jun 27, 2012, 3:22:15 AM6/27/12
to gtfs-c...@googlegroups.com
David

I think we have to accept "fuzzy" definitions of modes. There are so many
different contexts and potential factors that will influence the way that
modes are defined locally - and in GTFS I think it is important that it is
the local perceptions that are reflected in the mode types. You have
reflected on the situation in New York - if I were to do the same in London
the "London Underground" system has long sections of overground track ....
but no one would thank you for using anything other than Underground as the
mode for that system. The DLR, however, is probably best defined as a Metro
- whilst Croydon Tramlink is a tram system.

We also have to recognise that American English and English English are not
the same - so a Trolley in America is not the same as a Trolley in the UK
(which is an electrically powered bus which takes and returns current from
and to two separate overhead wires).

In Clermont Ferrand (Fr) for instance there is a "tram" system which is
based on a single guide rail and articulated rubber-tyred vehicles drawing
current from an overhead supply and returning it through the earthed
guiderail. It is called a tram - but you could argue it is an electrically
powered guided bus because it is running on rubber tyres on the road.

Local judgement needs to prevail.

Roger

-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
On Behalf Of David Turner
Sent: 27 June 2012 12:25 AM
To: gtfs-c...@googlegroups.com
Subject: Re: [gtfs-changes] Re: proposal: Modify route_type to add new types
and to group similar types together

--
You received this message because you are subscribed to the Google Groups
"General Transit Feed Spec Changes" group.
To post to this group, send email to gtfs-c...@googlegroups.com.
To unsubscribe from this group, send email to
gtfs-changes...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/gtfs-changes?hl=en.


Neil Taylor

unread,
Jun 27, 2012, 3:47:49 AM6/27/12
to gtfs-c...@googlegroups.com
Re: coach and bus services

In the UK and Europe bus services tend to reflect urban transit services where the passenger pays on board/pre-purchases at stop (as in London) or uses a smartcard to make a short trip of up to 10 miles/16km (or maybe 20 miles/32km in more rural settings). These are scheduled services typically running on at least an hourly frequency.

Coach services tend to be different from buses in that they serve longer distances and are predominantly inter-urban rather than intra-urban. Coach services typically require pre-purchased tickets or reservations (either at a ticket office before travel or online/by phone in advance) and do not tend to accept smartcard/pay on board methods of trip purchase. While they run to a schedule, the frequencies tend to be much lower reflecting the longer distance of trips and greater variability of traffic conditions on motorway (interstate) networks.

Best regards
Neil
  
-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com] On Behalf Of David Turner
Sent: 27 June 2012 00:25
To: gtfs-c...@googlegroups.com
Subject: Re: [gtfs-changes] Re: proposal: Modify route_type to add new types and to group similar types together

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To post to this group, send email to gtfs-c...@googlegroups.com.
To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.


This email (and any attachments) contains confidential information and is intended solely for the individual to whom it is addressed. If this email has been misdirected, please notify the author as soon as possible. If you are not the intended recipient you must not disclose, distribute, copy, print or rely on any of the information contained, and all copies must be deleted immediately.

This footnote also confirms that this email message has been swept by anti-virus software, but Integrated Transport Planning Ltd cannot accept liability for any damage caused by receipt of this email.
Please consider the environment before printing this e-mail.

sabre23t

unread,
Jun 27, 2012, 6:16:31 AM6/27/12
to gtfs-c...@googlegroups.com

In MY side of the world ...

Coach == Express Bus, point-to-point org limited stops, seating only, pre-booked ticketing, intra-urban.

Bus == Stage Bus, multi stops, seating/standing, on board or at stations ticketing, inter-urban.

Roger Slevin

unread,
Jun 27, 2012, 6:25:20 AM6/27/12
to gtfs-c...@googlegroups.com

The UK situation is much the same except

·         There are legal distinctions between services which are commonly referred to as the differences between coach and bus - but these do not always align with other factors that might distinguish between the two modes

·         Coaches are generally high-floor vehicles with separate luggage accommodation - buses generally have lower floor and no separate luggage space

·         There are services on the margin between bus and coach - often referred to as “limited stop” services - these may fit some of the definitions for coaches and some of the definitions for buses .... ultimately it is an arbitrary local decision which category to put them in

 

Roger

--

Stuart Heinrich

unread,
Jun 27, 2012, 12:52:02 PM6/27/12
to gtfs-c...@googlegroups.com
On Wed, Jun 27, 2012 at 12:22 AM, Roger Slevin <ro...@slevin.plus.com> wrote:
David

I think we have to accept "fuzzy" definitions of modes. There are so many
different contexts and potential factors that will influence the way that
modes are defined locally - and in GTFS I think it is important that it is
the local perceptions that are reflected in the mode types.  You have
reflected on the situation in New York - if I were to do the same in London
the "London Underground" system has long sections of overground track ....
but no one would thank you for using anything other than Underground as the
mode for that system.  The DLR, however, is probably best defined as a Metro
- whilst Croydon Tramlink is a tram system.
 
 
I think the mode types are fine, but one must recognize that transit mode is not sufficient for describing the vehicle in a comfortable way.  For example, an underground rail system may be referred to as a subway, metro, underground or BART train, etc.  These are clearly not enumerated types.  In our routing system we have recognized the need to make a separate field for each transit route that describes the "locale specific vehicle name" which is specifically NOT an enumerated type.  It certainly would be nice to have such a field incorporated into GTFS as well.

David Turner

unread,
Jun 27, 2012, 4:44:03 PM6/27/12
to gtfs-c...@googlegroups.com

On Wed, 2012-06-27 at 08:22 +0100, Roger Slevin wrote:
> David
>
> I think we have to accept "fuzzy" definitions of modes. There are so many
> different contexts and potential factors that will influence the way that
> modes are defined locally - and in GTFS I think it is important that it is
> the local perceptions that are reflected in the mode types. You have
> reflected on the situation in New York - if I were to do the same in London
> the "London Underground" system has long sections of overground track ....
> but no one would thank you for using anything other than Underground as the
> mode for that system. The DLR, however, is probably best defined as a Metro
> - whilst Croydon Tramlink is a tram system.

Sure, and in Japan, there's a kind of train called 新幹線, which doesn't
appear anywhere in this taxonomy. So maybe we ought to have two route
type fields:

(1) route_type used to present icons to the user, for user preferences
in routing (people prefer trains/trams to buses even when travel time is
equal). If we go with my simple proposal B here, this is easy to
internationalize, and mostly doesn't require any fuzzy definitions.

(2) route_type_name, which includes things like S-Bahn, 新幹線, Regional
Rail, etc. This allows an underground train to be called a "subway" in
New York and an "underground" in London (Google transit and OTP
presently call both "subways").

Stuart Heinrich

unread,
Jun 27, 2012, 5:18:25 PM6/27/12
to gtfs-c...@googlegroups.com
This is exactly what we need.  It's a simple, backwards compatible solution to this problem...does anyone have any reason why this proposal should not be accepted?

Aaron Antrim

unread,
Jun 28, 2012, 3:10:24 AM6/28/12
to gtfs-c...@googlegroups.com
I think that mode definitions will become clearer and easier to agree on if we separate the idea of route_type from vehicle type.

For example, the TPEG definition list has intercity bus and intercity rail.  Why should the "intercity" service designation be conflated with the vehicle?

Vehicle type is useful for customers who want to know what sort of vehicle and facilities to look for.  They may associate certain vehicles with certain amenities.

Route or service type, I think, is a bit of a different idea: This encompasses designations such as intercity, high-speed, in-traffic, commuter, etc.  Some of this information (such as intercity, or high-speed) would be indicated by other elements of the GTFS (namely the schedules and stops).  A mapping application may use this information to show just intercity services, or just frequent services, for example.

It might be useful to be able to describe a service such as BRT.

I like David's proposal.  Does anyone have thoughts on changing route_type to vehicle_type, or simply, mode, so we can move toward separating the description of the type of vehicle from the type of service?

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

To unsubscribe from this group, send email to gtfs-changes+unsubscribe@googlegroups.com.

Neil Taylor

unread,
Jun 28, 2012, 8:09:23 AM6/28/12
to gtfs-c...@googlegroups.com, Ian Stott

I agree, and also support David’s proposal.  I think it makes really good sense to avoid the conflation between what is fundamentally the type of service an individual might use (e.g. bus, rail, metro), the other nuances around the type of vehicle they will use to make that trip (e.g. express bus, jeepney), and the associated connotations these will have for local populations and transit system users.

 

In the context of the GTFS feed I am developing in Metro Manila, I understand this will allow us to define Jeepneys and AUVs as types of bus route_type, but dedicate ‘Jeepney’ and ‘AUV’ vehicle designations to them in the proposed vehicle_type field.

 

Unless anyone has any objections, then this is how we will format the data in the Metro Manila public transport database so that it can be appropriately converted into GTFS through the open source GTFS Creator tool that our team is working on.

 

Many thanks for your thoughtful responses to my question

Best regards

Neil Taylor, ITP

www.itpworld.net

 

From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com] On Behalf Of Aaron Antrim
Sent: 28 June 2012 08:10
To: gtfs-c...@googlegroups.com
Subject: Re: [gtfs-changes] Re: proposal: Modify route_type to add new types and to group similar types together

 

I think that mode definitions will become clearer and easier to agree on if we separate the idea of route_type from vehicle type.

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


For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

To view this discussion on the web visit https://groups.google.com/d/msg/gtfs-changes/-/I7qN42C96HAJ.


To post to this group, send email to gtfs-c...@googlegroups.com.

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


For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

This email (and any attachments) contains confidential information and is intended solely for the individual to whom it is addressed. If this email has been misdirected, please notify the author as soon as possible. If you are not the intended recipient you must not disclose, distribute, copy, print or rely on any of the information contained, and all copies must be deleted immediately.

Stuart Heinrich

unread,
Jun 28, 2012, 1:27:33 PM6/28/12
to gtfs-c...@googlegroups.com
Agree with David...I think route_type_name is the most informative/clear title for the new field

 
On Thu, Jun 28, 2012 at 10:24 AM, David Turner <nov...@novalis.org> wrote:
On Thu, 2012-06-28 at 13:09 +0100, Neil Taylor wrote:
> In the context of the GTFS feed I am developing in Metro Manila, I
> understand this will allow us to define Jeepneys and AUVs as types of
> bus route_type, but dedicate ‘Jeepney’ and ‘AUV’ vehicle designations
> to them in the proposed vehicle_type field.

I think this should probably be route_type_name, rather than
vehicle_type, since "underground" or "subway" describes the user's
perception of the routes rather than the specifics of the vehicle.
Also, the exact same vehicles are used on the Staten Island Railway as
on the NYC subway, but the SIR isn't thought of as a subway.

David Turner

unread,
Jun 28, 2012, 1:24:11 PM6/28/12
to gtfs-c...@googlegroups.com
On Thu, 2012-06-28 at 13:09 +0100, Neil Taylor wrote:
> In the context of the GTFS feed I am developing in Metro Manila, I
> understand this will allow us to define Jeepneys and AUVs as types of
> bus route_type, but dedicate ‘Jeepney’ and ‘AUV’ vehicle designations
> to them in the proposed vehicle_type field.

Neil Taylor

unread,
Jun 28, 2012, 1:53:48 PM6/28/12
to gtfs-c...@googlegroups.com
Yes. Completely agree... Apologies for my bad typing (leading to confusion) earlier!

Thanks for clarifying
Best regards
Neil Taylor
--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To post to this group, send email to gtfs-c...@googlegroups.com.
To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.


Brian Ferris

unread,
Jun 28, 2012, 3:55:10 PM6/28/12
to gtfs-c...@googlegroups.com
So to chime in late to the conversation, I'm definitely +1 on keeping route_type as a simple enum of base vehicle types that are easily internationalized.

I would like a little clarification on how route_type_name would be used in practice.  The examples I've seen mentioned in the thread seem to fall along a spectrum of localized vehicle type names (subway, underground, metro) to things that I'd call more of a branded service name (S-Bahn, 新幹線) and things that fall somewhere in-between (Regional Rail).  I mention this mostly in the context of somewhat related proposals for something like a route_service_name or route_branded_name that have been discussed recently.  Clearly, there is a demand for adding this stuff to feeds.  At that same time, I'd like to avoid the fate of route_long_name, which can pretty much hold anything at this point, which makes it difficult to figure out where and when it should be included in UI.

Brian

David Turner

unread,
Jun 28, 2012, 4:26:28 PM6/28/12
to gtfs-c...@googlegroups.com
On Thu, 2012-06-28 at 21:55 +0200, Brian Ferris wrote:
> So to chime in late to the conversation, I'm definitely +1 on keeping
> route_type as a simple enum of base vehicle types that are easily
> internationalized.
>
> I would like a little clarification on how route_type_name would be
> used in practice. The examples I've seen mentioned in the thread seem
> to fall along a spectrum of localized vehicle type names (subway,
> underground, metro) to things that I'd call more of a branded service
> name (S-Bahn, 新幹線) and things that fall somewhere in-between
> (Regional Rail). I mention this mostly in the context of somewhat
> related proposals for something like a route_service_name or
> route_branded_name that have been discussed recently. Clearly, there
> is a demand for adding this stuff to feeds. At that same time, I'd
> like to avoid the fate of route_long_name, which can pretty much hold
> anything at this point, which makes it difficult to figure out where
> and when it should be included in UI.
>
Looking at Google Transit in Tokyo, I see:

新宿駅(東京)
JR山手線 7,980円 各停 Train towards 渋谷方面
5:18am - 5:38am (20 mins, 8 stops)

品川駅(東京)
JR東海道・山陽新幹線 5,540円 のぞみ Shinkansen のぞみ99号 towards 博
多行
6:00am - 8:05am (2 hours 5 mins, 3 stops)

京都駅(京都)
烏丸線 250円 各停 Subway towards 国際会館行
8:17am - 8:23am (6 mins, 3 stops)
-------------------

This corresponds to (for example):

South Kensington
Piccadilly Line Subway towards Cockfosters
9:46pm - 9:55pm (10 mins, 5 stops)

Where do the words "Train", "Shinkansen", and "Subway" come from in the
GTFS? I had assumed (prior to noticing "Shinkansen") that they came
from route_type, and my hope was to replace this with route_type_name.
There doesn't seem to be a public GTFS feed for Japan, so I can't check
what they've coded to get that result. Maybe Google has special-cased
it?

Anyway, I think the description of route_type_name should be something
like:

The route_type_name field holds the name that is commonly used locally
to refer to the type of service for this route. This will be used
whenever a textual description of the route type is needed, as in 'Take
the route_type_name to stop_name', and should be a noun phrase. If this
field is left blank, a default based on route_type might be used
instead; for services that don't have a special name (for instance, most
buses are simply buses), it is best to leave route_type_name blank.
> +unsub...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/gtfs-changes?hl=en.
>
>
>
> This email (and any attachments) contains confidential
> information and is intended solely for the individual to whom
> it is addressed. If this email has been misdirected, please
> notify the author as soon as possible. If you are not the
> intended recipient you must not disclose, distribute, copy,
> print or rely on any of the information contained, and all
> copies must be deleted immediately.
>
> This footnote also confirms that this email message has been
> swept by anti-virus software, but Integrated Transport
> Planning Ltd cannot accept liability for any damage caused by
> receipt of this email.
> Please consider the environment before printing this e-mail.
>
>
> --
> You received this message because you are subscribed to the
> Google Groups "General Transit Feed Spec Changes" group.
> To post to this group, send email to
> gtfs-c...@googlegroups.com.
> To unsubscribe from this group, send email to gtfs-changes
> +unsub...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/gtfs-changes?hl=en.
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "General Transit Feed Spec Changes" group.
> To post to this group, send email to gtfs-c...@googlegroups.com.
> To unsubscribe from this group, send email to gtfs-changes
> +unsub...@googlegroups.com.

Neil Taylor

unread,
Jun 28, 2012, 4:38:10 PM6/28/12
to gtfs-c...@googlegroups.com
+1 from me for David's suggested definition of route_type_name.

Best regards
Neil Taylor

www.itpworld.net
To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.

Brian Ferris

unread,
Jun 28, 2012, 4:50:05 PM6/28/12
to gtfs-c...@googlegroups.com
So just play devil's advocate some more, would it be acceptable for an agency to put values like "Long Island Railroad" (aka a branded name) in there?  As an an agency, I might say "Hey, Take the Long Island Railroad to ... sounds good to me."

And yeah, we do a lot of custom localization configuration by hand, since you are right that GTFS doesn't capture all these cases.




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

Stuart Heinrich

unread,
Jun 28, 2012, 5:19:24 PM6/28/12
to gtfs-c...@googlegroups.com
No.  "MTA Long Island Railroad" is the name of the transit agency.  A proper noun, already has a place to be specified, and completely different from this field.
 
The reason this field is needed is to assist in translating the vehicle type (stored in route_type) field into a string, because the same type of physical vehicle may be referred to differently in different areas. 
 
The existing route_type field is an enumeration as follows:
  • 0 - Tram, Streetcar, Light rail. Any light rail or street level system within a metropolitan area.
  • 1 - Subway, Metro. Any underground rail system within a metropolitan area.
  • 2 - Rail. Used for intercity or long-distance travel.
  • 3 - Bus. Used for short- and long-distance bus routes.
  • 4 - Ferry. Used for short- and long-distance boat service.
  • 5 - Cable car. Used for street-level cable cars where the cable runs beneath the car.
  • 6 - Gondola, Suspended cable car. Typically used for aerial cable cars where the car is suspended from the cable.
  • 7 - Funicular. Any rail system designed for steep inclines.
So for example, if route_type=0, then route_type_name might be equal to "tram" or "streetcar" or "rail"...

Stuart Heinrich

unread,
Jun 28, 2012, 5:26:55 PM6/28/12
to gtfs-c...@googlegroups.com
Whereas route_type has the following descriotion:
 
> The route_type field describes the type of transportation used on a route. Valid values for this field are:
0 - Tram, streetcase, light rail.  Any light rail or street level system within a metropolitan area.
1 - ...
 
I would word the doc something like this:
 
> The route_type_name field describes the type of transportation used on the route as a freeform string.  This allows the route_type to be translated into the most appropriate string representation of the vehicle's type in accordance with the local vernacular.  It should not be capitalized and should not be a proper noun.

Brian Ferris

unread,
Jun 28, 2012, 5:28:56 PM6/28/12
to gtfs-c...@googlegroups.com
So that wasn't the best example on my part. I guess I'm just looking for stronger wording in the definition that that "route_type_name" is a localized name for the "route_type" value in the feed, so that it doesn't en up having branded service names put there (unless that's ok?).  Something like:

The route_type_name field holds the name that is commonly used locally to refer to the type of vehicle for this route.  This will be used whenever a textual description of the route_type field is needed, as in 'Take the route_type_name to stop_name', and should be a noun phrase.  If this field is left blank, a default based on route_type might be used instead.  For services that don't have a special name (for instance, most buses are simply buses), it is best to leave route_type_name blank.  The route_type_name name should not be used for a branded service name.

David Turner

unread,
Jun 28, 2012, 6:09:54 PM6/28/12
to gtfs-c...@googlegroups.com
On Thu, 2012-06-28 at 23:28 +0200, Brian Ferris wrote:
> So that wasn't the best example on my part. I guess I'm just looking
> for stronger wording in the definition that that "route_type_name" is
> a localized name for the "route_type" value in the feed, so that it
> doesn't en up having branded service names put there (unless that's
> ok?). Something like:
>
>
> The route_type_name field holds the name that is commonly used
> locally to refer to the type of vehicle for this route. This will be
> used whenever a textual description of the route_type field is needed,
> as in 'Take the route_type_name to stop_name', and should be a noun
> phrase. If this field is left blank, a default based on route_type
> might be used instead. For services that don't have a special name
> (for instance, most buses are simply buses), it is best to leave
> route_type_name blank. The route_type_name name should not be used
> for a branded service name.

Shinkansen is branded, but Google uses it in the field where I imagine
route_type_name would be used. Similarly, Underground. I'm not 100%
sure of the colloquial use of S-Bahn -- maybe it makes sense, maybe it
doesn't. I guess the difference between Shinkansen or Underground vs
LIRR (or Regional Rail) whether the name is used to refer to the mode vs
the specific service. That's a subtle distinction, but one that I guess
I would be willing to defend.

>
> On Thu, Jun 28, 2012 at 11:19 PM, Stuart Heinrich
> <sbhe...@gmail.com> wrote:
> No. "MTA Long Island Railroad" is the name of the transit
> agency. A proper noun, already has a place to be specified,
> and completely different from this field.
>
> The reason this field is needed is to assist in translating
> the vehicle type (stored in route_type) field into a string,
> because the same type of physical vehicle may be referred to
> differently in different areas.
>
> The existing route_type field is an enumeration as follows:
> * 0 - Tram, Streetcar, Light rail. Any light rail or
> street level system within a metropolitan area.
> * 1 - Subway, Metro. Any underground rail system within
> a metropolitan area.
> * 2 - Rail. Used for intercity or long-distance travel.
> * 3 - Bus. Used for short- and long-distance bus
> routes.
> * 4 - Ferry. Used for short- and long-distance boat
> service.
> * 5 - Cable car. Used for street-level cable cars where
> the cable runs beneath the car.
> * 6 - Gondola, Suspended cable car. Typically used for
> aerial cable cars where the car is suspended from the
> cable.
> * 7 - Funicular. Any rail system designed for steep

Stuart Heinrich

unread,
Jun 28, 2012, 6:32:28 PM6/28/12
to gtfs-c...@googlegroups.com
I think that the discussion is being confused with two completely separate needs.  One need is the colloquial or shortname description of the transit agency.  The other need is a description of the physical vehicle type.
 
If route_type_name contains "bus" in some circumstances, it cannot contain "Shinkansen", "Underground" or "S-Bahn" or any other proper noun because the usage is completely different. 
 
The confusion comes from the fact that you might say:
 
"Take the bus from A to B" or "Take the Underground from A to B" or "Take the BART from A to B"...which might lead one to think, initially, that these fields are compatible when they are actually not.
 
For example, you cannot take the sentence template,
 
"You are riding on a bus" and change it to "You are riding on a Underground"
 
Consider the following three sentences, all of which it should be possible to generate:
 
"You are riding on a bus."
"Take the MUNI from A to B."
"Take the MUNI bus from A to B."
 
Replacing these with their field equivalents:
 
"You are riding on a [ROUTE_TYPE_NAME]."
"Take the [AGENCY_SHORTNAME] from A to B"
"Take the [AGENCY_SHORTNAME] [ROUTE_TYPE_NAME] from A to B."
 
Suppose that the agency name is London Underground and then someone were to put Underground as route_type_name, then we'd have:
 
"Take the [London Underground] [Underground] from A to B"
 
Currently, agency_shortname is not present..and I think there is a common need for this as well as route_type_name.  I have mentioned this need to the GTFS group before and I don't think made any progress, but this seems like a good time to bring it up again.  Currently we just augment all GTFS feeds by manually adding this column into the agency.txt table.
 
S-Bahn, LIRR, Underground, Shinkansen are all examples of what should be put into agency_shortname field, not route_type_name.

Brian Ferris

unread,
Jun 28, 2012, 6:45:55 PM6/28/12
to gtfs-c...@googlegroups.com
I agree that they are separate concepts.  I just want to make sure an agency reading the spec a year or so from now is clear on the distinction as well, so we avoid drift in the meaning of field and complications for feed consumers.

Brian

David Turner

unread,
Jun 28, 2012, 9:25:31 PM6/28/12
to gtfs-c...@googlegroups.com
Then, other than "jeepney", "AUV", and maybe "coach", what do you
envision going in route_type_name? I guess I could imagine "trolley" or
"trolleybus" for some systems.

Also, if we wish to describe a subway as "the underground" or "the tube"
in London (since a "subway" usually means a pedestrian underpass), we
need to do something; what do you suggest? Is it unrealistic to expect
to be able model this?

Keep in mind that Google already uses "Shinkansen" in place of the
generic descriptors generated from route_type; as long as the usage is
limited to descriptors not in complete sentences, this will work out
OK.
> To unsubscribe from this group, send email to gtfs-changes

Jonathan Wilson

unread,
Jun 28, 2012, 10:34:15 PM6/28/12
to gtfs-c...@googlegroups.com
The way I see it, we need to communicate the following information:
1.The route type (used for the icon).

I would advocate item 1 being made into a more general "short-journey rail"
for anything that is considered intra-urban rail, be it underground,
elevated (ala the Chicago El) or at ground level.

Item 2 would be for long distance rail (which usually departs from a
central departure point and doesn't stop at commuter-rail stations on the
way out of town)

Item 3 would be for bus services (which generally implies frequent
stopping, shorter routes, standing-permitted etc)

Then I would add an item 8 for coach services (generally longer distance
services connecting destinations, most are pre-paid, generally sit-down only)

When to use item #1 vs #2 and #3 vs #8 would be up to the agency (just
because an agency uses a coach-type vehicle on a normal bus run doesn't
mean it necessarily has to be labeled as a "coach", especially if a mixture
of coach and bus vehicles are used on the service as is the case on the
examples I have seen)

2.The vehicle type (which would be a noun), examples might be:
"Shinkansen"
"Tram"
"TGV"
"Bus"
"Jeepny"
"Hovercraft"
"City Cat" (a specific branded type of ferry)
"Coach"
"Monorail"
"Train"

It would have a relationship to signage at the station or stop and to what
the vehicle is known as in common usage and would be used to differentiate
between different but related vehicle types that stop at the one station or
stop.

3.The mode type which would differentiate different mode types, e.g.:
"Underground"
"Subway"
"Light Rail"
"El"
"S-Baun"
"Metro"

Designations like "Express", "Limited Stops" and so on would be best
covered by the route name/description fields.

Bradley Tollison

unread,
Jun 29, 2012, 12:56:29 AM6/29/12
to gtfs-c...@googlegroups.com
I agree with Brian's concerns simply because I had already considered using it for branded buses, in Los Angeles limited stop services which may or may not have signal priority are known as "rapid," and they're a big deal here. They're heavily marketed and you'd be hard pressed to find an agency not willing to exploit any opportunity to advertise it here.

David Turner

unread,
Jun 29, 2012, 2:22:05 PM6/29/12
to gtfs-c...@googlegroups.com
On Fri, 2012-06-29 at 10:34 +0800, Jonathan Wilson wrote:
> The way I see it, we need to communicate the following information:

> 2.The vehicle type (which would be a noun), examples might be:
> "Shinkansen"
> "Tram"
> "TGV"
> "Bus"
> "Jeepny"
> "Hovercraft"
> "City Cat" (a specific branded type of ferry)
> "Coach"
> "Monorail"
> "Train"
>
> It would have a relationship to signage at the station or stop and to what
> the vehicle is known as in common usage and would be used to differentiate
> between different but related vehicle types that stop at the one station or
> stop.
>
> 3.The mode type which would differentiate different mode types, e.g.:
> "Underground"
> "Subway"
> "Light Rail"
> "El"
> "S-Baun"
> "Metro"

I'm not sure I understand the distinction between 2 and 3. "Shinkansen"
seems to be as much in category 3 as category 2. Maybe that means it
could go in both?

But to bring this back to a concrete proposal, I would be willing to
ignore the complexities of system naming (your #3) for now, and simply
have route_type_name refer to the type of vehicle used on the system.
That could be branded or not, but won't ever include agency or route
names.

Does that meet everyone's approval?


Jonathan Wilson

unread,
Jun 30, 2012, 2:29:11 AM6/30/12
to gtfs-c...@googlegroups.com
> I'm not sure I understand the distinction between 2 and 3. "Shinkansen"
> seems to be as much in category 3 as category 2. Maybe that means it
> could go in both?
The "vehicle type" would be used to differentiate between different kinds
of vehicles at a given stop or station platform (e.g. "Eurostar" vs TGV"
when both stop at the central railway station in Paris or e.g. "Jeepny" vs
"Bus" vs "Van" all of which might serve passengers at a given stop)

The "system type" in my proposal (which would be optional) would be used
when the operator wants to indicate what the mode is.
It would be of value when there are multiple modes departing from a single
location or complex and there is a desire to indicate which mode is the
right one (so people know which part of the complex they need to go to)
e.g. ThamesLink vs mainline vs Underground at Kings Cross St Pancras.

David Turner

unread,
Jul 2, 2012, 5:31:27 PM7/2/12
to gtfs-c...@googlegroups.com
On Fri, 2012-06-29 at 14:22 -0400, David Turner wrote:
> But to bring this back to a concrete proposal, I would be willing to
> ignore the complexities of system naming (your #3) for now, and simply
> have route_type_name refer to the type of vehicle used on the system.
> That could be branded or not, but won't ever include agency or route
> names.

Now that I've heard back from Jonathan Wilson, I have some exact text:

The route_type_name field identifies the type of vehicle serving this
route. Examples include TGV, jeepny, AUV, hovercraft, City Cat, coach,
or monorail. The route_type_name should never include the names or
abbreviations for agencies or particular routes.

If the route type would be the same as one of the enumerated types in
route_type (bus, for instance), it must be left blank.



Stuart Heinrich

unread,
Jul 2, 2012, 6:10:38 PM7/2/12
to gtfs-c...@googlegroups.com
On Mon, Jul 2, 2012 at 2:31 PM, David Turner <nov...@novalis.org> wrote:
On Fri, 2012-06-29 at 14:22 -0400, David Turner wrote:
> But to bring this back to a concrete proposal, I would be willing to
> ignore the complexities of system naming (your #3) for now, and simply
> have route_type_name refer to the type of vehicle used on the system.
> That could be branded or not, but won't ever include agency or route
> names.

Now that I've heard back from Jonathan Wilson, I have some exact text:

The route_type_name field identifies the type of vehicle serving this
route.  Examples include TGV, jeepny, AUV, hovercraft, City Cat, coach,
or monorail.  The route_type_name should never include the names or
abbreviations for agencies or particular routes.
 
 
I find these examples confusing for several reasons. 
 
1) The description says not to use names or abbreviations of agencies, yet your examples include both abbreviations and names of proper noun brand name agencies such as Jeepney, CityCAT, and TGV (note spelling corrections).  The difference is that these agencies produce vehicles that are used by differently named transit agencies.  If we are discussing the actual vehicle type, then TGV is "electric train" or "electric rail", and CityCAT is simply a "car".  I think it is acceptable and useful to refer to them by their branded names, but this distinction should be noted in the description.
 
2) The examples should all be realistic transit vehicles...an Autonomous Unamned Vehicle (AUV) or hovercraft are generally not such.  I think its best to list only the most obvious examples rather than the edge cases...putting edge cases in the list only makes it confusing what the field represents and increases the chances that many agencies will treat it as a "free form" input that they can simply put anything into. 
 

If the route type would be the same as one of the enumerated types in
route_type (bus, for instance), it must be left blank.

 
 
Disagree.  The route_type field maps to a CLASS of vehicles, such as 0 = "Any light rail or street level system within a metropolitan area" rather than to a specific named vehicle type.  Every consumer that attempts to map the class name to a string will do so in an implementation dependent way.  Thus, you cannot say "if the route_type_name (string) would be the same as one of the enumerated types..." because there is no way to test for this "equality."
 
How I would word it:
 
route_type_name is an optional field that is used to describe the type of vehicle as referred to locally.  This is different from route_type which describes the general class of vehicle.  If route_type_name is omitted, most systems will infer a generic name based on the route_type field.

David Turner

unread,
Jul 2, 2012, 7:38:46 PM7/2/12
to gtfs-c...@googlegroups.com
I was actually thinking of CityCat, not CityCAT:
http://www.brisbane.qld.gov.au/traffic-transport/public-transport/citycat-ferry-services/index.htm

None of these are the names of agencies; TGV trains are run by SCNF;
jeepney is a common noun (it's in the OSPD), and CityCat ferries are run
by TransdevTSL.

It's true that these are not the most generic names for these vehicles,
but that's the point; route_type already has generic names.

> 2) The examples should all be realistic transit vehicles...an
> Autonomous Unamned Vehicle (AUV) or hovercraft are generally not such.

And, here, I was talking about an Asian Utility Vehicle, which is one of
the actual examples motivating this thread. Hovercraft are, indeed, rare
but not unheard of.

> I think its best to list only the most obvious examples rather than
> the edge cases...putting edge cases in the list only makes it
> confusing what the field represents and increases the chances that
> many agencies will treat it as a "free form" input that they can
> simply put anything into.

Maybe we should have some counterexamples?

> If the route type would be the same as one of the enumerated
> types in
> route_type (bus, for instance), it must be left blank.
>

>
> Disagree. The route_type field maps to a CLASS of vehicles, such as 0
> = "Any light rail or street level system within a metropolitan area"
> rather than to a specific named vehicle type. Every consumer that
> attempts to map the class name to a string will do so in an
> implementation dependent way. Thus, you cannot say "if the
> route_type_name (string) would be the same as one of the enumerated
> types..." because there is no way to test for this "equality."

OK, fair enough. I had forgotten that the enumeration of vehicle names
that OTP uses was non-canonical. How about appending to your proposal,
"Leaving route_type blank will allow systems to produce
internationalized names, where appropriate."

> How I would word it:
>
> route_type_name is an optional field that is used to describe the type
> of vehicle as referred to locally. This is different from route_type
> which describes the general class of vehicle. If route_type_name is
> omitted, most systems will infer a generic name based on the
> route_type field.

Given the discussion we have been having on this list, I think it makes
sense to include some examples and counterexamples.


Brian Ferris

unread,
Jul 10, 2012, 10:24:08 AM7/10/12
to gtfs-c...@googlegroups.com
Just to pick this discussion back up, I think I might be more comfortable with the proposed field if it was named something like "localized_route_type" to stress the fact that it's a localized name for the route_type field.  Granted, "localized" is a loaded term for me because I'm a software engineer, but I'm curious what others think.

Either way, David, I'm curious if you have a most recent / best version of the proposed field description text that incorporates the discussion so far?

Brian


Neil Taylor

unread,
Jul 10, 2012, 12:36:58 PM7/10/12
to gtfs-c...@googlegroups.com

I have no problem with “localized_route_type” as a descriptor, since it seems like a sensible way of defining what we are talking about (but I’m not a software engineer!).  From the Metro Manila perspective, from which I picked up this thread a few weeks ago, it would enable a trip planner to differentiate between AUV’s and Jeepneys, as well as different types of buses (Aircon and Non-Aircon) which are colloquially used to determine fares for similar trips.

 

Best regards

Neil

This email (and any attachments) contains confidential information and is intended solely for the individual to whom it is addressed. If this email has been misdirected, please notify the author as soon as possible. If you are not the intended recipient you must not disclose, distribute, copy, print or rely on any of the information contained, and all copies must be deleted immediately.

David Turner

unread,
Jul 10, 2012, 12:48:19 PM7/10/12
to gtfs-c...@googlegroups.com
On Tue, 2012-07-10 at 16:24 +0200, Brian Ferris wrote:
> Just to pick this discussion back up, I think I might be more
> comfortable with the proposed field if it was named something like
> "localized_route_type" to stress the fact that it's a localized name
> for the route_type field. Granted, "localized" is a loaded term for
> me because I'm a software engineer, but I'm curious what others think.

How about localized_vehicle_type? Route_type at present is somewhat
ambiguous between the type of vehicle and the type of track. Of course,
that's unavoidable, since sometimes one type of vehicle could use two
types of track (i.e. the various subway-surface lines, or the SIR using
subway cars). Since this field is intended only to describe vehicles,
we should make that clear in the name.

> Either way, David, I'm curious if you have a most recent / best
> version of the proposed field description text that incorporates the
> discussion so far?

localized_vehicle_type is an optional field that is used to describe the
type of vehicle as referred to locally. This is different from
route_type which describes the general class of vehicle. If
localized_vehicle_type is omitted, most systems will infer a generic
name based on the route_type field. Leaving localized_vehicle_type blank
will allow systems to produce internationalized names from route_type,
where appropriate. Examples include TGV, jeepney, AUV[1], CityCat[2],
coach, or monorail. Counterexamples include LIRR (same as agency name),
subway (general class; equivalent to an option in route_type), S-Bahn or
Metro (describes type of system rather than type of vehicle), and
express (describes type of service not type of vehicle).

Those [1] and [2] should be linked to the appropriate pages, specifying
that AUV refers to an Asian Utility Vehicle, and CityCat refers to a
type of ferry.

The list of examples is unchanged but for a spelling correction, since I
didn't see any response to my response to Stuart.
> +unsub...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/gtfs-changes?hl=en.
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "General Transit Feed Spec Changes" group.
> To post to this group, send email to gtfs-c...@googlegroups.com.
> To unsubscribe from this group, send email to gtfs-changes
> +unsub...@googlegroups.com.

David Turner

unread,
Jul 10, 2012, 1:27:45 PM7/10/12
to gtfs-c...@googlegroups.com
So the inventory of localized_vehicle_type for Metro Manila would be:
--------------
AUV
jeepney
aircon bus
non-aircon bus
--------------
Is that right? And is "aircon bus" (or just "aircon"?) how locals refer
to the vehicles?
> +unsub...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/gtfs-changes?hl=en.
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "General Transit Feed Spec Changes" group.
> To post to this group, send email to gtfs-c...@googlegroups.com.
> To unsubscribe from this group, send email to gtfs-changes
> +unsub...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/gtfs-changes?hl=en.
>
>
> This email (and any attachments) contains confidential information and
> is intended solely for the individual to whom it is addressed. If this
> email has been misdirected, please notify the author as soon as
> possible. If you are not the intended recipient you must not disclose,
> distribute, copy, print or rely on any of the information contained,
> and all copies must be deleted immediately.
>
> This footnote also confirms that this email message has been swept by
> anti-virus software, but Integrated Transport Planning Ltd cannot
> accept liability for any damage caused by receipt of this email.
> Please consider the environment before printing this e-mail.
> --
> You received this message because you are subscribed to the Google
> Groups "General Transit Feed Spec Changes" group.
> To post to this group, send email to gtfs-c...@googlegroups.com.
> To unsubscribe from this group, send email to gtfs-changes
> +unsub...@googlegroups.com.

Neil Taylor

unread,
Jul 10, 2012, 2:07:04 PM7/10/12
to gtfs-c...@googlegroups.com
Hi David

Here is the correct inventory of localized_vehicle_type for Metro Manila:
--------------
AUV
jeepney
aircon bus
non-aircon bus
--------------

Sometimes non-aircon buses are referred to colloquially as 'ordinary buses', but 'non-aircon bus' is probably more commonly used and more specific, so I would advocate that as the best term.

Best regards
Neil
To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.

David Turner

unread,
Nov 28, 2012, 2:57:35 PM11/28/12
to gtfs-c...@googlegroups.com
When last we discussed this, there were no objections to the following
text. OTP could incorporate this relatively easily.

Are there any objections now?

If there are no objections: Brian, if I submit a patch to OBA-GTFS to
support this field, will you merge it?


localized_vehicle_type is an optional field that is used to describe the
type of vehicle as referred to locally. This is different from
route_type which describes the general class of vehicle. If
localized_vehicle_type is omitted, most systems will infer a generic
name based on the route_type field. Leaving localized_vehicle_type blank
will allow systems to produce internationalized names from route_type,
where appropriate. Examples include TGV, jeepney, AUV[1], CityCat[2],
coach, or monorail. Counterexamples include LIRR (same as agency name),
subway (general class; equivalent to an option in route_type), S-Bahn or
Metro (describes type of system rather than type of vehicle), and
express (describes type of service not type of vehicle).

[1] http://en.wikipedia.org/wiki/Minivan#Asia
[2]
http://www.brisbane.qld.gov.au/traffic-transport/public-transport/citycat-ferry-services/index.htm

On Wed, 2012-11-28 at 06:16 -0800, John wrote:
> Adding Minibus would be very useful for those of us who use Marshutnis/Marshrutkas (minibusses popular in post USSR countries).
>
> We (my project team) came to this group for this specific purpose.
>
> On Thursday, November 8, 2012 6:10:22 AM UTC+4, sakarp wrote:
> > Hi All,
> >
> >
> > Was there any progress on this? Was a decision made?
> >
> > I'm writing in from Kathmandu, Nepal where we would need a localized_vehicle_type or similar field. For the Kathmandu Valley Metro area that field would contain:
> >
> >
> > 1. Bus/बस (already accommodated by route type)
> > 2. MiniBus/मिनिबस
> > 3. Tempo/टेम्पो
> > 4. Micro/मिक्रो
> >
> >
> > As we move out the valley with our work we might also use it for night bus, tourist bus (both terms that suggest the availability of certain kinds of comforts and certain expectations of how stuff in you will be rather than who rides them). But we have not given the out of valley transport enough thought to commit.
> >
> >
> > -Sakar
> >
> > On Tuesday, July 10, 2012 11:52:04 PM UTC+5:45, Neil Taylor wrote:Hi David

Neil Taylor

unread,
Nov 28, 2012, 3:21:17 PM11/28/12
to gtfs-c...@googlegroups.com
+1 from me for OTP support for this proposal

Cheers
Neil
----- Original Message -----
From:David Turner <nov...@novalis.org>
To:"gtfs-c...@googlegroups.com" <gtfs-c...@googlegroups.com>
This footnote also confirms that this email message has been swept by anti-virus software, but Integrated Transport Planning cannot accept liability for any damage caused by receipt of this email.

Neil Taylor

unread,
Nov 28, 2012, 3:22:57 PM11/28/12
to gtfs-c...@googlegroups.com
I mean OBA!

Best regards

John

unread,
Nov 28, 2012, 3:37:13 PM11/28/12
to gtfs-c...@googlegroups.com
+1 for us (Yerevan Armenia Team).

A bit of overkill, but this is still my first day here, but to give our examples: We would need 3 categories for localized_vehicle_type since they are treated separately. 

a) Marshrutkas, the common mini-bus/minivan type of shuttle found in post USSR countries
b) Busses
c) Metro, both over- and under-ground. I know this was described as a counterexample, but our metro line consists of less than 15 points, with only one fork at one end. The rails move underground throughout city-center, but a few stops toward the south are above ground. 

Route numbers here are provided for these types and both a) and b) groups share numbers (since locals differentiate between the 2 types for travel within the city, ie, the 1 Bus and 1 Marshrutka are different.

Also, if I'm going about this the wrong way, please inform me of such. I'm still trying to get the grasp of how this group works.

-John

Joe Hughes

unread,
Feb 20, 2008, 8:20:04 PM2/20/08
to Google Transit Feed Spec Changes
Summary:
This proposal adds new types to route_type, and adds structure to the
set of values so that clients that don't need finer distinctions can
easily determine which broad category a route falls into.

Motivation:
The route_type field in GTFS gives a client application enough
information to display appropriate icons and/or localized text
descriptions of the route, in order to give riders a general sense of
what type of vehicle they'd be boarding. Client applications can also
use this field to favor certain modes in trip planning and map
displays.

The goal of this update is to expand the set of distinct travel modes
that can be expressed within GTFS, while still keeping it relatively
easy to determine how a route should be classified. It also allows
clients to group different route types into a relatively small set of
high-level types by checking number ranges.

It's not a goal of this system to perfectly identify and classify
every transit route in the world, nor should the brand identity of
individual systems be encoded in this list. The tests for adding a
new type are:

1. Are there or were there ever several routes of this type in the world?
2. Does this type require a linguistic and visual representation
that's significantly different from existing types?

Proposal:
For a nicely-formatted version of the new value chart (including
examples), see the following page:
http://groups.google.com/group/gtfs-changes/web/route-type-proposal

The list is also approximated below for the benefit of email readers:

1000 - Generic Rail
1100 - Generic Local Rail
1101 - Tram, Light Rail, Streetcar
1102 - Subway
1103 - Metro Rail
1104 - Monorail
1105 - People Mover
1106 - Funicular
1107 - Cable Car
1200 - Generic Longer-Distance Rail
1201 - Commuter Rail
1202 - Intercity Rail
1203 - High-Speed Rail

2000 - Generic Bus
2100 - Generic Local Bus
2101 - Regular Local Bus
2102 - Trolleybus
2200 Generic Longer-Distance Bus/Coach
2201 Commuter Bus/Coach
2202 Intercity Bus/Coach

3000 - Generic Boat/Ferry

4000 - Generic Air Travel

9000 - Miscellaneous
9001 - Suspended Gondola Lift, Aerial Tram
9002 - Horse-Drawn Carriage

Deprecated Types

The values below are retained for backwards-compatibility with
existing feeds; feed-reading applications should continue to
understand these, but they shouldn't be used in new feeds.

Existing Value - Meaning - Corresponding New Value
0 - Tram, Light Rail, Streetcar - 1101
1 - Subway, Metro - 1102
2 - Rail - 1000
3 - Bus - 2000
4 - Ferry - 3000
5 - Cable Car - 1107
6 - Gondola, Suspended cable car - 9001
7 - Funicular - 1106

Comments?

Joe

Marc Ferguson

unread,
Feb 21, 2008, 8:31:28 AM2/21/08
to gtfs-c...@googlegroups.com

To me differentiating between Subway and "Metro Rail" is splitting hairs.  It is really a local terminology issue.

What about creating a new file that allows the data provider to assign a local label to one of the standard codes.  
        New York - 1102 = Subway
        DC - 1102 = MetroRail
        London - 1102 = Tube
        Portland OR - 1101 = MAX
        Boston - 1101 = Green Line

This could also be extended to allow the data source to define local types by specifying the last 2 digits.  For example;
        If the source has both express and commuter buses in their local vernacular then:
                2201 = Commuter Bus
                2210 = Express Bus

Marc



"Joe Hughes" <joe.hug...@gmail.com>
Sent by: gtfs-c...@googlegroups.com

02/20/2008 08:20 PM

Please respond to
gtfs-c...@googlegroups.com

To
"Google Transit Feed Spec Changes" <gtfs-c...@googlegroups.com>
cc
Subject
[gtfs-changes] proposal: Modify route_type to add new types and to group similar types together


Mike Gilligan

unread,
Feb 21, 2008, 1:41:30 PM2/21/08
to Google Transit Feed Spec Changes
I propose that 1101 - Tram, Light Rail, Streetcar be separated into 2
categories:
- Light Rail
- Tram, Streetcar

In Portland:
-Tram/Streetcar operates in a mixed mode environment with other
traffic and is subject to regular traffic signals. Similar capacity to
bus.
-Light Rail has private right-of-ways when traveling on city streets
and separate signal priority. High capacity.

This change would make it easier for the developers at TriMet to adopt
the GTFS in future open source development.

Thanks,
-Mike

On Feb 21, 5:31 am, Marc Ferguson <Marc.Fergu...@trapezegroup.com>
wrote:
> To me differentiating between Subway and "Metro Rail" is splitting hairs.
> It is really a local terminology issue.
>
> What about creating a new file that allows the data provider to assign a
> local label to one of the standard codes.
> New York - 1102 = Subway
> DC - 1102 = MetroRail
> London - 1102 = Tube
> Portland OR - 1101 = MAX
> Boston - 1101 = Green Line
>
> This could also be extended to allow the data source to define local types
> by specifying the last 2 digits. For example;
> If the source has both express and commuter buses in their local
> vernacular then:
> 2201 = Commuter Bus
> 2210 = Express Bus
>
> Marc
>
> "Joe Hughes" <joe.hughes.c...@gmail.com>

Marc Ferguson

unread,
Feb 21, 2008, 1:53:21 PM2/21/08
to gtfs-c...@googlegroups.com

And let's not forget a category for the up and coming BRT (Bus Rapid Transit).  I see BRT as Light Rail with rubber wheels.   BRT implementations can include:  new "high tech" buses; limited stops; stops that look more like at grade light rail platforms and, in some cases, limited access bus ways.

It probably should be it's own item in the 22XX series because these services are being "marketed" to the public as "new and different."

Marc



Mike Gilligan <mgil...@gmail.com>
Sent by: gtfs-c...@googlegroups.com

02/21/2008 01:41 PM

Please respond to
gtfs-c...@googlegroups.com

To

Google Transit Feed Spec Changes <gtfs-c...@googlegroups.com>

cc
Subject
[gtfs-changes] Re: proposal: Modify route_type to add new types and to group similar  types together


Nicholas Albion

unread,
Feb 21, 2008, 5:22:53 PM2/21/08
to Google Transit Feed Spec Changes
This idea sounds similar to my suggestion (perhaps privately to Joe)
of adding a "locale" field (perhaps in a separate file?)

route_descriptions.txt
route_type description locale
1106 Funicular
1106 Inclined rail en-AU
1106 Le train en les mont fr
3001 Water Taxi en
3001 Gondola it
9001 Gondola en
9001 Téléférique de Montjuïc fr

...Perhaps it would be nice to be able to indicate which version/
standard/source/convention was being used in this file also - that
would be easier with an XML-based format...

Joe Hughes

unread,
Feb 28, 2008, 10:38:32 PM2/28/08
to gtfs-c...@googlegroups.com
Thanks for your comments so far.

The distinction between "Metro Rail" and "Subway" is something that
the Google engineers working on adding European data lobbied for; it's
a more significant distinction there.

Mike made a good case for making a distinction between "Light Rail"
(generally dedicated right-of-way) and "Streetcar/Tram" (generally
mixed-traffic street-running). Does the distinction make sense for
those of you that are currently providing feeds with rail systems?

Marc also suggested adding BRT in the "longer-distance bus" category,
which sounds reasonable.

As for the proposals for specifying local names for modes, they seems
like they could be layered on top of this basic skeleton, so I'd like
to propose that we consider them separately later.

Other comments on these issues or the basic proposal?

Joe Hughes
Google

Devin Braun

unread,
Feb 29, 2008, 11:17:33 AM2/29/08
to Google Transit Feed Spec Changes
On Feb 28, 7:38 pm, "Joe Hughes" <joe.hughes.c...@gmail.com> wrote:
> Marc also suggested adding BRT in the "longer-distance bus" category,
> which sounds reasonable.

I second the BRT category. San Diego will open a large BRT system in
2011, and it will be marketed that way. It's the new way of saving
money on fixed guideway transit systems and we'll be seeing a lot of
these systems in the future in the U.S.

> As for the proposals for specifying local names for modes, they seems
> like they could be layered on top of this basic skeleton, so I'd like
> to propose that we consider them separately later.

If you asked a San Diegan if you could