Rare `cycleway` value `shoulder`: obsolete or useful?

General talk Tagging general discussion
,
1

About 98% of all cycleways (, …:left, etc.) have currently values that are valid and documented.

I am currently sifting through the 2% rest in an effort to see whether there are any that make sense and should maybe be documented as in-use. After all, 2% are still over 30000 values.

Most of these are indeed garbage, i.e. ambiguous values such as yes,both,left,right,on_street,segregated,shared,sidewalk,share_sidewalk, … obsolete values that are probably synonymous to valid values or tag combinations such as none,sidepath,use_sidepath,buffered_lane,soft_lane and troll tags such as proposed or construction.

However, the most-used undocumented value (after the obsolete and ambiguous shared) is…

shoulder

(… to which the undocumented value unmarked_lane is maybe synonymous?).
Together, they have about 12000 usages (0.45%).

It is pretty clear what the value is used for: That cyclists use the shoulder / breakdown lane in absence of an explicitly marked lane. (In many legislations, cycle lanes are actually described as shoulders specifically reserved for cyclists.)

Now, there is duplication with the (ill-defined) shoulder tag the same way as with the sidewalk value. But unlike the sidewalk value1, it is not ambiguous, because if there were a sign that cyclists must use the shoulder, then it would simply be a lane. So, directly has some utility.

So, I don’t know. In particular, I wonder if that value should be supported in StreetComplete or marked as an invalid value. What do you think?

Contra shoulder value

  • Duplication
  • Verifiability issue about whether it is usable and allowed for cyclists to use. Just add cycleway=lane to every paved shoulder=yes if there is no other cycle infrastructure??

Pro shoulder value

  • The shoulder key is badly defined, or at least, in a way that it is not useful for cycling tagging:
    1. a shoulder=yes could actually have a gravel surface (according to wiki), rendering it unusable for cyclists
    2. as defined in the wiki, if the shoulder is not broad enough for a car it’s shoulder=no. However, a narrow shoulder is already useful for cyclists
  • Duplication: We already have another value that refers to another tag, share_busway. Also, e.g. parking:lane=shoulder which also refers to the shoulder tag. So duplication is not necessarily a no-go per se.

1 because it is not clear whether that sidewalk is a non-segregated cycle- and footway (cycleway=track + cycleway:segregated=no) or whether it is a sidewalk where cyclists are merely allowed (cycleway=no + sidewalk=both + sidewalk:bicycle=yes)

2 Likes
2

I’m not so sure about this. There’s a difference between a bike lane and a shoulder that cyclists can or must use. For one thing, if a car experiences a fender-bender, the law may require the driver to clear the traffic lanes, including any bike lane, by moving the car to the shoulder. Other obstacles, such as garbage bins or a mobile, police-operated radar speed detector, may also occupy the shoulder.

It’s also possible for a shoulder to function as a parking lane or as a bus lane during rush hour, but this usage doesn’t diminish its identity as a shoulder.

3

I don’t understand the connection between the cited sentence and your comment. What are you not so sure about? That a situation where a sign mandates that the shoulder must be used by cyclists but at the same time all kind of other stuff is placed on the shoulder?

4

I’m not so sure that the mere presence of this kind of restriction necessarily turns the shoulder into a lane. Maybe the distinction between shoulder and lane is useful in cases where a physical shoulder is being used as a lane?

5

Hm, but it does not, if I understand what you are talking about correctly? if it were official cycle lane, it would be marked with cycleway:right=lane. To me, cycleway:right=shoulder would instead indicate there is no official cycleway lane, but that the cyclist in need might decide to use the existing shoulder and still reach their destination (assuming they tolerate such driving conditions, of course).

Yes, I think so (see above).

2 Likes
6

For me, it is a problematic argument to establish such a value because the actual shoulder tagging is broken (because that is the only reason why cycleway:*=shoulder would have a benefit imho). That doesn’t sound sustainable to me. Let’s just™ fix the shoulder tagging and use tags like shoulder=* + shoulder:width=* + shoulder:surface=* as perfect indicators for the suitability of a road for cycling.

7

Hm well, there are several issues with this approach…

First, the shoulder tag only declares the physical layout of a shoulder. It does not communicate anything about how it is used or usable (in reality), other than that you can stop there if your car broke down.
As @Minh_Nguyen noted, there could be all kinds of stuff on the shoulder that inhibits it being used for cyclists. E.g. it could be used for parking parking:lane:parallel=shoulder (/parking:position=shoulder)

Additionally, pretending the first point is not an issue, there is a problem with the level of detail (for data consumers). Just to know whether there is a shoulder usable as a cycle lane, a data consumer so inclined would need to analyze three tags. More importantly yet, it is even more so of a problem for the mapper (of shoulders), because to make the shoulder information usable in the context of cycle infrastructure mapping, he’d have to add up to 3 tags. And that, on the premise, that mapper knows about the relevance of such precise shoulder tagging for cyclists - i.e. why should the mapper care about adding such detailed information?

And lastly, well, we have to work with what we got: Over 20000 ways have cycleway=shoulder tagged. Removing these would mean to destroy previously collected data. If cycleway=shoulder is something that should be removed, then there must be an equivalent tagging with which the information carried in this tag - “cyclists can use the shoulder” - can be expressed instead.
Even with a reformed shoulder tagging (that could just™ be proposed) as discussed in the shoulder-thread, there’d not be a 1:1 tagging conversion to it, as the minimum information that must be supplied there whether it is a wide or narrow shoulder (which is irrelevant for shoulders usable by cyclists).

It’s really quite similar to parking:position=shoulder, the more I think about it. Even from a reformed shoulder tagging, you can’t really infer whether cars (can) park on it. After all, it could be a narrow shoulder, but the rest of the verge is filled with gravel, so shoulder parking is possible after all (or would that be half-on-kerb-parking?) Or, it could simply be prohibited.

3 Likes
8

Well, I assumed that someone mapping cycleway=shoulder would also map shoulder* instead.

However, I had doubts about cycleway=shoulder at first because I hope that in the future there will be a much stronger focus on detailed information such as width and surface/smoothness information and in my opinion it would be unacceptable to map cycleway=shoulder + cycleway:width=* + cycleway:surface/smoothness=*, where cycleway:width and cycleway:surface/smoothness are the same as shoulder:width and shoulder:surface/smoothness.

But thinking more about it, I like your comparison with bus lanes (cycleway=share_busway). One would usually not map such details either, but derive them from the road/bus lane attributes if needed. The same recommendation would then apply to cycleway=shoulder: This tag means there is no dedicated cycle lane/infrastructure, but the shoulder is suitable for cycling and all details for evaluating the suitability can be derived from shoulder tagging if required/if mapped.

This would challenge the definition of cycleway (“…to map cycling infrastructure that is an inherent part of the road…”), but in my opinion this is within an acceptable range.

(In any case, I would oppose the use of cycleway=lane in such situations, as they are not dedicated cycle lanes and therefore cycling traffic is not “expected” there.)

4 Likes
9

Oh, and I noticed that cycleway=shoulder actually is documented in the wiki, seems that I overlooked it the first time. I added some of the info from this thread to the wiki article.

2 Likes
10

Hi, at this point, what are the preferred tags to map a shoulder that practially all cyclists use but isn’t strictly marked as a cylce lane? I’m currently improving cycleway data on Ma-12 in Mallorca between Can Picaford and Playa de Muro (Street View link) . Currently, it’s a mix of cycleway:both=lane, cycleway:both=shoulder and shoulder:access:bycicle=yes. I would eradicate shoulder:access:bycicle as it’s a very niche, undocumented tag (494 usages in total) in favor of the documented cycleway:both=shoulder (many thousands of usages).

3 Likes
11

I would tag shoulders:both=yes (and maybe an additional cycleway:both:shoulder).
As far as I know, in spain cyclist have to use the shoulder if one is prensent, so with shoulders=* already everything is said.

In Germany I use cycleway=shoulder only in cases where the markings of the the shoulder is clearly show that they are also meant as cyclelane. (eg. dashed lines here: Google Maps)
In Germany cyclist are allowed but not forced to use the right shoulder.

P.S Link to google maps because mapillary seems to block my ip.