Talk:Tag:route=railway

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)

Name tag

Hello, why do we use name tag as duplicity for other tags?

name = [operator] [ref] [from] [to]

And when there is an actual name of the railway, where to put this?

Filip009 14.12.2022 7:30 UTC

Hello, Filip009, thanks for your question. It is a bit sparse and lacking in detail, so I must guess a bit. Are you talking about how in the USA, frequently you'll find on a segment of railway=rail an additional name tag of, for example name=Union Pacific Railroad or name=Norfolk Southern? If so, the reason is because of the way that the USA's 2007-8 TIGER (data) import (from the US government's Census Bureau) imported naming conventions like this. The correct and more-modern way to tag such rail segments (in the USA, or likely anywhere) is to put these values (the ones that are "the name of the railway") into either an owner=* or operator=* tag, depending on whether that railway (company) is the "owner" or the "operator" of the railway. There are frequently "track sharing agreements," so that the rail owned by Union Pacific Railroad (for example, which should be tagged owner=Union Pacific Railroad on the the railway=rail way) might also have, say, an operator=BNSF tag on it. Click on those tags to read the wiki about them. The name=* tag on a railway=rail way should be "the name of the line."

To quote our Railways wiki, "Where a line has a recognised name this can be included in name=*. Sometimes this is entered as the name of the operator=* or owner=*, but if they are known, please use these tags, reserving name=* for the actual name of the line." If you ARE asking about USA rail, see United States/Railroads for specifics, as there are conventions for what USA rail companies do, including naming their "Subdivisions" (and so on) and how we tag the various usage=*s of rail in the USA.

If you are asking about rail outside of the USA, please specify that, and I or others here might direct you to a specific wiki page that might have specific rail conventions in that country or region. (That's why I said "likely" back there: it's likely correct, but there really are "global" approaches to enter rail into OSM (and how to properly assign its name=* tag) and there are sometimes "country- (or region-) specific" methods to do this. Stevea (talk) 08:59, 14 December 2022 (UTC)

I'm asking because of "name" tag example on this wiki site. In the example tag consist of [operator] [ref] [from] [to], which in my opinion is duplicity. I think we need to change example on this site with some relation, which has good name. Is it now clear, what I'm looking for? :)

Filip009 14.12.2022 14:13 UTC

I am sorry, no, it is not clear. We may be having a language problem: you use the word "duplicity" which in English means "deceitful" (lying, misrepresenting the truth). Usually wiki articles don't (obviously, intentionally) lie or purposefully not tell the truth. Also, I don't see any examples in the article at all. What example do you refer to? The table with operator, ref, from, to is not an example, it is a grouping of tags applied to a relation, some of which are mandatory, some of which are recommended, some of which are optional. I don't know if it is a "good" example, but, try this, which is the "Coast Subdivision" route=railway near me in California (USA). You can see that the relation has name=*, operator=* and usage=* tags. Please ask again if this is still not clear. Stevea (talk) 14:37, 14 December 2022 (UTC)

Sorry for my english. I think word "duplicate" is that word I was looking for. :D

On english site. In part Tagging. In fourth column. There is an example of name tag. And in my opnion it is not good example because it is just a copy of another tags. Not real name of railway.

Filip009 14.12.2022 20:40 UTC

OK, I see where you specify (..."in fourth column's name tag"). Your opinion of it not being a good example seems (to me) to be a misunderstanding on your part: the table's name=* key entry really is a good example of "the name of the track" (exactly what is specified). Your opinion of it (partially) containing "copy of another tags" is specious (means "appears to be correct, but is actually wrong"). The reason for this is that, as you can see, the name=* key on the rail segment is mandatory, whereas for the various "pieces" of this example name tag where you believe it is "just a copy of another tags," these "other tags" (ref=*, from=*, to=*) are not mandatory. This makes the name=* key the "authoritative" or "definitive" key which effectively defines what this rail segment "really is" (named). Does that make sense? Stevea (talk) 23:49, 14 December 2022 (UTC)

You are correct. This is Tagging For editing software and renderer. It is counterproductive to applications seeking a proper name. Discussed on Talk:Buses#Bus_Route_Naming etc, with the prime example of a geocoder (Nominatm) ignoring name=* on type=route because of this. https://www.mail-archive.com/tagging@openstreetmap.org/msg51508.html
As mentioned there, iD has added support for more tags in generating labels, to avoid these artificially synthesized composite "name" as annotations.
Other discussions:

• https://lists.openstreetmap.org/pipermail/tagging/2022-February/064020.html
• https://www.mail-archive.com/tagging@openstreetmap.org/msg44910.html
• https://lists.openstreetmap.org/pipermail/tagging/2020-December/057736.html https://lists.openstreetmap.org/pipermail/tagging/2020-December/057745.html (with more links)

However in this example, it seems "KBS 801" is a correct proper name. Neither ref=801, *=KBS, nor *=DB alone would give it its recognizable identity. --- Kovposch (talk) 07:10, 15 December 2022 (UTC)

Let's be clear about who is correct and about what. WHAT is "tagging for editing software and renderer?" If, as the Page says, the actual name=* of the track (in the "example") truly IS "name=KBS 801 Schlüchtern - Gemünden" and it just so happens that there are "matching components" for from=* and to=* in this name=*, then I do agree this is a "poor example" and not a "good example" of a name. The reason being that it seems it encourages entering "other values" into the name tag, which I agree we shouldn't do. However, in this particular example, it may actually be that the name of the track is "name=KBS 801 Schlüchtern - Gemünden" (correctly). NOW I better understand Filip009's original confusion. And, I think I agree with him that in this table, we likely want another example name, one which does not do this sort of "repeating" of other components, as it encourages people to think that those belong in the name, when they don't necessarily belong. Thank you Filip009 for bringing this to attention with your question and thank you Kovposch for your additional clarifying links. To be clear, I don't think we want to "tag for the renderer" (with "prettified") false names, simply "dressed up" to look good for renderers (and such). Instead, the name=* key should ONLY contain the ACTUAL name of the track. Stevea (talk) 07:24, 15 December 2022 (UTC)

(Kovposch, it looks like we "crossed in editing time," thank you for your additional clarification). Stevea (talk) 07:24, 15 December 2022 (UTC)

Yes, I understand the proper name can often include an origin to destination clause. This is widespread in Germany. Only that this example can use more scrutiny, or examples without coincidences should be added. --- --- Kovposch (talk) 12:44, 15 December 2022 (UTC)

I'm in USA and think it would be best (for now, we can tweak and add later, if needed...) if someone in Germany were to both "understand all the subtle issues" and "use a better example" (or two) that would make clear that both "no origin to destination clause" name=* values are found, as well as those WITH "origin to destination clause" values. We might modify the table (or tables) to use several examples from around the world, as that is simply "the reality we have in our map" (data). Again, thanks to all for assistance; this is a bit quirky and was hard to understand (for me at first, I think Filip009 as well), so some disambiguation seems truly needed here. OSM's rail data aren't "one size fits all," neither in our wiki (we keep doing better and better here, though!) nor in people's minds as we try to understand how things might best be done, especially in my country/region (hers, yours, theirs...) to map rail. Let's fix this wiki so it's really clear. Stevea (talk) 08:09, 17 December 2022 (UTC)