cycleway:BACKWARD=opposite_lane

[dabreegster]

osm2lanes/osm2lanes/src/transform/tags_to_lanes/modes/bicycle.rs

Line 140 in df0e7bb

// cycleway:BACKWARD=opposite_lane

Most of Lyon breaks without this support, eg, https://www.openstreetmap.org/way/113485483. Reminder to self to add a test and start to work on this

[westnordost]

To put cycleway:forward and cycleway:backward into perspective. As of 2022-04-29,

• cycleway:<left/right/both> is used 1225214 times
• cycleway:<forward/backward> is used 332 times

That's 99.97% vs 0.03%

As far as I know, this tag is not documented. Software support for this is likely zero and it should be considered a tagging mistake. Half of current usages seemed to have been added in some kind of import and/or by a single user in April 2016, see taghistory.
It looks to me that it would be less effort to repair the current usages with the approved tags than to implement and write tests for letting osm2lanes correctly interpret these tags.

[droogmic]

Note, in our comments, code, and possibly logging we do use the terminology:

// cycleway:BACKWARD=opposite_lane

All caps means that it is left/right depending on the driving side.
We currently do not even check cycleway:backward

See: https://github.com/a-b-street/osm2lanes/blob/main/osm2lanes/src/transform/tags_to_lanes/modes/bicycle.rs#L95

[westnordost]

Ah, so it is an internal representation

[hungerburg]

Having studied a similar issue in #161, maybe this tagging scheme can be made to work with a simple change in code, when -- in RHT territory -- "cycleway:left=opposite_lane" was understood as a shorthand for "cycleway:left=lane + oneway:bicycle=no + cycleway:left:oneway=-1", in LHT territory the same with left swapped for right.

Technically, the value for "cycleway:*:oneway" will be "-1" if the oneway value is "yes" and it will be "yes", when the oneway has "-1".