Shoulder=* tag is confusing

Whatever decision will be made, my vote is for a pragmatical and structured solution.

Pragmatical meaning not to insist on details which are hard to verify. Most people would be able to assess if a shoulder is wide enough to park a normal passenger car but many would not be able to estimate if the width is 1.5 or 2.0 or even 2.5 meters. From that point of view shoulder=yes if the mapper rates it to be wide enough as emergency stop for a normal passenger car should do.

If the mapper rates the shoulder to be not wide enough, but still wide enough for bicycles or pedestrians this is a valuable information which should not get lost due to a missing tag. In this case shoulder=narrow is much better than nothing and easy to understand.

In both cases additionally shoulder:width=* and shoulder:surface=* add valuable information.

Side note: In regard to the surface a “hard shoulder” is not limited to asphalt or concrete. Also one made of paving stones or grass pavers fulfil the condition “paved” as mentioned in the wiki.

Structured is in I my understanding what @westnordost proposed with his samples in post #13. It allows a consistent tagging of nearly all situations to be found OTG. Considering the above said + considering the acutal use of the shoulder tag I would vote for (using the descriptions to the sample pics given by westnordost):

  • hard shoulders that are broad enough to accomodate a whole car:

shoulder=yes + optional shoulder:width=2 + optional shoulder:surface=asphalt

  • hard shoulders that are not broad enough to accomodate a whole car:

shoulder=narrow + optional shoulder:width=1.5 + optional shoulder:surface=asphalt

  • hard + soft shoulder:

shoulder=narrow + optional shoulder:width=.5 + optional shoulder:surface=asphalt + verge=yes + optional verge:width=1.5

  • soft shoulder only:

verge=yes + verge:width=2

Regarding verges the wiki page limits those to strips of low vegetation which means every surface not being paved (=shoulder) nor low vegetation (=verge) would have no valid tagging. I have seen roadside strips coverd with loose gravel oder pebbles so if these would be understood as verge it could be helpful to tag verge:surface=* as additional option (corresponding to shoulder:surface).

3 Likes

I would not try to redefine it: in such case we cannot ever be sure is it following older unclear situation or new definition.

2 Likes

Maybe emergency_lane / narrow / no?

emergency_lane might be yet another value. I wouldn’t use it so describe wide shoulders - the term contains the intended use of the shoulder. And in fact, in Germany there are very wide shoulders (that are free to be used to park and by slow vehicles) and very wide shoulders (that are dedicated emergency stopping lanes that must not be used by anybody else).

So, yes / no / wide / narrow / emergency_lane? Having the distinction between wide and narrow at about 2 - 2.5m?

To all who write “why not just use shoulder:width”: This would mean you always need a measuring tape, i.e. tag it very precisely, just to record whether something is a “proper” shoulder or just a narrow strip.

I’m reasonably sure someone has written an editor that can use your smartphone’s camera to measure widths :wink:

(also, any halfway competent desktop editor has a width-measuring function for aerial imagery, right?)

So, yes / no / wide / narrow / emergency_lane?

wide / narrow / no should be enough then. yes can be interpreted as a deprecated alternative to either wide or narrow. Usage for parking and slow vehicles can probably better be described with separate tags (such as the existing shoulder:bicycle=* and parking:condition=*).

1 Like

I agree with you and did not think about giving it a new definition but return to it’s initial meaning as quoted by @Richard in #2. Of course we could leave shoulder=yes as “undefined” which it has apparently become over the years. If you do not want to touch this I believe

shoulder= yes (deprecated) / no / wide / narrow / emergency_lane

would also serve as pragmatical solution, but one has to be aware, that shoulder=wide/narrow could easily be misinterpreted again as long as there is no clear distinction between “hard shoulder” and “soft shoulder”. Even a better documentation in the wiki could not really inhibit this as not every mapper takes time to study every wikipage carefully.

Maybe it would helpful to leave shoulder=yes/no as it is now and start using

hard_shoulder=wide/narrow/no + optional/additional tags

in future to avoid running into the same mess again.

How about:

  • Calling everything expanding further than the end of road marking but somewhat (semi) regularly used by cars shoulder? Surface can be defined by surface tags, width can be defined by width tags etc. there’s no need to be unflexible here.
  • And have a tag ‘emergency_lane’ for an emergency lane? Since well, it’s an additional lane, not a shoulder. End of road markings are commonly made twice in such a case - on both sides of the emergency lane.
  • A verge is filled with vegetation. It could in theory be used in an emergency to get off the used road, but a regular vehicle might get stuck here.
1 Like

Following on from Richard’s wiki quote:

With that definition in mind, how would people classify this?

I chose that because it’s about the only bit of road near me tagged as “shoulder=left” that I’m not convinced is correct. It’s about 1m wide, and so certainly isn’t wide enough to be used as an emergency refuge for cars. It’s just about wide enough to cycle down, if you don’t stick your arms out, don’t mind 40 tonners whizzing past your right ear, and don’t know about the separate cycleway to the north or parallel tarmac bridleway to the south.

I wouldn’t have tagged that as a shoulder myself, but I’m not sure what I would tag it as?

2 Likes

I wouldn’t have tagged such unclear thing at all, period, unless I was forced to - when I would (under current definitions) map that as shoulder=no.

But then the issue is that current tagging schema is unclear… If it were clear as some suggest, then all answers in this discussion and all versions of wiki would be the same. As they are different, it is obviously unclear. QED. Changing the wiki now won’t help; best we can do now is invent new values which would be precisely defined from the start, and deprecate unclear yes/no values.

However, if my new tagging scheme was accepted and documented, it would be shoulder=its_complicated (which is value between shoulder=not_even_a_hedgehog_could_use_this and shoulder=yeah_sure_you_could_park_a_space_shuttle_there) :smile:

1 Like

Likewise, I wouldn’t tag that at all. It’s just an artefact of highway construction and maintenance that the white line has been painted a short way in from the edge (my suspicion is that it’s basically “future-proofing” against a crumbling road edge).

It’s not really a useful or significant object for anyone using the road and it doesn’t meet the definition.

2 Likes

It looks like the discussion came to a close. This is something that should likely go into a (small) wiki proposal. Would someone put the result of this discussion into a proposal?

I would but I am quite busy at the moment.

Also, one issue I see currently with what has been proposed so far (i.e. especially with my own proposal where I specifically mentioned how it could look like if we started on a green field) is that it (re)defines the shoulder tag to mean (as some also demand or at least always understood it to be the case in this thread) that something only counts as shoulder if it is paved, everything else is a verge.
This disregards that there are currently roundabout 400 values of shoulder:surface (etc.) with values that indicate unpaved surface. That’s really not a lot if you consider the amount of shoulders that exist but these values still exist.

I don’t think that’s a problem - in developed countries, highway=tertiary is assumed default paved too, but that doesn’t mean highway=tertiary; surface=gravel is an invalid combination.

2 Likes