Recent versions of StreetComplete now ask for cycle lane information on roads tagged cycleway=opposite as well as the ones where it is missing. I am finding that the tag has been used both for cycle signage without lane markings (which StreetComplete changes to oneway:bicycle=no) and for cycle lanes separated by dashes (cycleway:right=lane cycleway:right:lane=advisory cycleway:right:oneway=-1). I am currently looking for the tag with a saved query overpass turbo to survey which is which on the ground.
Iām not exactly an Overpass QL wizard, but would it be more efficient limited to {{bbox}}
? Itās returning a lot of data. Not sure if using regexes for keys makes it better or worse, however.
/*
* Find ways with deprecated cycleway*=opposite* tags
*/
[out:json][timeout:60];
// gather results
way[~"^cycleway(:left|:right|:both)?$"~"^opposite"]({{bbox}});
// print results
out geom;
Using this just now, it looks like iD makes some unusual choices during edits:
- Rather unexpectedly suggesting
cycleway:both=no
forcycleway=opposite
- Surprisingly choosing
cycleway:right=separate
for its Standard Bike Lane option (youād assume=lane
, right? Perhaps itās just if thereās a standard pedestrian sidewalk nearby)
I wish iD would switch off some of these āupgradesā by default, as far too many of these have the effect of saying: āHey inexperienced user, would you like to make this āerrorā go away? Donāt worry about what it means, you can just trash the existing tagging and itāll take ages before anyone notices what youāve broken.ā
4 Likes