Talk:Key:cycleway:lanes

cycleway:lanes vs bicycle:lanes aren't alternatives, but complementary tags

At this moment the wiki reads:

bicycle:lanes=* - specifies the access for cyclists on a per-lane basis, can be seen as an alternative to cycleway:lanes=*.

I would disagree with this statement, the tags are complementary, not alternatives for each other. `bicycle:lanes` specifies legal bicycle access per lane. On the other hand, `cycleway:lanes` specifies the infrastructure. Example: bicycle:lanes=no|designated|yes + `cycleway:lanes=none|lane|none means bicycles are legally allowed on 'lane' 2 and 3, but only lane 2 is a designated cycle lane, while lane 3 is (probably) just another regular lane (which may be accessible by cars etc. depending on other tags like `access:lanes`). This could for example occur in combination with a turn, e.g. where the rightmost lane is a turn to the right while lanes 1 and 2 are through lanes. --Famlam (talk) 13:28, 19 October 2024 (UTC)

Although I get your point, keep in mind that bicycle=designated means an infrastructure built specific to a mode and the only thing which falls under the description of a designated bicycle lane is, well, a bicycle lane i.e. cycleway=lane. In fact, I'd even argue that cycleway=* was invented during a time where the concept of per-lane access on OSM didn't exist back in the day. This can be seen by the existence of a few other tags such as cycleway=opposite (denotes exceptions to oneway=yes for cyclists, now deprecated in favour of oneway:bicycle=no), busway=lane (denotes the existence of bus lanes, in the process of getting deprecated due to lack of flexibility compared to bus:lanes=*) and cycleway=share_busway (permits cyclists on the bus lane, nowadays of the opinion that it's questionable and belongs to be deprecated because permitting cyclists on bus lanes still is a case of a relative lack of bicycle infrastructure).

The closest example where cycleway=* for cycle lanes has the upper hand is that you can specify it further with cycleway:lane:lanes=*. But even for that case, per-lane access is still implied by these tags and that use of cycleway=* might not exist if bicycle:lanes=* came first. For example, bicycle:lanes=no|no|designated + access:lanes=yes|yes|no implies cycleway:lanes=no|no|lane + cycleway:lane:lanes=no|no|exclusive (notice the order of the tags). Heck, motorcycles don't have a cycleway=* equivalent so the only way to tag exclusive and advisory motorcycle lanes is through *:lanes=*. That's why I claimed it can be seen as an alternative. Because I never used cycleway:lanes=* with bicycle:lanes=* before and still don't see a point in it.

In other words, if one tagging style adds nothing new, it isn't supplementary, it's redundant.

--ManuelB701 (talk) 17:13, 19 October 2024 (UTC)

By using implied tagging (e.g. bicycle:lanes=|designated| implies cycleway:lanes=|lane| or the other way around, similar to how cycleway=opposite_lane used to imply oneway:bicycle=no + cycleway:[otherside]=lane), you would for example exclude tagging of e.g. customer-only access (or similarly for private/employee-only access). E.g. bicycle:lanes=no|customers|yes + cycleway:lanes=|lane|. Probably these cases are rare, but valid. Hence I think it's important that these tags, to specify legal access and infrastructure respectively, remain separate. --Famlam (talk) 20:29, 19 October 2024 (UTC)

I've decided to remove this section but I still am not happy about this because it leaves out motorcycle lanes (how would you tag motorcycle lanes with customers?). Actually, this opens up an interesting topic: Is access:lanes even defined for values other than yes, no and designated. (variable is a special case because it was invented without a proposal but it nonetheless came about to be with the *:lanes=* extension). --ManuelB701 (talk) 10:31, 22 October 2024 (UTC)