Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhance definitions for cable tram and aerial lift #186

Merged
merged 1 commit into from
Dec 26, 2019

Conversation

aababilov
Copy link
Contributor

Term "cable car" is used in different sense in various countries. We also want to avoid misinterpretation of the word "gondola".

US: "cable car" has cable below the vehicle and runs on rails. That is called "cable tram" outside US. Example: cable car in San Francisco.

UK: "cable car" has cable above the vehicle and uses it for support and propulsion; it has no rails. That is called "aerial lift" in US. Example: Singapore Cable Car.

Main subtypes of aerial lift are:
a) aerial tramway - usually larger; one or two stationary ropes for support while a third moving rope provides propulsion. Examples: Roosevelt Island Tramway (New York) and Portland Aerial Tram
b) gondola lift - usually smaller; supported and propelled by cables from above. Examples: Singapore Cable Car, Telefèric de Montjuïc.

Gondola lift is not related to gondolas in Venice.

Term "cable car" is used in different sense in various countries. We also want to avoid misinterpretation of the word "gondola".

US: "cable car" has cable below the vehicle and runs on rails. That is called "cable tram" outside US. Example: cable car in San Francisco.

UK: "cable car" has cable above the vehicle and uses it for support and propulsion; it has no rails. That is called "aerial lift" in US. Example: Singapore Cable Car.

Main subtypes of aerial lift are:
  a) aerial tramway - usually larger; one or two stationary ropes for support while a third moving rope provides propulsion. Examples: Roosevelt Island Tramway (New York) and Portland Aerial Tram
  b) gondola lift - usually smaller; supported and propelled by cables from above. Examples: Singapore Cable Car, Telefèric de Montjuïc.

Gondola lift is not related to gondolas in Venice.
@abyrd
Copy link

abyrd commented Aug 16, 2019

Nice, I like the emphasis on general description of modes as categories, rather than associating each code with one specific name.

@flocsy
Copy link
Contributor

flocsy commented Aug 16, 2019

To avoid confusion because in different countries the same word is used for different things we should add to the standard a sentence about this. Something like:

When defining the route_type the definition in the standard is to be used even if it's contradicting the local language. I.e: in Venice, Italy the small boats that they call gondola should not be set as route_type:gondola but ferry. The route_type is not to be used as branding.

Also to minimize confusions like this, maybe we should change the names of the existing route_types (keeping the same id, and same definition, just change the name):

0 | Tram, Light Rail, Streetcar
1 | Subway, Metro, Underground
2 | Rail
3 | Bus
4 | Ferry, Boat

But I have hard time to clarify the last 3:

5 | Cable Car
6 | Gondola, Suspended cable car
7 | Funicular

To my understanding Funicular is an unpowered vehicle that is pulled on a cable, but then why not uniting it with cable car?

Isn't the SF cable car "similar enough" to tram to set it's route_type to tram?

But again, since it's not clear why we need/have route_type it's hard to be more specific. Unless we specify this in the standard we'll always have never-ending discussions.

If the goal is to have some kind of hint for the clients, then the standard should specify exactly what those hints are.

For example if we think route type is to define the default icons an app is using when there's not specific icon from the agency, then we should add this to the standard, including example icons. But if that is the case, then we won't be able to avoid adding more and more route_types, because in every city where there's something distinctive the local providers will request a way to differentiate. For example in a place where they have both buses and trolleybuses, they'll request a new default icon with the "antenna" over the bus.

Or the same goes for San Francisco: if there needs to be a different default logo for streetcars/trams and the SF Cablecar, then we need both. If not, then I would say SF Cablecar is maybe a tram as well.

@abyrd
Copy link

abyrd commented Aug 16, 2019

When defining the route_type the definition in the standard is to be used even if it's contradicting the local language. I.e: in Venice, Italy the small boats that they call gondola should not be set as route_type:gondola but ferry. The route_type is not to be used as branding.

I fully agree on adding this language. It's a good example. The route_types are about conceptual categories, never about the specific words used to demonstrate those categories.

Also to minimize confusions like this, maybe we should change the names of the existing route_types (keeping the same id, and same definition, just change the name):

I think we should consider the route_types to "not have names" in the sense that no one word is the "official name" of that category. Each one should just be a description, with various words that are used in different places within that category.

Anyway, I'm in favor of adding words like Underground and Boat to the lists as you've suggested.

But I have hard time to clarify the last 3:

5 | Cable Car
6 | Gondola, Suspended cable car
7 | Funicular

To my understanding Funicular is an unpowered vehicle that is pulled on a cable, but then why not uniting it with cable car?

As I said elsewhere, I do not think we gain anything by avoiding human "mental clustering" of the modes and insisting on categorizing them only by abstract descriptions of their traction and guideway technology.

It would be possible to unify them, but it would run counter to public perception of these as two non-overlapping categories. While SF cable cars run like trams in the streets, in my experience funiculars operate in areas too steep to have streets, and you wait for one of a matched pair of cars often in a fixed indoor station. Even as someone who pays attention to details of public transit, I don't think I've ever mentally grouped a San Francisco cable car with the Funiculars in Lyon for example.

I think the strongest argument here is that San Francisco cable cars may be the only system in the world that would actually fall in category 5. I suspect the existence of category 5 has to do with GTFS's origins on the US west coast, and the general visibility of San Francisco among that technology crowd. All other modern cable cars would probably be perceived as people movers and the traction technology unknown to the riders. So category 5 is attributable to a kind of US west coast bias, a mostly harmless one that's baked into the spec from the beginning, and should probably be ignored when thinking about the categorization system. Another perspective: those cable cars are mostly used for tourism so perhaps the real category is a "tourist railway", to be grouped with things like https://www.openstreetmap.org/way/37497491 (which once caused some amusing routing confusion by being located directly on top of an underground rail station).

As for the gondola category, I have no doubt it is distinct from the other two. I can't imagine representing a ski-lift like thing with an icon that looks like a tram or a funicular going up a slope.

For example if we think route type is to define the default icons an app is using when there's not specific icon from the agency, then we should add this to the standard, including example icons. But if that is the case, then we won't be able to avoid adding more and more route_types, because in every city where there's something distinctive the local providers will request a way to differentiate.

Sure, we definitely need some guidelines for when to stop splitting categories. It can't go on forever. But I fail to see how not specifying default icons would lead to a proliferation of route_types. Again, if agencies want really specific icons, colors, etc. for their modes, that will fall under a branding extension.

Contrary to such a branding extension, route_type should be semantic and not prescriptively force GTFS consumers to display things in a certain way. It is the common denominator fallback, clustering routes into commonly used mental categories of modes, for any purpose the GTFS consumer sees fit. This includes differentiating icons, but also debugging purposes, heuristics for evaluating data validity, inferring access time and elevation, allowing the filtering of results by mode etc.

@flocsy
Copy link
Contributor

flocsy commented Aug 16, 2019

I think we should consider the route_types to "not have names" in the sense that no one word is the "official name" of that category. Each one should just be a description, with various words that are used in different places within that category.

Ah, this is the phrase I was looking for "no names". I think this is a good way to define it, but the problem is demonstrated with your next sentence:

Anyway, I'm in favor of adding words like Underground and Boat to the lists as you've suggested.

No matter what word we would use, there always be a place in the world where that word is used, and in many occasions we'd also find a place where it's used in a contradicting way. (Not to talk about the fact that in many places these vehicles go under, then come up, then go under again...)

While SF cable cars run like trams in the streets, in my experience funiculars operate in areas too steep to have streets, and you wait for one of a matched pair of cars often in a fixed indoor station. Even as someone who pays attention to details of public transit, I don't think I've ever mentally grouped a San Francisco cable car with the Funiculars in Lyon for example.

I tend to agree, but shouldn't we have these guidelines of how to decide which route type a producer should use in the standard?

I agree with the US bias and I would say it's OK to have route_type 5 only for SF, if there wasn't route_type 6 "Suspended cable car".

As for the gondola category, I have no doubt it is distinct from the other two. I can't imagine representing a ski-lift like thing with an icon that looks like a tram or a funicular going up a slope.

agree.

Sure, we definitely need some guidelines for when to stop splitting categories. It can't go on forever. But I fail to see how not specifying default icons would lead to a proliferation of route_types.

I keep on asking the same question again and again: why do we need route types? If one of the goals is to provide a default/fallback icon to be used, then we should have an example in the standard. This is like fonts: we all know and agree how an "A" looks, and I'll be able to read your website even if you designed your own font.

I'm pretty much sure that nobody would have a problem understanding what's the difference between a train and a bus and also recognize them seeing an icon. But as we add more and more types it becomes a problem. See for example: trolley bus. I would guess it's icon would look like a bus, but with the "antennas" on the top. But it also adds confusion as in the US trolley or trolleycar is used for something I would call a tram.

The same can be said for monorail.

What's the difference between the look / icon of a metro and a train? Not in a specific city, where you add color and maybe even the shape can remind locals.

How would one see the difference between tram or rail icon and cogway icon? (without the color branding for example)

Not to talk about the cable-car vs tram problem (well, you can use the SF cablecar icon :)

Contrary to such a branding extension, route_type should be semantic and not prescriptively force GTFS consumers to display things in a certain way. It is the common denominator fallback, clustering routes into commonly used mental categories of modes, for any purpose the GTFS consumer sees fit.

All this is branding / l18n specific. The mental category of people in the US and UK is different when they hear "cable car". This is the reason that I think if we need route_types at all, then we should define them in a way that any reader will understand it the same way.

I am also less focusing on what a consumer would need to do, and more on the producers: we need to have a clear meaning to the types so that when you send anyone who is familiar with the types to any place in the world he'll have no doubt what type each route there should be and everyone else will agree with him. If we have a mess in the data (confused producers), then consumers will be confused as well. If we achieved this, then I don't mind adding a few more types.

We also have a specific problem here: producers are local, but most consumers are global. It might be logical to split A and B in the local level (and I think it should be done but with "branding") but it might be confusing for the global consumers. (Maybe route types should look more like a tree and not a list and producers should define the fallbacks: trolleybus->bus, streetcar->tram, monorail->rail, but in another continent they would have a datasource with: streetcar->bus. This way we'd have a clear fallback in case a consumer is not ready yet for a new added type. And we'd also have more flexibility to add new types. Though we still should agree on the 1st level where everything else will fall back to :)

This includes differentiating icons, but also debugging purposes, heuristics for evaluating data validity, inferring access time and elevation, allowing the filtering of results by mode etc.

In my experience this is very much location specific. For example in Sydney the rail and metro counts as one type (at least for fare calculation). Good icons are location specific (not only the color. but also the shape can be different in two cities although nobody will have a doubt that the route is a metro/subway/underground) Data validity: see my idea about having a tree, that would be easy to validate and consume. I mean it's more difficult to implement at the 1st time, but then you're not prone to errors when new types come into existence. Elevation is a problem even if we only talk about 1 city: Budapest: M1: 120 years old, just below street level (-5m). Well, in one end of it it actually comes out and is on the ground. M2: -10m to -50 or even more, but it also comes out to 0 on one end. M3: -5 to - whatever.... Filtering: location specific (or even user specific if we take accesibility into account)... the list is never ending, I know every problem you mentioned, but most problems are also consumer specific.

@aababilov
Copy link
Contributor Author

aababilov commented Aug 19, 2019

Isn't the SF cable car "similar enough" to tram to set it's route_type to tram?

It is a tram already. Its non-US name is "cable tram". There were several generations of trams: horse-drawn, steam, cable-hauled, gas and electric. We have this route_type in GTFS for historical reasons. It was initially supported by Google which has its headquarters in the San Francisco Bay Area.

@aababilov
Copy link
Contributor Author

aababilov commented Aug 19, 2019

For example in Sydney the rail and metro counts as one type (at least for fare calculation).

Hi from Sydney! Trains and Sydney Metro are perceived as different route types here. Local maps have different colours and logos: orange T (train), teal M (metro), red L (light rail), blue B (bus), green F (ferry).

@aababilov
Copy link
Contributor Author

@flocsy @abyrd @LeoFrachet

What is your opinion on my pull request? Would you like to update route type definitions in the proposed way?

@abyrd
Copy link

abyrd commented Aug 19, 2019

@aababilov as implied in my first comment, I am +1 on your proposed changes.

@flocsy
Copy link
Contributor

flocsy commented Aug 21, 2019

+0.5 It's better than what it was, but still not really clear. If we start to differentiate traction and engine types we'll have a problem soon in other types as well.

@aababilov
Copy link
Contributor Author

I am opening the vote.

The vote will be open until Tuesday, 24 December at 23:59:59 UTC.
Gavriel (@flocsy ), Andrew (@abyrd ), Leo (@LeoFrachet ): don’t hesitate to vote if you want to.

@skinkie
Copy link
Contributor

skinkie commented Dec 17, 2019

+1 Bliksem Labs / OpenGeo

@flocsy
Copy link
Contributor

flocsy commented Dec 19, 2019

+1

@prhod
Copy link

prhod commented Dec 20, 2019

+1 (Kisio)

@laurentg
Copy link

+1

@aababilov
Copy link
Contributor Author

Vote closed. It passed by four +1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants