It would have been nice if the OP added this bit of information for context, but maybe post and bug report just coincidentally happened at the same time.
If I understand correctly, the ticket is complaining that StreetComplete automatically addsoneway:bicycle=no if you have a cycleway on the left side of the road - no matter if it’s separate or not. Where does it say anything about removing that?
While I can see the point of adding bicycle:oneway=no if there is bicycle traffic going in the opposite direction of the one way street, StreetComplete should not automatically do this if the cycleway that goes in the opposite direction is mapped separately.
There should be at least a question whether bicycles are allowed to ride against the flow on the carriageway as well. Automatically assuming they are, might be a valid choice in some countries, I don’t know, but it seems to be a risky thing to do without confirmation.
And to further answer a question by @westnordost from the bug report:
Basically, it comes down to how bicycle:oneway (=~ vehicle access restrictions) should be interpreted (in relation to cycleway=separate):
Should it always refer to the street as a whole (i.e. including potentially separately mapped cycleway) or
Should it refer to the whole street only if the cycleway situation is not mapped on a separate way?
Or in other words, should access restrictions refer to always streets as a whole or to individual OSM ways?
All access restrictions apply to the OSM way they are attributed to. If the cycleway is mapped with cycleway:left=track, then they apply to this track as well. If the cycleway is just “referenced” with cycleway:left=separate, then they don’t apply to this way, because it’s a separate OSM way.
Have you tried that? A way that has oneway:bicycle=no and then you answer “does have any cycleways: no”. Have you checked if that removes the oneway:bicycle=no?
Yes, I just tested it on oneway road. In such case there is “no cycling allowed in this direction” option.
On road that is not oneway for cars it would likely have no effect (as there is no special cycleway but bicycle traffic is not banned making oneway:bicycle=no pointless but matching reality and answer)
@Woazboat Anyway, I am happy to clarify the situation with StreetComplete since this is a new topic now:
StreetComplete currently removesoneway:bicycle=no if
the road is a oneway road
the user selected the “none, no cycling allowed in this direction” for the side of the road in contra-flow direction (i.e. left side for Germany)
For any other selection (such as “none, but cyclists may use road in both directions” or “bicycle lane”), it actually addsoneway:bicycle=yes at the moment. (Issue #4715 is about whether this should also be done for cycleway:*=separate)
There have been several misunderstandings about this in the past, maybe the cases you remember correcting wrong input stem from that time: Nowadays, a warning is displayed to the user if the road previously has been not-a-oneway but the user selects “none, no cycling allowed in this direction”. Additionally, a fat is displayed in the preview/illustration.
Here is how it looks like in the UI, you wrote you do not have Android / StreetComplete:
I tried this myself, but only sent this to @Mateusz_Konieczny in a private message as it would have been off topic in the other thread.
In its current state, SC does not “accidentally” delete bicycle:oneway=no. The actual dialog (Thanks, @westnordost for posting the screenies) is really well thought-through, even with a separate confirmation. If someone “accidentally” clicked “no cycling allowed in this direction”, it’s because they either didn’t read or did it on purpose.
Also note that there was a time when StreetComplete neither had this warning nor the illustration nor (I think) the bicycle pictogram with the arrow for the “none, but cyclists may use road in both directions” illustrations. Those clarifications and safeguards were added in response to various reports of mis-taggings by StreetComplete users.
Thank you for the clarification. It’s possible that the incorrect changes were made before the new safeguards. I didn’t look at the date too closely, just noticed that they were made with SC.
Here is how it looks like in the UI, you wrote you do not have Android / StreetComplete:
No, I do actually use StreetComplete regularly and quite like it. However I have never encountered this specific situation in StreetComplete where I would have seen these warnings.
Those clarifications and safeguards were added in response to various reports of mis-taggings by StreetComplete users.
is displayed in the preview/illustration.
