Talk:OpenRailwayMap/Tagging

Help point?

Need to add a tag that is appropriate for a help point -- an intercom facility (that I've never seen anybody actually use) that exists on many London stations, especially if the station is open when unattended.

Perhaps information=help_point --Harg (talk) 22:00, 19 May 2016 (UTC)

Can you give us any example picture of that? I currently do not understand exactly what you mean. Do you mean a kind of emergency phone? Or a remote ticket shop (via video chat) like http://www.merkur.de/bilder/2016/04/13/6306453/1983741020-kundin-videowand-4lLCVom5NG.jpg? --rurseekatze (talk) 22:16, 19 May 2016 (UTC)

Here is an example [1] They are for general enquiries and to request assistance rather than specifically for emergency use. They definitely don't sell anything.

As this concerns not just railways, but all forms of public transport, I suggest you to ask for that on the wiki discussion pages of public transport topics or any public transport mailing list. Also OpenRailwayMap focusses on infrastructure for railway operation, less on the passengers view. --rurseekatze (talk) 22:48, 19 May 2016 (UTC)

Prepaid card readers?

Also need a tag that is appropriate for oyster (prepaid) and contactless (pay as you go) card readers which can either be part of a walk-through ticket gate or a free standing reader on or near platform entrances. Hint: Those not familiar with London's ticketing might want to look at [2]

I suggest barrier=ticket_gate for the walk-through ticket reader but I'm less keen to suggest amenity=card_reader. They don't really provide either comfort, convenience or pleasure (dictionary definition of amenity). Facility=card_reader would make more sense, but we don't currently have a facility tag. --Harg (talk) 22:41, 19 May 2016 (UTC)

As this concerns not just railways, but all forms of public transport, I suggest you to ask for that on the wiki discussion pages of public transport topics or any public transport mailing list. Also OpenRailwayMap focusses on infrastructure for railway operation, less on the passengers view. --rurseekatze (talk) 22:48, 19 May 2016 (UTC)

Additional tags for track

I would like to suggest one or two additional tags for track: "converted to rail trail" and maybe "proposed for rail trail". While I realize that the focus of this project is rail use, rights of way converted to trails are preserved in a way that simple abandonment or built-over does not adequately cover. At least in principle they can be converted back to rail use should sufficient need arise. In addition there are often rail artifacts preserved along trails, such as bridges, tunnels, sections of rail, signs, etc., that may be of historic interest and can be mapped with existing tags.--Agr (talk) 11:35, 6 August 2018 (UTC)

Agr, I have struggled with how to tag "railtrail" here in the USA (specifically in California, though I do map rail in other states, too). See, for example, our California/Railroads wiki on this topic, which states (in part):

"A railtrail uses a former railroad right-of-way (ROW) for equestrian, bicycle or hiking paths, preserving the ROW for possible future re-use as a railway while providing a useful service in the meantime. These are often tagged highway=cycleway or highway=footway depending on whether they prefer or allow bicycle or pedestrian traffic. It is OK to tag both railway=abandoned and highway=cycleway if it is the case that an abandoned railway became a railtrail (for bicycle use, for example). Where a (multi-use) pathway is designated for pedestrians but also allows bicycles, tag highway=footway and bicycle=yes."

While this has been working (sort of), I think OSM's plastic tagging can offer more precise semantics if we coin new values railway=rail_trail and railway=proposed_rail_trail as you define them above. I believe that the first of these implies abandonment (the second implies impending abandonment), yet both also convey the necessary additional semantics you mention, like "could (in principle) be converted back to rail use should sufficient need arise." So while I'm not actually creating a voting proposal, I'm "virtually" doing so here in this Talk page, and certainly agreeing with you, by going so far as to suggest these exact Key:Value pairs. Stevea (talk) 14:42, 6 August 2018 (UTC)

Use of route=tracks and route=railway

Why were route=tracks and route=railway suggested for OpenRailwayMap? How are these tags used?

It the railway=* ways have the same name=*, they can be processed into a linestring before rendering. Asking mappers to maintain these relations seems unnecessary. And the two different tags do not seem to have a clear, verifiable distinction. --Jeisenbe (talk) 13:28, 11 January 2020 (UTC)

Whether railway=* ways have the same name=* can be a very big "if" in some parts of the world. The "hard work" of either adding identical name=* tags to contiguous strings of railway=rail must be done, OR these are collected into route=railway relations, or usually, both (in what most would consider "well-formed OSM data structures of rail" — at least using the standards extant in 2020). But it is not always the case that contiguous railway=* ways have the same name=*. Stevea (talk) 14:52, 11 January 2020 (UTC)

Correct name and ref tags on individual ways are more easily maintained and verified than collecting them all into a big relations. These must be edited every time a way is split or deleted, increasing the risk of errors and edit conflicts.

Re: "well-formed OSM data structures of rail" - I suppose nice data structures are their own reward to some mappers. But it is better to have a use case as well as a definition which can be understood and used by mappers in many different places. --Jeisenbe (talk) 15:08, 11 January 2020 (UTC)

As you have said, road networks don't necessarily have to be in relations, either, yet in many cases (US Interstate Highways, for example), they are. I'm not sure what you mean by "use case" (so, I ask for a definition), but a US Interstate Highway is a "thing," a single cohesive whole unit which sensibly belongs in a single data structure which represents it (so, we establish this with relations). Sure, being strictly correct (perhaps even pedantic), it absolutely is possilbe to "process into a linestring" the elements of such things (on the fly), whether they are rail, road or whatever. But the work to do so must either be done at that time, or beforehand by their collection into a data structure. It isn't a nicety to do so, rather it is a way to agree upon how we aggregate / organize such data. As an aside, that saves needing to "process into a linestring" as it is already done, and in a method that is widely agreed upon for a "thing" which is accurately represented in a map (by a data structure) for something which is real in the world (like a rail subdivision or a highway). I believe what you are saying is that this organization is needless (not useful), but that gives rise to the question: why must you "process them into a linestring" if such a linestring isn't useful to you? Isn't it true that "your" linestring is effectively "our" relation? If you want a linestring of elements (which might all be named the same, or not), that is different, or "custom," nothing stops you from sidestepping existing relation structure and building it yourself out of elements. But the work of organizing (whether widely agreed upon, as in a relation, leaning upon the fact of identical naming, or some other "custom logic" as might be your linestring) has to happen somewhere. Stevea (talk) 15:33, 11 January 2020 (UTC)

Re: " a US Interstate Highway is a "thing," a single cohesive whole unit" - No it isn't. When under construction, I-5 was built as disconnected segments. I have driven on under-construction Interstates back east which are still in this condition, and they may never be connected into 2 strings of continuous ways. And at some interchanges the name and number go off in separate ways (see: downtown Los Angeles) due to arbitrary decisions made years ago. Often to go straight you have to switch to the "other" freeway (e.g. at I-5 and CA-99 near Bakersfield). These long Interstate highways are administrative fictions. The real fact is that there is a grade-separated motorway here at a certain place, and that's what we map as a set of ways with highway=motorway. --Jeisenbe (talk) 23:38, 11 January 2020 (UTC)

"But the work to do so must either be done at that time, or beforehand by their collection into a data structure" - processing ways into a long "linestring" (that is, a set of different ways collected into one line - this is a common term in GIS) is trivial for a computer. It takes milliseconds. For a mapper it can take hours. Stevea, your time is very valueable, priceless actually - there are only a few of us who are really commit to this hobby, and we ony have so many minutes a day to spend on it. Milliseconds on a server are really cheap, and writing code is cheap. That's why database users should do the work, not the mappers. --Jeisenbe (talk) 23:38, 11 January 2020 (UTC)

As I ponder how "use case" applies (or doesn't, as it not very frequently has) to OSM, I'm struck with recalling one of the important tenets of OSM: that the data we make be usable in "creative, productive or unexpected ways." Is that a good place for "use case" technology (let's call it an approach) to overlap? Maybe in the way we implement certain things that provide us handholds along the way (like tools, for example, this wiki). But I still want to see some example use cases in OSM (by User:jeisenbe, for example) before I'd feel comfortable saying I can express one for route=railway relations. Stevea (talk) 16:15, 11 January 2020 (UTC)

My impression is that all of the possible uses of this data can be achieved just with the set of ways tagged railway=* + name=* or ref=* or operator=* - so we should make sure to add and maintain that information, but not worry about the relations. There are lots of rivers missing waterway=riverbank and disconmected streams, missing culverts and bridges, and missing landuse and natural areas to be mapped instead, and probably there are still many bus routes in smaller towns and rural areas which are missing if a mapper is only interested in public transit. --Jeisenbe (talk) 23:38, 11 January 2020 (UTC)

At least to me keeping common information like name, operator, wikipedia links etc. on a single relation instead of many individual ways is much easier and less error prone. I edit mostly with JOSM, it might be differnt for users of other editors. Sure, there is a lot of other stuff that can and should be mapped, but it is neither for me nor for you to decide what mappers should edit, it is every individual mappers decision what to map. --Lyx (talk) 23:57, 11 January 2020 (UTC)

It's fine to make and maintain the relations if you like. But I hope you are also putting the name and ref on each of the ways as well? That's the standard way to map it them. --Jeisenbe (talk) 00:26, 12 January 2020 (UTC)

Yes, as a matter of good practice, I do (I often know name=*, I seldom know ref=*, at least with rail). Where I see that this (putting name=* on a rail element) is not done (by others), but name=* is a tag in a relation, it isn't always clear what the right thing to do (on the element) is, that can be a struggle and when it remains ambiguous, I will not add name=* if I'm not sure). It is appropriate to say here and now I also find the relation a highly convenient "handle" or "container" for a "monolithic unit-thing" (which are often called "rail subdivisions" around here). So thank you for saying "it's fine to make and maintain the relations." It isn't that I "like" this, more like "this is what has evolved as what we do." Although, your suggestion that it may not strictly be necessary (I'm sure wider community consensus would be required before we step too far in that direction) is, again, intriguing. Stevea (talk) 00:32, 12 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:20, 11 January 2020 (UTC)

That's railway=* ways + name=* only. No need for a relation to find out the name of a section of track --Jeisenbe (talk) 23:38, 11 January 2020 (UTC)

As I said, I believe I understand you. What we agree upon (I think mostly): we agree that route=tracks are superfluous, we agree that route=train are useful (and correct) to define passenger rail, we agree that Interstate Highways aren't monolithic while they are being constructed. (I do say these are monolithic after they are completed, do you?). We agree that there are plenty of highways and "contiguous linear structure" (such as some highways) which are not in route relations and which do a perfectly adequate job of representing these in OSM as they are in the real world. (By contrast, there are also plenty which ARE in relations, and it isn't always clear why some are and some aren't. Perhaps this is at the crux of why you might want to see "all one or all the other" and I'm not sure you do). route=railway relations, at least in the USA (where I edit these), and because of how our TIGER import slightly botched these, do seem to benefit by being collected into these, as the collection facilitates naming of the specific railway=rail ways, at least for me and other users I collaborate with. That last is very clearly — and strongly — my opinion, but I've seen others do exactly the same thing along with me (collaboration has continued for many years) and I've never had it challenged / questioned / proposed / suggested to be eliminated as you seem to be doing now. I AGREE with you that this (elimination of route=railway) is possible, as it would be for every single route=road relation that exists, too. However, call it "legacy," OSM has grown up with these route relation structures (we haven't always had route relations, but we have for most of OSM's history) and it doesn't seem like they are going to go away soon or easily, though I am in a listening mode and agree it could be done. If you are suggesting this as an early gambit in that direction, I'm fine with this and would like to see wider community participation in this thread. It is actually an intriguing idea, though I think the work to do so throws away a lot of convenience that these relations provide. For example, in the USA, route=railway relations are used which contain way members with slightly differing name suffixes, like MT1 and MT2 to denote two main tracks as these edits are buffered among multiple OSM editors as we better refine the names and "collections" of what we understand to be these "entire structures." That wouldn't be possible in your imagined scenario, as the "magic" of "processing them into a linestring" would break somewhat, or need distinctly more complex logic. Would we receive your perceived benefit of decreasing the risk of errors and edit conflicts (as we have now with relations)? Perhaps, but I believe that by "ironing out" this layer of structure (the route=railway relation) you'd reduce flexibility (as I describe the MT1/2 usage above) at the cost of placing a much greater semantic weight on "name=* is the binding force" instead of this being done with the relatively straightforward concept of relation membership. (And, as we all know, "the name is the name only"). Part of why I remain both intrigued and in listening mode is your assertion that "our time is valuable," as that is another point on which we agree. Yet, there is legacy, this is done on other types of relations besides rail, and I see no easy path forward, more like a vast, huge effort, when there seems to be a well-specified (legacy, true) method to do what we do already. This is simple (for certain reasons), and for that reason, makes a lot of sense. Yet it is also complex (in my mind, given the legacy), as in "how might one propose we move forward"? Simply stop creating route=railway relations altogether and let the legacy ones slowly wither and eventually die? I'd be happy to listen to a more-firm proposal on how to do that. But making that proposal? That's a bit of a tall bar for me to get to (right now). Though, I think I could get there. I'm also curious to hear if you think we might be able to eliminate route=road relations, too (perhaps on that wiki, not here. I note that wiki says "It is usually unnecessary to add these relations, because database users can combine connected highway=* ways which share characteristics such as the same name=* and ref=*.") I remain in listening mode, I welcome your further dialog and additional dialog from others. Stevea (talk) 00:12, 12 January 2020 (UTC)

As an aside, I forgot to mention that one issue upon which I seem to disagree with you is that "long Interstate highways are administrative fictions." I agree with you that "there is a grade-separated motorway here at a certain place...". No problem there. But this feels like the distinction between "physical infrastructure" (which everybody must agree exists) and "logical routing which is superimposed upon that physical infrastructure" which some do, some don't. What you call "a fiction" is what others call "a highway network." I don't want that single issue to "stick in anybody's craw" (be a point of contention), but I do feel the need to indicate that is a minor point of disagreement between us. Yes, "physical certainly exists." I say (you don't agree) that logical also exists, else why is there the entire concept of route "network"? (Same goes for bicycle route networks and their network=* and cycle_network=* tags, something with which I am also quite familiar in both OSM and the real world). Stevea (talk) 01:04, 12 January 2020 (UTC)

The "active" thread of this topic seems to have travelled to Talk:Tag:route=railway#.7B.7BTag.7Croute.7Crailway.7D.7D_vs._.7B.7BTag.7Croute.7Ctracks.7D.7D. Stevea (talk) 22:22, 17 January 2020 (UTC)

Semantic use: ref= vs. railway:ref=

We're working out better regional tagging clarifications over on OpenRailwayMap/Tagging in North America, as the way the railroads are run here is fundamentally different in enough ways that the default OpenRailwayMap/Tagging scheme really doesn't translate well 1:1 to North American uses. This activity has brought up the following question:

Here on the main tagging page, some objects use ref=*, and some use railway:ref=*. In a few passes through the page, I didn't see any one item that used both.

1. What is the intended semantic difference between the two tags, that drove which was selected for each object on the page?

2. If there is a difference in how each is rendered on the map as a label, what is it?

Thanks! We're working hard to make the North American guidance good, clear, and consitent wherever we can with the international system despite the major differences, so we really appreciate the clarifications!

Chuck (talk) 14:56, 10 June 2020 (UTC)

railway:ref=* is used for stations, halts, yards and signal boxes because ref=* was in use on them when railway:ref=* was invented. On stations, halts, yards and signal boxes, railway:ref=* is used for the reference number or code used by the company operating the infrastructure. ref=* has no fixed meaning and its usage varies way more between countries, regions and mapping habits of individual mappers. The purpose of this tag can be compared to uic_ref=* which is explicitly defined to take the international (UIC) station number while ref=* can be anything.<br

By the way, I prefer to see such discussions happen on the OpenRailwayMap mailing list which likely has more readers than a talk page in the wiki. --Nakaner (talk) 07:07, 12 June 2020 (UTC)

Thanks, that does confirm my best guess for the pattern. And I agree, in retrospect this general a question would've been more useful on the list. Thank you! Chuck (talk) 11:40, 12 June 2020 (UTC)

So railway:ref=* means the exact same thing as ref=*, but OpenRailwayMap made a new key to make it harder for casual mappers to find, thus limiting use of this tag to a smaller group of mappers who are focused on railways? Am I understanding this logic correctly? --Jeisenbe (talk) 18:03, 17 October 2020 (UTC)

Tagging railway loading points

Hi, how are loading mechanisms like those often found at quarries/mines (what are they called even, here's a picture (source Bing)) tagged? Are there even tags for these? Hiausirg (talk) 17:14, 22 May 2021 (UTC)

railway=track

In the Netherlands an import of railway data has been done and with that "spoortak" objects were imported. According to this document, IMSpoor vertaling NL - EN 1.0.0, the English word for "spoortak" is track. I see "spoortakken" with diamond crossings, see for instance https://www.openstreetmap.org/way/449428466.

Is it a good idea to use railway=track for this or are there better alternatives?

Emvee (talk) 19:44, 21 August 2021 (UTC)

Do you mean railway=rail + service=crossover? ---- Kovposch (talk) 09:42, 22 August 2021 (UTC)

Before writing the text above I did read about railway=rail + service=crossover but somehow I judged that it was meant for longer pieces of track but rereading it now, it think indeed railway=rail + service=crossover is the way to go. Thanks for the input. - Emvee (talk) 10:27, 22 August 2021 (UTC)

defect detector's ref

in w:Defect detector as we pass the detector we hear over the radio

CSX EQUIPMENT DEFECT DETECTOR. MILEPOST 7-0-0-POINT-1

mention if this means we should use

railway=defect_detector
ref=700.1

or better with

ref=mi:700.1

and/or

railway:position=700.1

And also mention how we should tag the building next to the tracks. Jidanni (talk) 07:42, 29 January 2023 (UTC)

man_made=street_cabinet ? building=... Jidanni (talk) 20:21, 2 July 2023 (UTC)

Detector sources

Mention https://database.defectdetector.net/

How to tag inland rail-truck intermodal terminals?

Regarding the node in the middle (not the land use area, which is already clear) should inland intermodal terminals be tagged as railway=yard or railway=station? K2000 (talk) 06:15, 6 July 2023 (UTC)

Add SelTrac signalling system

Hi, not sure how OSM tagging works but is it possible to add a SelTrac tag? https://en.wikipedia.org/wiki/SelTrac Tyteen4a03 (talk) 10:03, 27 March 2024 (UTC)

This railway:*=* format is poor. It has been suggested to change to railway:train_protection=* Proposal:Railway:train protection recently.
—— Kovposch (talk) 09:50, 28 March 2024 (UTC)

Clarification on ref=* value of railway=platform

I've already asked this question on the talk page of the railway=platform_edge tag, but since platform_edge tag seems to be relatively not so popular, I'll repeat my concerns here.

In Poland, tracks/edges are numbered independently from the platforms, as can be seen for example here.
Currently, the tagging scheme on this page suggests to set the value of the ref=* key on the railway=platform element to "The track numbers served by this platform".
It seems really counter-intuitive to have to input something else than the platform number into the ref=* value of a platform, when a platform has an own reference number, which is e.g. the only number displayed on the information boards in the station halls.

Is this an oversight due to the obscurity of the "Polish" system, or a deliberate choice? If it's a choice, why?

Regards, --Dzamper (talk) 14:38, 6 April 2024 (UTC)