Is route=light_rail incompatable with PTv2?

General talk Tagging general discussion
1

Reading through some older discussion threads on the forums, I came across a few threads stating that route=light_rail is incompatible with PTv2 because it was not in the original PTv2 proposal (in German, but the new forums makes translation easy anyway):

In addition, the German wiki page contains a notice that this tag is controversial (while the English page lacks any such notice), so seemingly a mapper would come to two different conclusions about the status of this type of route depending on whether one is looking at English or German wiki pages and discussions (as I couldn’t find anything in English on this controversy). Or perhaps the German community simply came to a different conclusion.

So should route=light_rail be used with with PTv2? Personally I think that if mappers are using it meaningfully (differentiating from tram or subway can occasionally be difficult) then it doesn’t really matter what was originally included in the proposal. But I’d like to hear what others think.

2 Likes
2

The concept of “light_rail” can be difficult, both in Germany (an extremely rich and diverse place for rail, perhaps moreso than any other place — AND the geographic origination of OSM’s OpenRailwayMap overlay-renderer) as well as in other places. For example, it is still unclear whether Berlin and Hamburg’s S-bahn are light or heavy rail. Yes: tram, subway, “metro,” the line between where “heavy rail” becomes “light rail” (and how this changes from country to country) very often blur and smear around each other, especially between different countries where it is more difficult to draw firm boundaries between these different (but related in not-easy-to-describe ways) wheeled-vehicles-on-rails. You can talk about signaling, street-running vs. not, the speed, length and capacity of cars and the system, and still get plenty of disagreement.

How all of this logically maps onto OSM’s implementations of PTv2 is yet another dimension of difficulty.

As I’m a firm believer that the concept of light_rail isn’t going away and is a necessary semantic for OSM to continue to capture the full reality of Earth’s transportation networks, both railway=light_rail (as a tag for underlying track infrastructure) and route=railway (as a tag for for collections of track infrastructure) are not going to go away as OSM tags. Nor is route=light_rail (as a tag for for the passenger relation, similar to route=train for “heavy rail” passenger trains) going away. In short, the omission of route=light_rail from PTv2 was either a regrettable oversight, or the two were found incompatible at the time (I wouldn’t understand why if that were the case) and it was deliberate. This must be fixed, either in a “patch” to PTv2, call it PTv2.1, or a newer PTv3 that incorporates even more public transport concepts.

While I understand our German wiki calls route=light_rail “controversial,” I disagree. I call the omission of route=light_rail from PTv2 a mistake that OSM must fix. True, I’m a long-time rail mapper in OSM (>10 years), but I don’t have an easy solution for this: more discussion, please. Especially among those of us (not me) who are really deep into PTv2’s definitions, implementations and use cases. We can eventually solve this, but we are only in the earlier-to-middle stages of doing so.

3 Likes
3

Was the PTv2 list of route values intended to be exhaustive? If so, it’s quite lacking. Light rail is hardly the most exotic form of rail transportation out there. As long as railway=light_rail exists and other route values exist that match railway=*, then route=light_rail should also exist. If there was a specific reason why it was intentionally omitted at the time, it doesn’t seem to have been communicated to voters, so I’m not sure how much it matters that PTv2 was approved with this omission.

I don’t think we really need a formal successor to the PTv2 schema just to acknowledge this omission. Only an unnecessarily strict reading of the proposal would consider the addition of a new route value to be backwards-incompatible. Besides, many have voiced a need to repeal PTv2’s ill-considered requirement to overload the name key with a formulaic description of the route, even though technically that would be backwards-incompatible.

5 Likes
4

Not only that, but it seems to be an increasingly popular means of transit (some of Los Angeles’s recent transit expansions come to mind)

Looking further into it, it appears that the author never intended the list to be exhaustive: Proposal talk:Public Transport/Archive 2011 - OpenStreetMap Wiki

Nonetheless there appears to have been a lot of back and forth of editing the proposal content: Proposal:Public Transport: Revision history - OpenStreetMap Wiki
(I don’t think that is supposed to happen, and is part of why we archive proposals afterwards now)

1 Like
5

Well, I’ve given up working on Public Transport in OSM and discussing
it as I don’t see any possibility to achieve something usable.

Wilhelm

6

What, why? There have been less then 24h and all 3 replies seemed positive and constructive to me?!

7

We have a tram that becomes light rail when it passes a certain point in the route it follows. More of those to come in near future. People don’t like to change cars.

8

OK, opposite to this, California’s BART (Bay Area Rapid Transit) has on its Yellow Line a great majority of “heavy rail” (subway through San Francisco and under the bay), then, if you are going to Antioch at the east end of the Yellow Line, you must change trains / cars (by walking across a platform) at Pittsburg / Bay Point station. This is where heavy rail “turns into” light rail (different tracks with different gauge, with different electrification, with different cars…), yet these two disparate heavy- and light-rail systems are actually on ONE line (Yellow) in the BART system.

In short, transit can be / is rather complicated. PTv2 (or however we do it in OSM) must accommodate these real-world complexities.

9

Sure, this is expected with light rail. In the San Francisco Bay Area, one of the light rail systems is called a “metro” because half of it runs underground as a subway and seamlessly transitions to above-ground dedicated tracks. Another is called “light rail” and mostly runs on dedicated tracks, but it has some street-running segments. (Even freight rail can have street-running segments.) I can see how the hybrid nature of light rail causes indigestion, but the PTv2 proposal did provide for route=trolleybus, even though trolleybus systems can be hybrids too.

At least in the U.S., we talk about “light rail lines” (or “light rail routes”) as a category distinct from “subway lines”, “streetcar lines”, and “railroads”, even though the infrastructure and vehicles can sometimes mix. This makes it useful to distinguish the tagging, since otherwise information is lost about the route. On the other hand, we normally refer to routes served by trolleybuses as simply “bus routes”, making route=trolleybus somewhat redundant. But maybe other regions and languages distinguish such routes, making that tag useful too.

As with anything marked as a controversy on the wiki, it would be helpful to know what exactly keeps the controversy going? Is the tag causing any problems for data consumers? Are mappers in one region even confused than everyone else about when to apply the tag – can better preset names and icons help?

One of the threads linked above links to these 2014 meeting minutes that seems pretty reasonable in translation. If one cannot base the decision between light_rail and tram on the system’s name, then it becomes necessary to decide by intuition based on a variety of characteristics, as this writeup accurately demonstrates.

10

Examples of controversy and/or confusion are San Diego’s (California, USA) light_rail system known as “the Trolley,” which use temporally-distinct freight rail lines (though, freight rail is only extant from 0200 to 0330) on its Blue and Orange tracks and the northern San Diego County’s light_rail system (known as SPRINTER) using temporally-distinct freight rail (to Escondido from the “main line” connection near Oceanside). Such (apparent) ambiguities, though they are actually able to be well-tagged in OSM, have caused tagging vacillations that are not always easy to resolve. This (mixed passenger and freight traffic) also happens on SMART and NWP rails, Napa Valley Railroad and others (in California and elsewhere).

Whether to tag underlying infrastructure railway=rail + usage=branch or railway=light_rail (and get rather fancy and specific with tags such as railway:traffic_mode=passenger/freight/mixed) is less than clear.

I’m certain there are many other similar problems.

There is nothing wrong with “tossing into OSM one’s best guess based upon intuition from various characteristics,” as the community can then wrangle the details of what tagging might be best, some tags eventually “winning.” But this does cause vacillation in tagging and rendering and even rancor about “what is actually correct.” It can be difficult to write wiki documentation that imagines all possible cases, so we go with the best we can think of — and then find we need to extend it. Clearly, it seems we must extend PTv2 to be more accommodating to light_rail and the various odd ways it fits into (or doesn’t fit into) other kinds of rail. But this varies widely across countries / jurisdictions and multiple distinguishing legalities, with varying technologies (electrification, diesel propulsion…) and naming conventions, so we have the present difficulties. OSM isn’t the only one who suffers, it seems the larger world of rail has been tussling with these issues for decades. What we need is a set of tagging standards that at least if they are not consistent (and they aren’t, at least right now), should be able to accommodate the wide realities that exist in the real world of (passenger) rail.

I will add that OpenRailwayMap and its very well-documented conventions in our wiki goes to great lengths to accommodate many kinds of rail. Yes, this originates in the rich-rail world of Germany, but these tagging conventions (to support a rail-rendering overlay layer, yes it is true) are applicable to the whole world, being as rich and well-developed as they are. There are realities in rail mapping in OSM that create realities of “well, we just have to do it like that in this country” and that’s “not terrible,” but at least we can and at least we do document such differences.

11

Sorry. It’s a misunderstanding. I’ve got an E-Mail and answered to it and I didn’t notice it would be published in this context. I did not want to refer to the “light_rail”-discussion here but just tell, that I’ve given up Public Transport in OSM after several years of intensive work in this realm.

12

It looks like that list of criteria is already at the page for railway=light_rail. Whether we need a different set of criteria for the actual route (since it is less flexible, given an entire route needs to have a single route=* value where as it can run on different types of infrastructure throughout its run, as you mention.

This is a good point and it can be a huge challenge, especially since the concept of “light rail” can be different in every place, and probably depends more on how it fits into a place’s transit hierarchy. So the same infrastructure considered to be a tram route in one place may be considered light rail in another, and I feel that we should respect that somehow. For example, some of Amsterdam’s tram lines have levels of separation which could be considered light rail (and would be tagged as route=light_rail in some places) but I think it should still be tagged as a route=tram given that all the references to it call it a tram. Although in this case perhaps the underlying infrastructure could still be tagged as railway=light_rail.

1 Like
13

That is exactly how it is mapped here! And the operator calls the whole a tram too, even though some part of the route is run under a railway concession for historical reasons. Not that it would matter much for passengers - max speed 40km/h in the light-rail sections due do bad rails and a winding route :wink:

1 Like
14

Right, how we classify a route is often informed by the infrastructure, but it isn’t always a one-for-one match. An extreme example is that long-distance hiking routes sometimes have to follow busy roads.

Perhaps we should think about it from the perspective of a system operator. For example, consider a local transit agency that numbers its tram lines and rail lines in two different namespaces (or two disjoint numeric ranges). Now consider a route that travels over a mix of railway=light_rail/tram/subway. Does the agency number it like a tram line or like a rail line? Or does it use a third namespace, in which case route=light_rail becomes necessary?

2 Likes
15

There are tracks and passenger rail services around San Francisco’s Embarcadero which are railway=tram and railway=light_rail, yet “what the passenger rail services are called” (either streetcar/tram or MUNI light_rail, a distinct “thing” in San Francisco, distinct from cable cars, historic streetcars, BART, Caltrain, and the monorail at SFO Airport which are ALSO rail in San Francisco, but Amtrak bypasses The City) varies. In some places (around Pier 1), “light_rail travels over track which might be called streetcar/tram track” (so which do we call it?) and in some places, it’s a bit more convenient in tagging (or is it?) to say that “streetcars/tram travel over light_rail track”? It’s a cluster of examples where “yes, both” is the answer.

Edit: San Francisco even additionally has route=trolleybus (electric bus, power from overhead lines). A newly-constructed Central Subway is part of MUNI. The high-speed-rail station of the future is under construction. Local transportation jurisdictions talk seriously about another passenger rail tunnel under the Bay. It is amazingly complex, OSM sometimes struggles to keep up with accurate tagging. Los Angeles is another booming rail construction zone (partly to prepare for hosting the upcoming Olympics).

Even talking about it is complicated, but I capture the gist above. If you care to look at the ways, you can, though describing them beyond “passenger railway=* around Pier 1” gets tedious.

It’s not so that particular route=light_rail relations are “seriously disharmonious” with PTv2, it’s more like a sour note among a symphony. We haven’t totally ruined anything, but the scheme could use more harmony, because of the complexity of how we “tag tracks,” and seem to “straightjacket services” into niches which aren’t really true, or are quite grey / fuzzy / flexible and which certainly wander around a great amount between jurisdictions and regions. Highly multiple-rail-service areas (like Downtown San Francisco, there are many others in dense, urban centers) especially exacerbate the breakdown along the edges of this. It’s fuzzy and can use sharpening up, but it isn’t wholly broken. “Minor ambiguities,” let’s agree, which are hard to disambiguate.

I’ll give us around a solid B, maybe B- in places, maybe B+ in other places. Some really polished areas creep into A- or even A (not A+) territory, but we need better tagging and schemes like PTv2 (or PTv2+) which improve things. Rail is really rich. We’re not done, we’re good, very good in places, we can get better.

1 Like