Talk:Tag:barrier=guard rail

more description form guard rail for motocycle

there are but there are too and for motorcycle there's some importance for the second. does we need to add a tag like guardrail=motocycle? -Yod4z (talk) 11:02, 24 February 2014 (UTC)

My suggestion is guard_rail:motorcycle_friendly=yes. This leaved room for more, like e.g. guard_rail:double=yes or guard_rail:profile=--Jojo4u (talk) 19:16, 26 March 2015 (UTC)

Change direction description

This part

> If there is a clear inner/outer demarcation to the guard rail, construct the line so that the right side is inner and left side is outer.

should be reverse so its more clear and easier to understand. On a simple road, when reversed, it ould face the same direction as the driving-direction of the car (if driving on the right side of the road, of course). I made an example drawing of how it should be, in my opinion.

I'm afraid this will not change as it is used already 65.000 times and seems to be in the wiki since 2014.

-Negreheb (talk) 12:25, 15 September 2020 (UTC)

To put it in other words: The inner and outer definition as currently stated in the wiki contradicts the "usual" definition used in other barriers like Tag:natural=cliff or Tag:barrier=retaining_wall where "right" describes the bottom side of the barrier, i.e., where one would fall deeper when crosses the barrier. In the case of the retaining wall the left side is also the one that is prevented from moving down by artificial means. While there is no clear upper and lower side on guard rails I would argue that it's more natural to derive the semantic of the direction from the main purpose of the barrier, which is preventing road users from getting off the road.

Interestingly, there is no direction specified for Tag:barrier=handrail although they are similar. There, another aspect comes into play more frequently: being in the middle of two was with no clear direction (think about wide stairs with multiple (>2) rails.

--Stefanct (talk) 13:10, 15 September 2020 (UTC)

I do also find it very strange, that the so called "inner side" (with the smooth surface) should be right. For a long time, I was thinking and assuming that it would be left (and drawed it in this way) – because on a two-directional road you have to draw the way for the guard rail in opposite direction to the traffic – that is not intuitive at all. BUT: this only counts for countries with right-hand traffic (like Germany and other 175 countries according to Wikipedia) and not for right-hand traffic countries (75 according to Wikipedia). See this graphic:

Right-hand traffic (red) and left-hand traffic (blue)

So I guess, this definition could come perhaps from the UK (?) – only a suspicion. Anyway – not a good decision in my opinion. And too bad, that only the argument with the usage numbers counts or comes as an answer in these cases. A bad logic or remains a bad logic – or a bad definition, which is not intuitive enough remains a bad definition, it should perhaps be changed as soon as possible, and we will have a better situation in the future, and soon there will be more years and usages with a good logic (and old ones which have been changed or complemented with a new subtag, see below). Let's hope there will be OpenStreetMap also in 100 years (with a good, not a bad logic and good definitions). And one question to the usage numbers: is it also clear and sure, that it was drawed in the defined way in the majority of the now 77.800 usages? Perhaps most of the mappers drawed it intuitively in the other direction (with a better logic in my opinion)? And does any documentation or discussion exist, when this definition was made – with some arguments? I did not checked it so far ... would perhaps be interesting why it was decided in this way ...

Anyway: perhaps it would be much better to completely drop the definition of the guard rail inner/outer side via the direction of the way, and introduce an additional (sub-)tag as it is already mentioned/proposed in the next chapter ’Tagging guard rails with two "inner" sides’ by Biff: guard_rail:smooth=* (I would propose guard_rail:smooth_side=*) with the values left|right|both. Then you could draw new guard rails in any direction and also old guard rail ways could be complemented with this subtag (without the need of changing the direction of these existing guard rail ways!). This would also correct guard rails which were drawn in the "wrong" direction according to the old definition ... I guess, this could at least be a not insignificant number ...

It reminds my to a situation with highway=steps, where for some time the wiki stated (as far as I remember), that ways for steps should best (or always?) be drawn in in the ascending direction of the steps (generally a good logic! – but that was also too complicated for some mappers, and many steps existed which where drawn in descendig direction – with no other tag, and you could not know, if it goes up or down). But then the usage of the tag incline=up or down was recommended as a better and clearer method – and a more flexible one: it allows to draw steps in a descending direction, too. Why not ... And the recommendation to draw it in ascending direction was removed, I think.

Perhaps this could also be the way to go here for a migration/transformation from the old solution/definition (not optimal/not intuitive for everybody) to a better solution. A typical progess. And it also would be a solution for guard rails with two "inner" sides ... Would this be a possibility? Or anyone have a better idea? --Goodidea (talk) 16:44, 11 May 2021 (UTC)

Tagging guard rails with two "inner" sides

I'm aware of guard rails that have struts in the middle and smooth elements on both sides. How should this be tagged? --Biff (talk) 10:59, 25 February 2021 (UTC)

Simply one for each side in opposite directions? We don't care about the struts as much as the rails. ---- Kovposch (talk) 11:04, 25 February 2021 (UTC)

Frequently it is difficult to tag two elements that are so close to each other. They might have to be drawn on top of each other. Maybe it would be better to define an additional tag like guard_rail:smooth. The implied default value would be guard_rail:smooth=right and the other relevant value would be guard_rail:smooth=both. What do you think? --Biff (talk) 11:22, 25 February 2021 (UTC)

Some people have apparently also used two_sided=yes. It's not yet that common for guard rails in particular, though, so there's room for better suggestions. --Tordanik 16:28, 25 February 2021 (UTC)

There's also ~42k side=* for traffic_sign=* mostly. ---- Kovposch (talk) 18:36, 25 February 2021 (UTC)

Problem is these are already defined to be one-sided and direction-dependent. Any change would be very far reaching. Maybe eg barrier=guard_rails? ---- Kovposch (talk) 18:36, 25 February 2021 (UTC)

I've started tagging guard rails with guard_rail=right/left/both, to specify which side of the way the rail is on. I think this makes more sense than the implicit side method currently documented, and also handles the double-sided case. --AntiCompositeNumber (talk) 12:57, 3 October 2023 (UTC)

I agree with AntiCompositeNumber, It fits well within the osm tag naming convention and guard_rail key doesn't currently have any consistent usage with significant numbers. its been used 1800 times with 1000 of those being guard_rail=no so its most likely being used to describe guard rails via a tag on the highway. I'll start following guard_rail=right/left/both practice too. --Kitsee (talk) 14:13, 3 August 2024 (UTC)

Define steel as default material

According to taginfo (https://taginfo.openstreetmap.org/tags/?key=barrier&value=guard_rail#combinations) it is quite common that users add tags that indicate that the guard rails are made of metal or steel. However, according to the tag description, this is anyway the default material. In my opinion, the material only needs to be tagged if it clearly differs from "steel". --Biff (talk) 11:05, 25 February 2021 (UTC)

Nodes

This node represents a guard rail spanning the width of the street to block vehicular through traffic. [1] This is a common method of calming traffic in a residential neighborhood. It can be mapped as a way, but there should be a barrier=* node of some sort for renderers and routers to know that the road is impassable, similar to how barrier=block is often mapped. A mapper has inserted a tiny highway=pedestrian way as a workaround, but I think allowing barrier=guard_rail to be tagged on a node would be a cleaner solution. – Minh Nguyễn ^💬 01:23, 30 June 2022 (UTC)

In some countries, to close a road, they use trees (tree trunks). In others I saw a big pile of sand or earth. According to taginfo, you can currently find barrier=tree (252 on a node), barrier=trunk (14), barrier=earth (2), barrier=sand (6), barrier=embankment (24). So why not a guard_rail. But in the wiki you have to write the "normal" use of a tag. And the normal use of a guard_rail is along a road so on a way. You can have exceptions, but only in osm data base, not on the wiki. The second point is how it will be understood by softwares. "barrier=yes" will be understood by any and when you will search a route from A to B, the software will not send you on this road. With barrier=tree or guard_rail, I'm not sure all software will work. It will probably work because of access=no. So the important tag in your case is not barrier but access. Best regards. Fred73000 (talk) 20:52, 2 July 2022 (UTC)

barrier=log is what you are looking for. I heard some routers don't consider barrier=* without access=*. --- Kovposch (talk) 07:12, 3 July 2022 (UTC)

@Fred73000 and Kovposch: More or less. OSRM primarily considers access tags (not just access=* per se) on nodes along the way, even without any barrier=* tag. It also considers all but a few barrier=* values to imply access restrictions. If a barrier=gate for example is always closed and locked, you'd have to add access=private or access=no explicitly. But for any value that the OSRM developers were unaware of at the time they wrote the whitelist, access=no is assumed.

I certainly would add access tags to a barrier=guard_rail node, but editors and QA tools would still flag it as invalid unless we document that it can also occur on a node. As I said, this is a common method of closing off a road in some regions, more common than barrier=block, which is more expensive to manufacture and install.

 – Minh Nguyễn ^💬 06:54, 28 July 2022 (UTC)

I agree that the use of guard_rail as a node should be documented. This type of barriers blocking roads exist all over the world (I confirm that in Argentina too), and other types of barriers such as new serseys are documented, there is no reason not to document this AgusQui (talk) 14:33, 30 June 2023 (UTC)