How to tag contraflow bike lanes on one-way streets?

I recently came across a cycleway tagging situation that closely resembles this scenario (wiki link):

Screenshot from 2023-07-26 14-41-52

In the above screenshot, the new style is compared with the older, less specific style. In the older style, the tag cycleway=opposite_lane is used. In the new style, the cycleway:left key is used to denote the position of the cycleway relative to the mixed-use lane.

When I entered these tags into iD, I noticed that the following drop-down menus were added to the Edit Feature menu:

With the tag cycleway:left=lane, iD interprets this as a “Standard Bike Lane.” If I select “Opposite Bike Lane” as pictured, iD edits the tag to be cycleway:left=opposite_lane.

My question is as follows: is the single tag cycleway:left=opposite_lane preferable over (or equivalent to) using cycleway:left=lane with cycleway:left:oneway=-1? I feel that combining cycleway:left=opposite_lane with cycleway:left:oneway=-1 would be redundant and potentially confusing.

This is a relatively niche case, but it feels that the OSM Wiki and iD editor defaults are at odds here. I understand that there is ongoing discussion regarding cycleway tagging, so there may not be a clear answer. Thanks in advance for your help!

I prefer this one (and only this, without any other tag). Using -1, in any case, seems more difficult to be understandable and also harder to maintain.

1 Like

cycleway=opposite_* has wrong semantics when used in cycleway:*= . cycleway:left=opposite_lane would mean the right side has a contra-flow bike lane opposite to the left, which makes no sense. The “opposite” refers to both the side and direction. It doesn’t mean “opposite” flow only. This should never be used.
oneway:bicycle=no would already indicate cycleway:left:oneway=-1 in most cases. Similar to how cycleway:right:oneway=yes is not always neccessary, unless you have two-way ones on a road.
Furthermore, the other preset’s name “contraflow bike lane” is also wrong and misleading. cycleway=opposite means bikes are allowed to travel in both directions but there is no bike lane. The description “A bike lane that travels in both directions on a one-way street” is even worse. It doesn’t mean one side is two-way.
https://github.com/openstreetmap/id-tagging-schema/blob/main/data/fields/cycleway.json needs to be improved.

2 Likes

I am in favour of the newer two-tag approach. I have always felt uncertain about the double meaning of the term “opposite”, but I used it in past.

1 Like

I have encountered an even more confusing situation I’d appreciate input on. In the screenshot below (iD) you can see West Franklin Street, which is oneway. There is a separated, contraflow bike lane on the left side of this street. However, there is one more complication: bicycles traveling on the road are expected to share only the left lane. You can see the “share the lane” arrow painted on the road in the center of this screenshot.


Even using the two-tag approach as discussed above, it is unclear to me what the value of cycleway:left=* should be. Surely there is a better way to describe this situation other than:

cycleway:left=separate;shared_lane
cycleway:left:oneway=-1;yes

Thanks in advance for your help.

That’s an interesting case. Suppose the contraflow lane was just painted on and not mapped separately. Then I would tag this as
oneway:bicycle=no
cycleway:left=lane
cycleway:left:oneway=-1
cycleway:right=shared_lane

The way I see it, “right” in cycleway:right doesn’t necessarily have to be “to the right of where the cars drive”. It can just be “to the right of the centre line”, in this case that is the line that divides normal (one-way) from contraflow traffic.

By the same logic your case could be tagged:
cycleway:left=separate
cycleway:left:oneway=-1
cycleway:right=shared_lane

It may look a bit odd but I don’t see why the same idea couldn’t be applied when the contraflow lane is mapped separately. You can always tag which lane bicycles are meant to ride in with lane tagging e.g.
bicycle:lanes=designated|yes (or designated|no depending on the jurisdiction)

That’s how I would do it, but I’m curious if others agree!

1 Like

It does though. This immediately fails if there is anything on the right side of the road. It will be inconsistent with other attributes viz sidewalk:*= .

lanes=2
sidewalk:both=separate
cycleway:left=separate
cycleway:right=no
cycleway:lanes=shared_lane|no
oneway:bicycle=yes
cycleway:left:oneway=-1

The cycleway:left:oneway=no overrides the oneway:bicycle=yes for the road on the cycleway:left= . But broadly speaking, it may not be necessary spatially. The cycleway:left=separate indicates it should be evaluated separately.
On a side note, I don’t know the difference between cycleway=no and cycleway=shared .

1 Like

This is a great idea, and I think would allow me to capture the nuance of the use of each lane. Bicycles can use the right lane, and are expected to if they are planning to take a right turn, but it’s the left lane that’s designated for them.

I think this is what I’ll go for. I’ll double-check the cycleway:lanes key vs. bicycle:lanes to make sure I’m using the one that pertains to the road itself. As you say, if a new separated cycleway were to be built on the right side, this tagging scheme would allow for that.