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

3,920 views
Skip to first unread message

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
----- Original Message -----
From:David Turner <nov...@novalis.org>
To:"gtfs-c...@googlegroups.com" <gtfs-c...@googlegroups.com>
Sent:28/06/2012 18:31
Subject:RE: [gtfs-changes] Re: proposal: Modify route_type to add new types and to group similar types together


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.


--
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.

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 take light rail to the U.S./
Mexico border, they'd look at you dumbfounded. If you asked them if
you can take the Trolley to the U.S./Mexico border, they'd tell you of
course, they do it all the time! So in a sense, local names for
different modes would be eventually very beneficial.

Devin Braun
San Diego MTS

Roger Slevin

unread,
Feb 29, 2008, 11:34:04 AM2/29/08
to gtfs-c...@googlegroups.com
Devin and all

I wondered how long it would be before someone referred to Trolley. This
word is not consistently used worldwide ... and I suspect your use of Coach
and several other mode descriptors will be different to that in UK English.

(A trolley is a rubber tired vehicle taking power from two overhead wires -
a tram is a rail-based vehicle taking power from a single overhead wire (or
in some cases from a protected central conductor in the roadway.

I haven't yet had time to check how the Google proposal fits with the
existing TPEG standard in Europe which already has a comprehensive
classification of public transport modes. It would be helpful if GTDF were
not to invent another classification - we need to work towards convergence
of standards, not yet more ad hoc versions. Perhaps Joe or others can
assure me that the proposed Google classification is based on TPEG's ... if
not, I think we should look at that already established standard as the way
forward.

Best wishes

Roger Slevin
Traveline south east

-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]

On Behalf Of Devin Braun
Sent: 29 February 2008 16:18
To: Google Transit Feed Spec Changes
Subject: [gtfs-changes] Re: proposal: Modify route_type to add new types and
to group similar types together


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


Marc Ferguson

unread,
Feb 29, 2008, 11:47:07 AM2/29/08
to gtfs-c...@googlegroups.com

Given the last two comments from Devin in San Diego and Roger from across the pond.  Maybe we should get back to the motivation for doing this.

I would postulate that the codes be used to control the display of icons representing the mode of travel.  Without using to operator specific icons, e.g. VRE, MARC, Amtrak in the Baltimore Washington area, there are a fairly limited set of icons to be used to denote the type of service.

Once you get away from the icon issue, the question becomes how does the characteristics of the service differ and how is it relevant to the journey planning process?   Take for example:
     1201 - Commuter Rail
    1202 - Intercity Rail
    1203 - High-Speed Rail


These have the same operational characteristics, heavy rail using diesel/electric locomotives. The remaining differences are user perception.  Intercity and High-speed may imply fewer stops but the journey planning process resolves the time issue.

And what is subway?   Generally it is wide gauge, self propelled vehicles that operate underground to a large extent.

And light rail?  Narrow gauge, self propelled vehicles that frequently operate "at grade."  They may or may not have dedicated right of ways.


As Roger pointed out trolley has a specific meaning in Europe.  In San Diego it more a "brand name."   In Seattle they have buses that meet the description of a tram but they just call them buses.

BRT is, in one cynical sense, light rail with rubber wheels.  In some implementations they are just limited stop buses, a.k.a. express buses.  In other places they are getting their own dedicated lanes and some places are allowing them to do traffic signal preemption.

What Devin brought up is the difference between the type of service, light rail, and the name of the service, Trolley - Blue line.  The route_type should only be used to change the symbology associated with the response.  Route_type may play a role in the processing of the request and it is here that the local "term" for the type of service would be important.  In San Diego calling the Trolley light rail would confuse folks.  Same for MAX in Portland or the Staten Island Railroad in Staten Island NY.

I think I've started to ramble .....

Marc



02/28/2008 10:38 PM

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

To
gtfs-c...@googlegroups.com
cc
Subject
[gtfs-changes] Re: proposal: Modify route_type to add new types and to group similar types together


Joe Hughes

unread,
Feb 29, 2008, 1:04:55 PM2/29/08
to gtfs-c...@googlegroups.com
Hi Marc,

You're right, it's worth looking at the motivations for wanting these
distinctions. I think I detailed some of them in my initial proposal
post, but I'll elaborate with some information about concrete uses.

You brought up whether it was worth making a distinction between
intercity rail and commuter rail. Google does think the distinction
is salient from a rider perspective; for instance, when showing the
bubble indicating next departures from a rail station, Google Maps
groups the departures into "commuter trains" and (intercity) "trains":
http://tinyurl.com/2jj4k7

In Google Maps's implementation of GTFS, route_type factors into
several client decisions:
1) How to group routes in a next-departure display
2) Which generic name to use in routing directions and next-departure
displays (this is localized by the client software to account for
differences between, say, US English and UK English)
3) Which generic icon to use to represent the service
4) At which zoom level to show the station icons are shown

These were the concrete considerations which motivated the particular
breakdown in the proposal I posted.

As you mention, there are some cases where we might want to have
agency-specific icons because they're well-known to riders, for
instance:
http://tinyurl.com/383avg

As you can see, Google already has an internal mechanism for
specifying agency-specific icons (and mode names), which is orthogonal
to route_type. The Google Maps implementation has convinced me that
it's workable to keep these sorts of specializations distinct from the
route type taxonomy, and so I'd like to keep the discussion to the
generic taxonomy for now, since that alone is proving contentious
enough.

Joe

On Fri, Feb 29, 2008 at 8:47 AM, Marc Ferguson

Joe Hughes

unread,
Feb 29, 2008, 1:08:01 PM2/29/08
to gtfs-c...@googlegroups.com
Roger,

I would welcome a concrete proposal for how you think the TPEG
taxonomy should be adapted for use in GTFS. It would also be
interesting to learn which agencies/operators output TPEG information
today.

Thanks,
Joe

Nicholas Albion

unread,
Mar 1, 2008, 1:29:05 AM3/1/08
to Google Transit Feed Spec Changes
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...

Nicholas Albion

unread,
Mar 1, 2008, 1:37:49 AM3/1/08
to Google Transit Feed Spec Changes
Brisbane has 2 modes of water transport - ferry and "city cat". The
distinction is quite significant as (generally) is provided for cross-
river travel, and the other is (generally) used for travel further up/
down the river. The branding "city cat" is also important - if it
were to be displayed as "water taxi" or "ferry" it would confuse
people. It may also be desirable for the operators to provide their
own icon to represent the service.

Joe Hughes

unread,
Mar 1, 2008, 11:21:57 AM3/1/08
to gtfs-c...@googlegroups.com
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

Roger Slevin

unread,
Mar 1, 2008, 12:54:09 PM3/1/08
to gtfs-c...@googlegroups.com
Joe

I am trying to locate an up to date set of documentation to check whether
this is the complete and current TPEG standard, or an earlier version that
underpins the BBC's implementation of TPEG. I hope to have something in a
few days time.

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,

Roger,

Joe

--

Roger Slevin

unread,
Mar 1, 2008, 12:58:01 PM3/1/08
to gtfs-c...@googlegroups.com
Joe

I think http://www.bbc.co.uk/travelnews/xml/pti/pti_index.html actually
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,

Roger,

Joe

--

Nicholas Albion

unread,
Mar 2, 2008, 5:53:32 PM3/2/08
to Google Transit Feed Spec Changes
> 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.

Actually, that's precisely what I was trying to do. We've had a
discussion previously about using hex values to simplify code. As I
recall, you were against it because you were concerned that it would
complicate the GTFS spec for the non-technical. However, as long as
GTFS is only ever used as a text-based (and not binary) exchange, the
values could just as easily be parsed as hex values or decimal. An
application could therefore simply say something like (where
route_code could be provided from a GTFS or TPEG source):

if( route_code & 0x000F == 0x0002 ) {
// treat as some sort of rail
}

or

base_route_code = route_code & 0x000F;

...okay, so there are currently a few flaws with this idea (eg
Miscellaneous = 10). This is why I think that it's necessary for the
folks behind TPEG, GTFS, TransXChange etc to put their heads together
and agree on some well thought-out values, terminology, exchange
formats/data model etc. I'm sure that TPEG provides an indication of
which version of the protocol is being used (something GTFS could do
with also), so before TPEG applications become too widely deployed I
think it would be good for them to consider an overhaul.

Joe Hughes

unread,
Mar 5, 2008, 3:01:49 PM3/5/08
to gtfs-c...@googlegroups.com
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 at
http://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

Joe Hughes

unread,
Mar 19, 2008, 11:42:39 AM3/19/08
to Google Transit Feed Spec Changes
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
> > 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

Jacques chez stibus

unread,
Mar 20, 2008, 5:44:13 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

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:

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

-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]

On Behalf Of Jacques chez stibus
Sent: 20 March 2008 09:45
To: Google Transit Feed Spec Changes

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.

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.

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.


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

 

Maria Smith

unread,
Dec 5, 2017, 12:11:58 PM12/5/17
to General Transit Feed Spec Changes
Do you know where this proposal sits at this time?  I see the reference guide still has the original 0-7 options for route_type.  I'd like to be able to use one of the others you proposed or maybe propose another one.  Morgantown, WV has the Personal Rapid Transit.  An above ground rail, electric car, on demand system.  I don't believe any others are used for public transit and last I read the only other one is in Disney FL.  Here's info on the PRT - https://transportation.wvu.edu/prt 

**I don't post in these forums much, if I need to post the question elsewhere please let me know.

Leonard Ehrenfried

unread,
Dec 1, 2022, 6:11:11 PM12/1/22
to GTFS Changes
Hello all,

Happy 10th birthday, dear route_type thread!

I'm about to add a carpool mode to OpenTripPlanner and whilst choosing a route type to map we discussed what an appropriate number would be.

It became clear that we actually need something like that in the standard.

Even though we haven't been able to come to a conclusion in the last ten years I was wondering if there is appetite in the community to have another go at this, particularly since the TPEG extended types are in quite widespread use these days.

If there is interest in the community, I'm happy to take the lead.

Many thanks.
Leonard Ehrenfried
Reply all
Reply to author
Forward
0 new messages