Talk:Key:shoulder

Shoulder=<paving>

This should be shoulder=paved/unpaved, not yes/no. Otherwise this sign wouldn't make much sense. --NE2 21:59, 4 August 2010 (BST)

Adding Shoulder.surface

Maybe add shoulder.surface={same values as the regular surface tag}?

I must admit than many values do not really apply but ...

Extract from http://wiki.openstreetmap.org/wiki/Map_Features

surface = {paved / unpaved / asphalt / concrete / paving_stones / cobblestone / metal / wood / grass_paver / gravel / pebblestone / grass / ground / earth / dirt / mud / sand / ice_road}

If shoulder=yes and shoulder.surface is not present, it is assumed shoulder.surface=paved

Shoulder=yes is a given for almost any (rural) road. The shoulder is simply the clear area that you pull into if you break down. It may simply be grass. --NE2 00:45, 5 August 2010 (BST)

Based on NE2 comment, I understand that if no shoulder tag specified, we must assume as default shoulder=yes and shoulder.surface=unpaved --[Tremblad, 9 August 2010]

I like very much shoulder.surface than shoulder.paved alternative. By default, I don't assume nothing. As we don't assume nothing in maxspeed or other highways features. But if we have to put something by default, I only assume that shoulder=yes. The surface is dependant on countries and type of roads. But it's just an opinion.--Xan 15:12, 9 August 2010 (BST)

In France, shoulder paved called bande dérasée is different from an emergency where all traffic is forbidden lane. A bande dérasée is necessarily paved, otherwise it is a low side. So in France shoulder:surface=unpaved can not exist. --Zoubiddaaa (talk) 15:54, 6 September 2014 (UTC)

side

I'm thinking that instead of shoulder:side={left,right,both}: where is the shoulder? perhaps it might be better to use shoulder:{left,right,both} = ...

So instead of shoulder:side=left you would do shoulder:left=yes.

This way you can do,

shoulder:left:width=2
shoulder:right:width=3

I guess you could also do this with shoulder:side, but this way it seems you can universally apply the practice of feature(:{left|right})?(:attribute)*=...

Just a thought.Aharvey 09:33, 4 November 2010 (UTC)

I'm agree with you. Please modify the proposal. Better this way.--Xan 15:37, 4 November 2010 (UTC)

forward and backward

Wondering if using the forward and backward values would be better than right and left. This would bring the syntax into alingment with, for instance, the lanes syntax. In this case, for a roadway segment, you would have shoulder:forward=yes and/or shoulder:backward=yes. In this variation, I would suggest not using shoulder=both but rather just use the two shoulder:forward and shoulder:backward both with yes values to indicate both; I would also suggest not using shoulder=no or shoulder:forward=no, but rather let the absence of a value indicate the absence of a shoulder. --Ceyockey 17:08, 13 January 2013 (UTC)

This doesn't work on a one-way road. --NE2 19:24, 13 January 2013 (UTC)

I thought it would. Are not 'forward' and 'backward' relative to the direction that the way is drawn, so that on a oneway road in the US, forward would always be on the right and backward would always be on the left? --Ceyockey 12:39, 14 January 2013 (UTC)

Forward and backward are in relation to the direction of the way and actual real-world movement along the way. For example, maxspeed:forward applies not only to vehicles in the main lanes and right shoulder, but also to bikes being driven against traffic on the left shoulder (which is legal, at least in Florida, if it's a shoulder and not a bike lane). --NE2 16:17, 14 January 2013 (UTC)

If I understand correctly, 'forward/backward' should only be used for things which relate directly to movement (e.g. speed limit), whereas 'right/left' should be used for static properties of the roadway. Is that a correct interpretation? --Ceyockey 22:49, 14 January 2013 (UTC)

Basically. The two do overlap, however, when dealing with static properties that should only be used in one direction, like a bike lane. --NE2 01:18, 15 January 2013 (UTC)

Example

I've applied the shoulder syntax I described to the Bear Tybouts Road appearing in the view http://www.openstreetmap.org/?lat=39.6284&lon=-75.65171&zoom=16&layers=M . This has several variations in shoulder values along its short length. I've not put a surface value as I would expect this to come from survey results and this is just armchair mapping. --Ceyockey 17:16, 13 January 2013 (UTC)

Resolved: Both left/right/... in key (your suggestions) and left/right/... in value are in use today, though the former is vastly more popular. The fact that both are in use is documented now --Westnordost (talk) 22:55, 14 April 2022 (UTC)

Quality?

I was thinking about this during a very long ride over the weekend, when I plenty of time to contemplate highway shoulders :) I decided there are 5 grades of quality:

• A: as good as, or better than, the main road surface.
• B: almost as good as the main road surface. Cycle tourists will happily ride here, road bikers will only do so if there's traffic.
• C: significantly worse. Bearable for short stretches if necessary. Cracked pavement, weeds, lower grade asphalt.
• D: very soft, dirt or sand with gravel. A mountain bike can force their way through, but for everyone else it's pretty much unrideable.
• E: no shoulder: grass, vegetation, or obstacles.

  I struck out 'grass' as this would generally go into either C or D; lots of "shoulders" are just grass on the roadside which people will drive onto. --Ceyockey 12:45, 14 January 2013 (UTC)

I think "quality relative to main surface" is probably the better approach than absolute surface indications like "paved" etc. Stevage 02:34, 14 January 2013 (UTC)

Why not smoothness:shoulder to go along with smoothness=*? --NE2 04:19, 14 January 2013 (UTC)

There are also situations where trying to pull off the road is downright dangerous, particularly if there is a drop-off into a drainage ditch. One might extend the letters to "F: Beware - drop-off or other significant danger." This is particularly a problem in rural agricultural areas in the US. --Ceyockey 12:45, 14 January 2013 (UTC)

tag shoulder like sidewalk

I think it would be better to use the same tagging style as for sidewalk. Which means that the side of the shoulder would be tagged directly with the main tag:

• shoulder=yes
• shoulder=no
• shoulder=right
• shoulder=left
• shoulder=both

I agree that this would be preferable. --Tordanik

Resolved: Resolved

Parking lane

If there is a parking lane next to the curb (e.g., in a retail area), does shoulder=* apply there? Or is this for areas that are expected to be relatively clear for use in emergencies or for bike travel? Germyb (talk) 02:17, 25 September 2017 (UTC)

For parking lanes, see Key:parking:lane. Usually, a shoulder must be kept clear for use in emergencies, otherwise it is a parking lane. But certainly, there is somewhat of a smooth transition between what can be considered a shoulder and what can be considered a parking lane. For what it's worth, there is e.g. the value parking:lane:right:parallel=shoulder to mark a shoulder where it is allowed and common to park cars --Westnordost (talk) 22:50, 14 April 2022 (UTC)

Resolved: Resolved

Tags proposed in "Refinement" section don't make sense

• shoulder:surface=* and shoulder:smoothness=* assumes that the shoulder is always fully paved or fully not paved (grass, gravel, ...). This does not account for shoulders that are not fully paved like this one or that one, very common for non-motorways. Any road that has a shoulder at all, there will at least a tiny portion of it paved, otherwise there would be no room for the shoulder line.
• shoulder:width=* is not too valuable because if a shoulder is not wide enough to give refuge to any vehicle completely off the rest of the roadway, then it is not a shoulder in the first place. Furthermore, if the shoulder is not fully paved, it is not clear to which the width refers: only the paved section or all of it? If all of it, where to stop measuring? This is quite fuzzy
• shoulder:bicycle=* doesn't make sense to tag on individual shoulders because whether cyclists may/must officially use shoulders is something that differs per country legislation, not per individual road
• shoulder:line=*, too, differs per country legislation, not per individual road. This tag would be in the same league of usefulness as recording for individual roads which color the cycle lane lines have. By the way, here is a list how shoulder lines look per country: https://github.com/streetcomplete/countrymetadata/blob/master/data/edgeLineStyle.yml , e.g. in Ireland it's short yellow dashes.

One thing I see that would be missing as a refinement would be whether it is a "full" shoulder (i.e. fully part of the asphalted surface) or a "half" shoulder (i.e. vehicles need to stop with 2 wheels on the asphalt and 2 wheels in the gravel/dirt/grass. But even this information is not that valuable, I guess, as the most important bit, whether there is a usable shoulder or not, is already recorded.

--Westnordost (talk) 22:33, 14 April 2022 (UTC)

Definition changed in January 22?

The definition of a shoulder was changed a couple of months ago to refer to full width emergency stopping lanes only. Was there any discussion or consensus on this?

Before it read: "A shoulder, often serving as an emergency stopping lane, is a reserved lane by the verge of a road or motorway..."

Now it reads: "A shoulder is an emergency stopping lane [...] suitable to allow any vehicle to safely stop beside the traffic lanes without obstructing other traffic."

This new definition invalidates about 50% of all shoulders with a shoulder:width tag because they have a width of less than 2 meters which clearly doesn't fit to the new description.--Mueschel (talk) 10:01, 27 April 2022 (UTC)

See the change comment for the source of this change (direct link). My intention was not to redefine the tag but to make its definition more precise. For this, I did some research by looking randomly at roads tagged with shoulder=yes/both to document in what situations this tag is de-facto used and the more precise definition you cited was the result of that. However, I didn't check for trunks and motorways because I assumed those would all have a hard (asphalted) and broad shoulder anyway. So, you are right, apparently, there are a lot of shoulders tagged on trunks and motorways that have a shoulder:width of less than two meters.

I had some discussions (sparked by this post on Talk-GB) with a few OSM contributors from UK because they were unhappy about the definition of a shoulder used in StreetComplete, which read "A shoulder is a clearly demarcated emergency stopping lane that is wide enough to allow any vehicle to stop safely completely beside the traffic lane, not necessarily (fully) on paved surface.". Funnily, the issue was that they found that definition to 'not be strict enough, as it included things they would have tagged with verge=* instead like "just some unpaved area beside the road" or shoulders that partly or fully were just a mowed grass patch.

I guess this is the result of a broad and imprecise definition: Everyone has an own definition what can still count as a shoulder=*. For some, only asphalted 3m wide motorway-style shoulders are shoulders, for others, a narrow grass verge seems to be enough. The result is that this data is nearly worthless and up for edit wars.

In that light, shoulder:width=* is maybe a good way to filter out shoulders that are "not really" shoulders, however, the issue with shoulder:width=* is that it is not defined which width is meant: Just the paved part? Or all of it? If all of it, where to stop measuring exactly, e.g. a ditch usually doesn't start at a certain width but it is a continuous slope. In any case, however shoulder:width=* should be defined, the point is that it is currently not defined, which means, like for shoulder=*, everyone may have an own definition here which is why again, this data might be worthless too. See also the discussion right above this one.

My conclusion: If the de-facto usage of shoulder:width=*...

* describes the paved part of the shoulder, current documentation of shoulder=* is fine

* describes paved + unpaved (if applicable) part of the shoulder, current documentation needs to be amended

* describes sometimes the paved part of the shoulder only, sometimes both, then, I don't know... shoulder:width=* would be kind of unusable

For now, I will just add a paragraph/footnote that refers to this tag. --Westnordost (talk) 10:51, 27 April 2022 (UTC)

Actually, I don't know what to write. I will instead do some random research using this overpass query and mapillary/streetview --Westnordost (talk) 11:02, 27 April 2022 (UTC)

I think we should revert the description to the old version - just the definition I cited, the details about definition can stay as they are. Width should be defined by whatever is "usable" for the intended purpose, matching the local standards: Unpaved parts might be a hazard in wet areas and might be perfectly usable for trucks in dry areas.

So your opinion is that shoulder:width=* should describe the part of the shoulder that is "usable". That's one and maybe the most reasonable interpretation. But for tags that are already in use, it doesn't matter what the tag "should" mean, it matters how it is actually used. I am looking into the data right now to find how this tag is used in the wild. Will report back later --Westnordost (talk) 11:49, 27 April 2022 (UTC)

I completed the research (see below). It looks like the tag is indeed mostly used the way we'd find meaningful. In documentation, I used the word "designated as" (DE: vorgesehen für...) to make clear that a non-fenced meadow (etc.) doesn't count as a (hundreds of meters wide ;-)) shoulder and to implicitly express that the standards for what makes a shoulder depend on the local standards, as you say. Since thus shoulders that are not broad enough for any motor vehicle obviously exist and are also tagged as shoulder=*, I removed the part. See the diff here. --Westnordost (talk) 14:49, 27 April 2022 (UTC)

Unrelated to this issue, discussions about issues in some external software should not be used as a reason to change the meaning of tags - software has to adapt to OSM standards, not the other way around. --Mueschel (talk) 11:30, 27 April 2022 (UTC)

Sure, as I wrote, it has not been my intention to change the meaning of a tag, just to document the current de-facto usage more precisely. The relevant part of the linked GitHub issue is not the discussion as a whole, but the outcome of the research conducted. --Westnordost (talk) 11:46, 27 April 2022 (UTC)

Documenting definition of shoulder:width

It is not documented what is the exact definition of shoulder:width=* - i.e. is it the width of only the asphalted part, all of the usable width or something in between? Prompted by the discussion above, I did some research on only non-trunk and non-motorway roads using this overpass query, i.e. roads where the likelyhood of soft shoulders (shoulders that are not fully paved) is higher. From the overpass query, I picked random roads and compared how they look in reality.

Result

Only a small percentage of roads tagged with shoulder=* also have shoulder:width=* tagged (~13%). Most can be found in Spain. And only very few roads that do not have hard shoulders (i.e. fully paved shoulders) have shoulder:width=* tagged. In the table below, most items are hard shoulders.

cc	width	usable part	only hard part
ES	0.7	✔	✔	link
ES	1	✔	✘	link
ES	1.5	(✔) slight ditch	✘	link
ES	0.7	(✔) slight ditch	✘	link
ES	1	(✔) slight ditch	✘	link
ES	0.8	✔	✘	link
ES	1.3	✔	✔	link
ES	1	(✘) broader than 1m	✔	link
ES	1.2	✔	✔	link
ES	1	✔	✔	link
ES	1.5	✔	✔	link
ES	0.4	✔	✔	link
ES	0.7	✔	✔	link
FR	1.5	(✘)should be more than 2m	✔	link
FR	1.2	✔	✔	link
FR	0.4	✔	✔	link
FR	1	✔	✔	link
NO	2	✔	✔	link
NL	2	✔	✘	link
DE	2	✔	✘ (paved part is never 2m)	link
AU	0.6	✔	✘ (paved part is never 2m)	link
AU	2.9	✔	✔	link
AU	1.7	(✘️) varies	✔	link
AU	2.3	(✔/✘️) varies	✔	link
US	5 ft	(✔) varies	✔	link
US	6 ft	✘	✔	link
US	6 ft	✔	✔	link
US	6 ft	✘	✔	link
US	1	✔	✔	link
US	3	✔	✔	link
US	4	✔	✔	link

Conclusion

As can be expected when a tag is not clearly defined, there is some variation. However, it is clear that the tag has not been used to only record the width of the paved part of the shoulder. Hence, I think the most broad definition that would fit for pretty much all the roads that have been checked would be that shoulder:width=* defines the width of what is (not necessary just usable but) dedicated as a shoulder. For example, some grassland left and right is not a shoulder, but if it is clear that it is dedicated as a shoulder (it's maintained), then it counts towards the shoulder width. --Westnordost (talk) 14:19, 27 April 2022 (UTC)