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

[Neil Taylor]

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]

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]

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:

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

品川駅（東京）
ＪＲ東海道・山陽新幹線 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]

+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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

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]

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]

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]

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]

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]

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]

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]

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]

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]

+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]

I mean OBA!

Best regards

[John]

+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]

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]

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]

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]

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]

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]

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