Warn about bicycle=use_sidepath with conflicting cycleway tags

[skyper]

cycleway=* together with bicycle=use_sidepath is only valid with cycleway=separate and cycleway:both=separate. Additionally cycleway:right/left=* together with bicycle:forward/backward=use_sidepath is only valid with cycleway:right/left=separate. See ​https://community.openstreetmap.org/t/widerspruchlich-getaggte-rad-und-fusswege/98297/5 and ​https://community.openstreetmap.org/t/widerspruchlich-getaggte-rad-und-fusswege/98297/9.

There might be some more combinations with oneway=yes.

[osm@…]

I hope this table is complete
cycleway (null) o.k.
cycleway(:both) separate o.k.
cycleway:left/right separate/separate o.k
cycleway:left/right no/separate o.k
cycleway:left/right separate/no o.k
cycleway:left/right no/(null) o.k
cycleway:left/right (null)/no o.k
cycleway:left/right separate/(null) o.k
cycleway:left/right (null)/separate o.k

cycleway(:both) !separate wrong
cycleway(:both) no wrong
cycleway:left/right separate/!separate wrong
cycleway:left/right !separate/separate wrong
cycleway:left/right !separate/no wrong
cycleway:left/right no/!separate wrong
cycleway:left/right no/no wrong
cycleway:left/right !separate/(null) wrong
cycleway:left/right (null)/!separate wrong

[GerdP]

Please clarify the description. I use bicycle=use_sidepath often and I see no need to add a tag like cycleway=separate. I agree that a combination like cycleway=both + bicycle=use_sidepath should produce a warning.

[anonymous]

the problem is not the presense or missing of the tag cycleway=separate.

use_sidepath is only to use with an separate mapped cycleway.

so any other value which is defining a cycleway (track/lane/shared/shared_lane/...) along the way without an separate geometry is wrong
also cycleway=no is wrong, because there have to be a separate way!

Have a look in my decision table. (null) stands for no cycleway tag present

[anonymous]

Same for foot=use_sidepath and sidewalk!=separate

[Famlam]

Probably good to exclude any highway that contains bicycle:conditional, bicycle:forward/backward/both_ways:conditional for this check.

There might be some more combinations with oneway=yes.

Be additionally aware of oneway:bicycle, oneway:conditional, oneway:bicycle:conditional in this case :)

[skyper]

Replying to GerdP:

Please clarify the description. I use bicycle=use_sidepath often and I see no need to add a tag like cycleway=separate. I agree that a combination like cycleway=both + bicycle=use_sidepath should produce a warning.

Hope the description is a bit better, now.

Replying to Famlam:

Probably good to exclude any highway that contains bicycle:conditional, bicycle:forward/backward/both_ways:conditional for this check.

I would expect cycleway:conditional or similar then.

There might be some more combinations with oneway=yes.

Be additionally aware of oneway:bicycle, oneway:conditional, oneway:bicycle:conditional in this case :)

Yes, I am aware of oneway:bicycle. For *:conditional again, I would expect all tags to carry the suffix.

[Famlam]

I would expect cycleway:conditional or similar then.

Cycleway refers to the infrastructure (except of the IMO bad cycleway=opposite* values, which combine physical infrastructure and bicycle access in one tag). But cycleway:conditional = lane @ (...) would imply that markings on the road appear and disappear depending on the condition being matched, which is pretty unlikely. It's more likely to find a traffic sign implying "bicycles are only welcome from this direction during daylight" or so (i.e. bicycle:backward:conditional=*).
But sure, excluding both bicycle(:optional_direction):conditional and cycleway(:optional_direction):conditional would also be fine I guess.

Yes, I am aware of oneway:bicycle. For *:conditional again, I would expect all tags to carry the suffix.

Regarding the suffix, what's wrong with this (made-up) example:
oneway=yes + oneway:bicycle:conditional = no @ (sunrise-sunset)? Adding oneway:bicycle=yes to this key would be redundant tagging.
Out of the 1477 oneway:bicycle:conditional=* on taginfo, only 61 contain oneway:bicycle=* whereas 1314 have oneway=*

[skyper]

I am only looking for a cycleway=* (except separate) together with bicycle=use_sidepath. I would guess all your examples do not have a bicycle[:backward/forward]=use_sidepath. Otherwise there is a problem with the tagging. But please, proof me wrong as I am happy about complex examples to minimize the false positives.

[Langläufer]

We are looking for something like this implemented as validator warning in JOSM
​https://overpass-turbo.eu/s/1uDt

[osm@…]

There should be a warning:
foot/bicycle=use_sidepath with sidewalk=no or cycleway=no because because it says that I have to use a path, which is not existing

An Error for:
foot/bicycle=use_sidepath with sidewalk=left/right/both or cycleway=track/lane/shared... because because there is an non separate foot or cycleway at the way but use_sidepath is blocking the complete way for routing.

use_sidepath should be only be used as a kind of softer access=no to force the router to use the separate sidepath instead the line for the road. This does not work if only one of two sidepaths is mapped separately!

[Famlam]

(As sidenote: I see that in the overpass by Langläufer, cycleway=no/none is also allowed in some cases.)

Just had a quick search in Germany.
​https://www.openstreetmap.org/way/426023874
bicycle:conditional=yes @ (width > 0.7)
bicycle=use_sidepath
Although not the case here, having a cycleway=lane (or side-variants of it) dedicated to bicycles that fulfill the condition would be 100% valid. But I agree it'll be rare. My suggestion to exclude conditionals is just to ensure that if they occur (now or in the future), a simple selector will avoid having them appear in the results, as the tagging would be valid.

(Just to be clear, I'm not opposing the rule)

[anonymous]

Replying to [Famlam]:
Your example ​https://www.openstreetmap.org/way/426023874 is not an issue, because there is no infrastructure (cycleway) defined.

The validation should only check if there is a conflict between use_sidepath and the tagging of the infrastructure (cycleway/sidewalk).

A Warning: cycleway says there is no infrastructure or
An Error: cycleway says there is infrastructure but it is NOT separately mapped

This validation is not complete but I do not see that it is wrong. (but you may show counterexample)

There are potentially more inconsistencies to find if you also check bicycle:forward/backward=use_sidepath and concerning cycleway:left/right:oneway. This may be implemented later because it is much more complicated and one have to concern also right/left hand traffic.

A conflict with bicycle:conditional may only occur if there is a separate cycle track and a cycle lane at the same time. But here we have to first think about how to model this this: e.g. cycleway:right = seperate;lane ?
If there are such constructions, we can exclude them from the validation.

[GerdP]

I think the suggested tests are okay and should be implemented with mapcss rules.

[Famlam]

Replying to anoniem:

Sorry, I tried to say that it would be completely fine tagging *in case* there was an actual lane on the road.

Although not the case here, having a cycleway=lane [...]

Better to avoid false positives from the beginning than to fix the check later. That's all I'm trying to say. I'd also be more than happy to see them in the mapcss rules.

Which would roughly correspond to what you say here:

A conflict with bicycle:conditional may only occur if there is a separate cycle track and a cycle lane at the same time. [...]

Which I guess would be cycleway:right=lane (because that's the physical thing on the highway, it overrules separate) + bicycle:forward=use_sidepath + bicycle:forward:conditional=yes @ (whatever condition allows you to use the lane)
But this is a bit offtopic

[skyper]

Well, some should already be warned about, see #17498 and trunk/resources/data/validator/combinations.mapcss?rev=18674#L1001​