From OpenStreetMap Wiki
Jump to navigation Jump to search

Parallel tracks

How would one construct the relation for a route that has parallel tracks part of the way? --T99 00:47, 8 January 2012 (UTC)

There is the same problems with this issue as there is with long dual carriage highways (like in the US f.ex): Interstate_Highways_Relations#Directionality. In the few cases where there is a quadruple line (two rails in each direction) there is a similar problem. I suggest we make one relation for each direction (and one for each the 'extra' (or outer) track in quads) and make super-relations to link them all --Gorm 22:31, 22 February 2012 (UTC)

route=railway vs. route=tracks

Can somebody please explain the difference between these two?--Shlomo (talk) 08:08, 30 May 2018 (UTC)

This offers "definitive" documentation: a "Railway Line" (route=tracks) is defined as "the physical railroad on which trains operate" whereas a "Railway Route" (route=railway) is defined as "the route of operation of trains over a Railway Line." If you are in Germany/Europe, you might better decipher what is meant by this, as it seems to be a method by which more specificity can be stored in OSM data elements (these relation types) for differences between "physical infrastructure" (tracks) and "train movements over tracks" (railway). Personally, I find this distinction confusing (and unnecessary) and see little difference or reason to use two sets of relations to do this. I was an early adopter of simply omitting route=tracks relations in the USA, which became a popular trend and is now "how we do it here." So, important: in North America, we completely omit route=tracks relations, "skipping directly to" route=railway relations (as what we in the USA call "Named Subdivisions"), seemingly with no ill effect. (We conflate these two relation types into one). Please also see this, where a couple of tables show this "conflation in the USA" concept. In short, if you are in North America, you may completely omit collecting rail elements into route=tracks relations, "skipping directly" to placing them into route=railway relations, which also usually have a name=* tag with a value like "XYZ Subdivision" or "ABC Industrial Spur." Stevea (talk) 14:40, 30 May 2018 (UTC)
Thanks, but that article does not seem to explain the difference. The 2 relations' descriptions only differ in the words 'line' vs. 'route'. So if the route=railway is for the "route of operation of trains over a Railway Line (train movements over tracks)" then the relation seems redundant with route=train, which is from the newer Public transport schemas. So is route=railway just the older schema for the same thing (a train route) and should be gradually replaced with type=train? There is only the difference that route=railway should not contain train stops/halts/stations (strangely the often do in OSM data, which is against both wiki pages) but type=train should. But a mapped route without stops is basically useless as train main not stop at all stops and there may be multiple train routes over the same railway line, which differ in the stops they stop at. type=train relations model all this and route=railway can't. Aceman444 (talk) 21:54, 21 March 2019 (UTC)
You are welcome. However, your use of terminology seems to indicate there may still be confusion on your part, especially as you ask your question. It is true (and we do it this way in the USA) that it makes logical sense to conflate route=tracks with route=railway, the latter "winning," thus making the former superfluous. But a route=train is something else altogether: passenger service UPON a particular set of railway=rail elements. (These elements usually — some say correctly — make up a route=railway relation). Think of "tracks" as the lowest level in a hierarchy and "railway" as a low-middle or middle level. Now, "conflate away" tracks as superfluous and keep the low-middle level of route=railway. (For freight rail, that's all you need). Continuing, think of a passenger rail route (a relation tagged route=train) at a high-level in the hierarchy, which is "supported by" the low-middle of route=railway relations. Again, tracks have conveniently disappeared, so we conflate the three to two: high-level trains "supported by" low-middle level railways. You use the phrase "type=train" which doesn't exist, so to reiterate, especially if you're in the USA, the two relation flavors to use are route=railway (containing contiguous railway=rail elements) and route=train (ONLY for passenger rail) which adhere to either the public_transport:version=1 or public_transport:version=2 scheme (though please try to use v2 by now). I know, it's confusing! Please don't "replace" route=railway with anything as it isn't an older scheme, it's what we use in the USA to denote what are largely called "Named Subdivisions" (contiguous elements of railway=rail in a relation). There are no stops, platforms or anything else (nor roles on elements) in a route=railway relation, simply elements of rail which when you click the "Sort" button in JOSM's relation editor, for example, they'll all line up perfectly. THEN, there are route=train relations, which ONLY denote passenger trains: THESE are the relations that contain stops, stations, platforms and those roles on the elements AND rail elements upon which the passenger train travels. I hope this helps, though if not, keep asking questions! Stevea (talk) 22:25, 21 March 2019 (UTC)
It looks like we crossed each other in editing as you added a bit to your original post. When you say "a mapped route without stops is basically useless" that isn't really true. That is what we know in the USA as a Named Subdivision (use the name=*, operator=* and perhaps owner=* tags in the relation, the owner tag if it differs from the operator). These are truly useful as they can support freight or passenger service and "this one + that one" can be linked together into what might be the traversal a freight car takes, a passenger train route (expressed as a route=train relation, with platforms, etc.) or even super-relations as what OSM calls in the USA "Major Mainline Rail," entities like Crescent Corridor, Mid-America Corridor, Southern Transcon and Northern Transcon: multiple route=railway relations linked into continent-spanning contiguous rail. Another way to think about it is that there is necessarily "underlying infrastructure" (simply contiguous rail, in a route=railway relation) which freight rail OR passenger rail could use, then there is OPTIONALLY passenger rail UPON that infrastructure (in a route=train relation). I mean, think about it: not all rail supports passenger rail. Freight simply travels upon route=railways, passengers travel upon routes expressed by route=train relations, which is only a subset of the entire rail network expressed by route=railway relations. If you followed all that, you've got it! Stevea (talk) 22:33, 21 March 2019 (UTC)
Thanks. I'm not editing in the USA, so I will not mess with the system there. I ask more for the European system. I can understand the meaning of route=tracks and route=train relations (PTv2). But I still do not see the meaning of that route=railway middle level. What does it represent in reality? Does it just say "some regular trains run from City A to City B over these tracks"? The specific routes with stops then mapped with separate route=train relations. Thus some unused segments of tracks being only in route=tracks relation, but no route=railway relations. Also, if there is the route=railway middle level, and there are various variants and alternating routes of trains in the network, how granular should those route=railway relations be? Should there be only ever a single route=railway on any track (and also a single route=track), and multiple route=train? Thus route=railway would realistically only span from one track intersection (branching) to the next. Or can there be multiple route=railway relations on a single track (railway=* way). Then how would those be determined? Aceman444 (talk) 23:14, 21 March 2019 (UTC)
Right, I see you map in Slovakia. (I once took a train from Vienna to Budapest and stopped in Bratislava, my German is non-existent and my Hungarian is elementary at best, I stumble a lot in Polish, so thank you for your fine English). Yes, "starting from the top of a hierarchy" (and working down), route=train (PTv2) are passenger routes, they are never simply "a route a freight train might take." For freight trains, the middle-level routes are what in the European/German method necessitate route=railway (and route=tracks, I suppose, though I still find this confusing and unnecessary). Yes, I know that there are specific tags one might add to specify freight rail (for example, railway:traffic_mode=freight, values of "passenger" and "both" are OK, too). But I believe it may be helpful to think of middle-level relation(s) as "what route would a freight train take?" Recall, route=train are only for passenger trains, as only those need the highly-specific detail of those sorts of relations (especially with PTv2) containing stop_positions, platforms and directionality tied together with a route_master super-relation. Perhaps this "different way of thinking about it" is (I believe) because in Europe, MOST trains are passenger trains (and so freight trains are not thought of as such by many people), whereas in the USA, MOST rail is freight, with the long-distance portions of what is transcontinental freight rail as somewhat repurposed into our (wheezing, old, slow) Amtrak (national passenger rail) system. In cities, urban and suburban rail do get better in the USA, those are sometimes "mixed" (passenger and freight, especially suburban) but are more often becoming passenger-only systems (especially urban / light-rail and tram systems). The USA has a long way to go to catch up to Europe in passenger rail, we likely never will given the vast distances between cities here. But it gets better in cities. You are correct when you say (I paraphrase you) "a given track (railway=rail) element should belong to exactly one route=railway relation." (Although, in Europe, it may be more correct to say route=tracks rather than route=railway). THEN, there are passenger routes (route=train) which can also use those track elements. Think of "all the rail owned by my country's national rail" as a set (or you could choose "a particular rail company"). Break those up into "rail lines" (what the USA calls Subdivisions). Each "rail line" is a unique segment of that national (or corporate) rail network and there is no overlap: all the "lines" added together equal "that set." However, now you have another thing called "passenger rail" and this is different from freight (sort of "raw" rail, no need for all the platforms and such), so passenger rail might be made up of "a piece of this rail, a piece of that rail, and a bit more of those rail over there." You might have different passenger routes which re-use elements of rail (that's OK), but the route=railway relations should only contain rail elements "once." Briefly stated: any given rail segment should be in exactly one route=railway relation, but it might be in anywhere from zero to a number of route=train relations, if there is one or more passenger train(s) which travels over that track. There should not be multiple route=railway relations which contain the same element of track. "The way that a route=railway is determined" is up to the national rail authority or rail corporation which owns it to "organize" all of their rail into "lines." (Infrastructure in this sense, not a "line" as in "passenger line"). From these "basic lines" (could be freight running on them, could be passenger trains) are built route=train relations for passengers, but the route=railway relations are (usually, I believe) left "as they are" for freight trains. (Here is where you might get more specific with railway:traffic_mode=*). Again, I hope this helps, I'm doing my best to take a European perspective to help you understand. Ultimately, you may need to speak with someone who knows OSM conventions of rail in Europe to help you best enter all THREE relation types: it seems you understand (low-level) tracks and (high-level) train, it is that middle-level of railway that is vexing you. I recommend Nakaner, an author of OpenRailwayMap; tell him User:stevea sent you! Stevea (talk) 00:55, 22 March 2019 (UTC)

The decision not to use both route=tracks and route=railway was a good one, because the discussion above does not show any clear difference in the meaning of the tags. But I am also skeptical of using a relation for tracks at all. If a set of connected railway=* ways has the same name=* and operator=*, database users are free to process these ways into a single linestring, automatically. There is no need for mappers to spend lots of time maintaining relations. By analogy, roads are not mapped with relations: we just add the name=* and ref=* to each way. --Jeisenbe (talk) 13:25, 11 January 2020 (UTC)

I'm curious where you are going with this, Jeisenbe. While it is true that "database users are free to process these ways (which are connected and have the same name and operator)," I shudder to imagine OSM without the quite sensibly "organized together data structures" of route=railways (as I know them in the USA). Since our TIGER import of 2007-8 which brought in hundreds of thousands of km of rail here, it has been (and is) an effort to better characterize our rail into these relations, which requires individually selecting, naming, adding usage tags to and collecting into relations a vast number of railway=rail elements. (In the case of TIGER rail in the USA, these did not have the same name and operator to begin with, and/or these data were blurred or unentered to begin with). However, once this better tagging/naming/organizing is done, the "work" to make better sense of rail (e.g. making PTv2 route=train or route=light_rail or route=tram relations) is much easier. In other words, the "effort" to create (and over time, as an easier effort, maintain) these relations is worth it as it "pays dividends." Rail companies organize their lines the same way (they and we in OSM call them "named Subdivisions") and in general, I believe most agree that this sort of organization (into route=railway relations) makes sense. I also agree that abandoning route=tracks — rather conflating it into — route=railway was and is sensible, but I can't imagine eliminating route=railway, too. It is far too convenient a data structure in how OSM "does" rail. Stevea (talk) 14:03, 11 January 2020 (UTC)

The only benefit mentioned is that it is then easier to make route=train relations. However, I would recommend just making the route=train relations alone (since these are real things separate from the tracks, they are the service pattern of a train which you can ride) and of course also adding the name and ref for each railway=* way. Do you know of any use cases for the route=railway or route=tracks relations? --Jeisenbe (talk) 15:13, 11 January 2020 (UTC)
I'm not sure what you mean by "use case," so I ask you to define that, please. It is true that rail companies organize their rail into these, hence the essential equivalency between what OSM defines as a route=railway and a rail company calls "subdivision" or "industrial line." I'm not sure if that's a "use case," but it is something, which isn't nothing. Stevea (talk) 15:36, 11 January 2020 (UTC)
I'm not deeply familiar with writing use cases, though I believe if I say "I want to capture in OSM all of the (unstructured, poorly named) rail infrastructure in the United States (entered by the 2007-8 TIGER import) as their owning rail companies (e.g. Union Pacific, BNSF, Norfolk Southern...and likely hundreds of smaller ones) name them" that might qualify as a use case. To solve / perfect it, we'd use route=railway relations. I know that's USA-centric, but that's what I'm familiar with. Stevea (talk) 18:23, 11 January 2020 (UTC)
It seems I'm talking to myself here (momentarily?), having this conversation with anybody/nobody/the community (and maybe Joseph in particular, should he answer again). I see Joseph's point, that all (rail, train) relations at all "levels" besides route=train might reasonably vanish, IF (the big if) all rail had proper name=* tags. (And as an aside, rail in USA does not have proper name=* tags, though our effort to better name them often includes placing them into the as-documented route=railway but not route=tracks relations). Yes, rail company subdivisions could be captured simply with name=* (and probably operator=*, owner=*) tags. So, another benefit of route=railway relations (besides further facilitating route=train relations) was to capture how rail companies name and organize their rail for both freight and passenger services, even as passenger services are more specifically captured with another kind of relation. This hints at but leaves unanswered "Are route=railway relations designed to explain the routing of freight rail?" The answer is "partly," as we know the rail elements in these route=railway relations must be used, but the exact route specified in the relation may or may not (likely not) precisely describe the movements on the rail for freight operation (these movements are very likely much more complex than simply the "A to B" which a route=railway relation expresses, anyway). Similar to how Interstate Highways are included in their own relations as a monolithic "thing," neither do we for those specify each and every movement that might take place on that highway, we simply use the relation to "bind" its identity as a single object. Stevea (talk) 19:15, 11 January 2020 (UTC)

I have waited about a week for Jeisenbe to reply here, and I have contacted him off-list (via email) about this as well, both with no reply. (I reiterate my perspective on OSM rail here, especially these topics, is USA-centric). I will summarize (and close?) this discussion by repeating that his recommendation to "just" making the the route=train relations alone, and not making route=railway relations is this: in the USA, we have hundreds of thousands of miles of poorly-named rail from our TIGER import and the route=railway relation (and wiki documentation and inter-Contributor collaboration, such as this) has evolved such that it is this very route=railway relation itself which furthers the better naming and organization of rail here. His "If a set of connected railway=* ways has the same name=*..." is indeed a "very big if" as that antecedent / proposition is far, far from being completed here: that precisely IS the work of TIGER Review now going on (and has for 12 years) in the USA. When that work is completed (2045, by some estimates) then he (or anybody using OSM's database from a coding perspective) finally will be able to effectively assert "database users are free to process these ways into a single linestring, automatically." But I don't believe that can be done (very effectively) today because of the poor tagging extant on much of the rail (half or so?) the USA has in OSM now. We'll get there, but not without the work of first establishing those better, matching, accurate name=* (and usage=*, they are helpful, too) tags. The small cost (in data storage) of a route=railway relation (and maybe some wiki that well-links this as a convenient handle and specifies its status as completed or not) is well worth the effort to get there, in my opinion. Yes, perhaps after that milestone, route=railway relations "fall away as effectively useless" but we cannot make that case today. But on our path to getting there, route=railway relations are quite useful. Oh, and once again, route=railway relations also directly equate to what rail companies (and municipalities) call these collections of rail elements, as "named subdivisions" or specific (named) "industrial lines." That alone seems a good reason to keep them as an aggregated relation (collection of elements bound together), if nothing else. Stevea (talk) 21:56, 17 January 2020 (UTC)