RE: [gtfs-changes] Re: proposal: Modify route_type to add new types and to group similar types together
Neil Taylor
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
David Turner
> 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.
>
新宿駅（東京）
ＪＲ山手線 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.
> 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
> 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
Neil Taylor
Best regards
Neil Taylor
www.itpworld.net
Brian Ferris
To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.
Stuart Heinrich
- 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.
Stuart Heinrich
Brian Ferris
David Turner
> 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.
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:
> 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
> cable.
Stuart Heinrich
Brian Ferris
David Turner
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.
Jonathan Wilson
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
David Turner
> The way I see it, we need to communicate the following information:
> "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"
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
> seems to be as much in category 3 as category 2. Maybe that means it
> could go in both?
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
> 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.
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 Fri, 2012-06-29 at 14:22 -0400, David Turner wrote:Now that I've heard back from Jonathan Wilson, I have some exact text:
> 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.
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.
David Turner
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.
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.
> 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."
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.
sense to include some examples and counterexamples.
Brian Ferris
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
David Turner
> 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.
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?
route_type which describes the general class of vehicle. If
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.
> 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
David Turner
--------------
AUV
jeepney
aircon bus
non-aircon bus
--------------
Is that right? And is "aircon bus" (or just "aircon"?) how locals refer
to the vehicles?
> 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
> 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
Neil Taylor
Here is the correct inventory of localized_vehicle_type for Metro Manila:
AUV
jeepney
aircon bus
non-aircon bus
--------------
Best regards
Neil
David Turner
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
route_type which describes the general class of vehicle. If
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).
[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
Cheers
Neil
From:David Turner <nov...@novalis.org>
To:"gtfs-c...@googlegroups.com" <gtfs-c...@googlegroups.com>
Neil Taylor
Best regards
John
Joe Hughes
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
|
|
Mike Gilligan
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:
> 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
>
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
|
|
|
|
Nicholas Albion
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
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
> Marc also suggested adding BRT in the "longer-distance bus" category,
> which sounds reasonable.
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.
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
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
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:
1202 - Intercity Rail
1203 - High-Speed Rail
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
| "Joe Hughes"
<joe.hug...@gmail.com>
Sent by: gtfs-c...@googlegroups.com |
02/28/2008 10:38 PM
|
|
Joe Hughes
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
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
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
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
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
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
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
> 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.
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
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
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
>
> > > 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:
Jacques chez stibus
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
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
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
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
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
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
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
> 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
David Turner
just started adding support to OTP, but I have a question about the
following modes:
109 Suburban Railway
402 Underground 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
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
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 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
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
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
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.
David Turner
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.
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
Aaron Antrim
--
Aaron Antrim
www.trilliumtransit.com
Portland, Oregon
To unsubscribe from this group, send email to gtfs-changes+unsubscribe@googlegroups.com.
Neil Taylor
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
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.
David Turner
> 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.
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
Maria Smith
**I don't post in these forums much, if I need to post the question elsewhere please let me know.
Leonard Ehrenfried
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.
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