most `cycleway=opposite*` not understood

[westnordost]

It looks like some cycleway=opposite* tagging is not understood. This is the "old" method how to tag cycleways that have cyclist contraflow in oneway streets, but it is (still) used a lot and will likely never completely go away.

The table below assumes a country with right-hand traffic. Note that the sides flip if oneway=-1 and if it is in a country with left-hand traffic.

input	current output	expected output	comment
``` oneway=yes cycleway=opposite_lane ```	``` oneway=yes cycleway:left=lane cycleway:left:oneway=-1 ```	```diff oneway=yes cycleway:left=lane cycleway:left:oneway=-1 + oneway:bicycle=no ```	The tag can be inferred from `cycleway=opposite*`
``` oneway=yes cycleway=opposite ```	Conversion Error: unsupported: 'cycleway=opposite without oneway=yes oneway:bicycle=no'	```diff oneway=yes + cycleway:left=no + oneway:bicycle=no ```	It is not an error if they are not tagged explicitly as these can be unambiguously be inferred from `cycleway=opposite*`
``` oneway=yes cycleway=opposite_track ```	(nothing?)	```diff + oneway=yes + cycleway:left=track + cycleway:left:oneway=-1 + oneway:bicycle=no ```
``` oneway=yes cycleway=opposite_share_busway ```	(nothing?)	```diff + oneway=yes + cycleway:left=share_busway + cycleway:left:oneway=-1 + oneway:bicycle=no ```	That cycleway tagging refers to a busway that is itself not tagged can be considered incomplete / erronous tagging, however, that's not the point

Note: Follow-up of this ticket would be to consider it invalid/ambiguos tagging if the cycleway=opposite* tagging contradicts with other tagging, e.g. cycleway=opposite + oneway=no or cycleway=opposite + oneway=yes + oneway:bicycle=yes or cycleway=opposite_lane + oneway=yes + cycleway:left=track etc.

[droogmic]

Note that the sides flip if oneway=-1 xor if it is in a country with left-hand traffic

right?

[westnordost]

Yes

[droogmic]

@dabreegster

for cycleway=opposite, I am led to believe that this is a single shared "lane" for which travel is designated to motor vehicles in the forward direction, but access is permitted to bicycles in both directions.

This would require a change in the spec for access to optionally encode direction. Do you agree?

[droogmic]

The alternative: is what we do today: https://github.com/a-b-street/osm2lanes/blob/main/osm2lanes/src/transform/tags_to_lanes/modes/bicycle.rs#L138-L142 create a virtual backward lane for bicycles, with no lane marking separation.

[droogmic]

same question to you @westnordost, what do you think is the most "correct" output?

[westnordost]

Not sure if I understand what you mean with "output". To me it sounds like whether this is interpreted as

1. virtual backward lane for bicycles, with no lane marking separation
2. or as a single shared "lane" for which travel is designated to motor vehicles in the forward direction, but access is permitted to bicycles in both directions

is rather about osm2lanes internal representation than output. And on that matter, I am not in a position to give advice.

Just to be clear: oneway=yes + cycleway=opposite equals oneway=yes + cycleway=no + oneway:bicycle=no. So, no special treatment is necessary for cycleway=opposite but generally for the situation where cycling is allowed in the contraflow direction.

[dabreegster]

for cycleway=opposite, I am led to believe that this is a single shared "lane" for which travel is designated to motor vehicles in the forward direction, but access is permitted to bicycles in both directions. This would require a change in the spec for access to optionally encode direction. Do you agree?

Let me check my understanding. It's one physical lane. In the forwards direction, vehicles and cycles share the lane. In the backwards direction, cycles are allowed to go, but there's no space dedicated to them. Correct?

The virtual lane option is to have a backwards lane of zero, or maybe very thin (I've seen contraflow markings in London for this situation, but they don't mark out a lane), and the user has to understand what very narrow lanes means in their use case.

The alternative is just output one lane, but make direction become per vehicle type?

Based on the use case, this situation probably triggers some edge cases -- in rendering, how to show contraflow markings on the big lane. In routing, likely a penalty for the backwards direction (just due to lack of dedicated space -- in my limited observation, these seem to get placed on low-traffic streets and are fine to use in practice). In simulation, handling for very narrow lane or shared space, similar to a bidirectional lane, but where only one vehicle type can use one direction. From thinking quickly through these, I think the second option (direction per access type) feels more consistent.

[westnordost]

Let me check my understanding. It's one physical lane. In the forwards direction, vehicles and cycles share the lane. In the backwards direction, cycles are allowed to go, but there's no space dedicated to them. Correct?

Usually a oneway road that allows cyclists in contraflow direction (but has no explicit cycle lanes) has no lane markings at all.

Though, it is not uncommon that additionally to the "oneway except for cyclists" sign, there are bicycle pictograms along the street to remind other road users that they should expect cyclists in contraflow direction. As far as I know, these pictograms are both optional and have no legal implication (i.e. a sign is necessary in any case).

[droogmic]

https://github.com/a-b-street/osm2lanes/pull/193