bicycle routing support for cycleway:left and cycleway:right tag

[ratrun]

BikeCommon Flag encoder should add support for the tags "cycleway:left" and "cycleway:right", see http://wiki.openstreetmap.org/wiki/Key:cycleway.

[karussell]

Do you mean this for oneway stuff or for changed priority due to the different safety?

[ratrun]

More important is support for the oneway stuff in order to avoid longer detours. If possible priority handling can also be implemented, although it is not easily possible to decide what to prefer for which kind of bike. E.g. a racebike rider probably will not like to go against a oneway.

[karussell]

Hmmh, the problem is that left and right is country dependent if we want to find out the oneway stuff, right?

[karussell]

Or is it identical to the :forward and :backward stuff? #205

[ratrun]

I think that the oneway aspect of this issue (values=opposite*) is identical to #205. After making some overpass queries I found out that the usage of #205 (bicycle:backward) is much more common compared to the cycleway:left or cycleway:right usage with "opposite". I cannot see any country dependent aspect. It does not matter if the car traffic runs on the left or on the right side.

Besides the oneway aspect of this issue there is the priority handling aspect, which eventually should be handled differently for every kind of bike. Here I see some relation with one of the aspects of #330, where the highway classification tag, if present, should have some influence on the priorisation. E.g. highway=primary together with some cycleway "lane, track ..." tag should not lead to increased preference, especially when comparing to an ordinary highway=residential or highway=unclassified without any cycleway. The same is true if the cycleway is running opposite to a oneway. We should not prefer such a cycleway. I quickly checked the code, I could not find any part where we are rating down the priority in these cases. I know people, which claim to have statistics, which say that these kind of cycleways are extremly dangerous for a cyclist. I believe that they might be right.

[karussell]

It does not matter if the car traffic runs on the left or on the right side.

Okay, my bad, so it is entirely dependent on the 'tagging direction'

I've fixed #205, will include bicycle:backward now and handle the prioritization after 0.4

[karussell]

Hmmh, according to the wiki the bicycle:backward has a different meaning.

[karussell]

Maybe you have some direct link with current wrong behaviour? (regarding access restriction)

BTW: The cycleway:left/right is not that rare (see here).

[ratrun]

In my last comment I meant that cycleway:left and cycleway:right with the value opposite* are rare, but not that the whole tag is rare. So actually I was quite wrong in my initial comment on this issue, where I meant the opposite stuff is more important compared to the priorisation.

With overpass turbo I found this example as testcase: http://www.openstreetmap.org/way/160978261 for a cycleway_left opposite_lane

and here is a graphhopper link:

https://graphhopper.com/maps/?point=48.896183%2C9.188351&point=48.893157%2C9.190096&vehicle=bike&elevation=true&layer=Lyrk

You are also completely right when you say that "bicycle:backward" is different to cycleway=opposite*. I was not aware of the strange "bicycle:backward=no" definition: "when a road has a oneway cycleway next to it that must be used, and a cyclelane in the other direction". So in the "no" case there should be an impact on the prioritisation in both directions, and ignore any oneway restriction in the common bicycle encoder. In the bicycle:backward="yes" case only the oneway restriction gets overruled.

[karussell]

Okay, thanks

I was not aware of the strange "bicycle:backward=no" definition

Yeah, super strange. But now implemented ;)
so if bicycle:backward is existent a possible oneway=true tag is ignored

[karussell]

Was this already implemented in some pull request @ratrun ? If not, do you intend to propose one? Otherwise I would postpone this issue ...

[ratrun]

The priority aspect of this issue is still open. I do not intend to make a pull request now, maybe I'll look at it in Winter. I believe that it will be not that easy to get consistent priority handling.

[karussell]

Ok, thanks! Postponing for now

[ghost]

Hi,
In the following example, the best route would be simply to take "Rue du Petit Barry", which is tagged as "oneway=yes" and "cycleway:left=opposite_lane":
https://graphhopper.com/maps/?point=43.544283%2C1.34619&point=43.541658%2C1.347107&vehicle=bike&weighting=fastest&elevation=true&use_miles=false&layer=OpenStreetMap

Regards
Sébastien

[ratrun]

Thanks for the reminder. I'm going to provide a simple PR without the priority aspect. The reason is that we are already accepting cycleway:oposite_lane currently without priority downgrade and it is reasonanable to hande cycleway:left and cycleway:right the same way.

[AllroadsNL]

ignored cycleway:left lane

situation

Still not fixed!
People use routing engine to test, control, because it is not fixed people try to fix it by setting wrong tags.

[ratrun]

There is a bug with bicycle:forward=use_sidepath, this is considered as one-way. I plan to provide a pull request for this.

[karussell]

Is this fixed now?

[ratrun]

Yes, I believe that this issue can be closed.