The AddCycleway quest is very error prone

[map-per]

The AddCycleway quest (not the CyclewayOverlay) is very error prone. I review these changes in Munich and many edits are wrong. The main problems appear to be that users have a bad overview over the cycleways in the surrounding.

This leads to wrong mapping when cycleways are separate as well as inconsistent tagging along a road (e.g. alternating between exclusive and advisory)

I know that the AddCycleway quest is deactivated by default, but there are quite a few people who downloaded the app before the settings were changed or activated the quest manually.

Example OSMCha Filter for Munich: https://osmcha.org/changesets/159362188?aoi=d2cb3d4f-bfe0-4353-8e36-06e0f81d2e03

Possible Solutions

• Display the same cycleway visualization from the Cycleway overlay in the AddCycleway quest
• Remove the quest (it's already deactivated by default and the cycleway overlay is better)

[matkoniecz]

This leads to wrong mapping when cycleways are separate

as in. people mapping them as cycleway:*=track instead as marking them as already mapped?

[map-per]

Yes

[westnordost]

OSM is full of these incorrect double taggings (on road PLUS mapped separately) for cycle tracks, sidewalks and to a lesser extent parkings, and it is a mistake that is introduced all over the place regardless of editor used.
It is only the cycleway overlay in StreetComplete (and maybe some MapComplete theme) that reveals this issue.

Worse yet, my experience is that the majority of all places where the the tagging switches from on-road to as-separate-way are mapped incorrectly (i.e. missing the virtual "link" way), and there's not even anything we can do in StreetComplete to help fix these issue (as you can't edit geometry in SC).

That's an issue, right? The better and more precise visualizations and quality assurance tools we have, the more errors become apparent. I.e. if we didn't have these tools, our map would look so much more nice and complete! But, don't shoot the messenger.

Actually I would claim that it happens less with StreetComplete than with other editors, as one at least gets some visualization of what one is about to tag. I think I don't even have to claim that, but that may be a fact: StreetComplete offers the most elaborate visualization of input of cycleway data also for the quest.

Anyway, as per the stuff suggested:

1. adding an overlay-like visualization to the quest is not technically possible
2. removing the quest is out of the question. See the text above. Actually, I thought about enabling it again by default, along with the sidewalk quest.

[westnordost]

Anyway, what may somewhat reduce introduced mistakes could be to at least never ask again for the bicycle infrastructure and sidewalk when it has been mapped as separate.

I thought this is already the case, but looking at the code, it appears that this isn't being done, yet.
This would at least stop StreetComplete users who haven't read and/or understood the "separate" option to engage in an edit-war (without their knowing) of on-road-mapped vs separate-way-mapped cycleways+sidewalks.

[map-per]

OSM is full of these incorrect double taggings (on road PLUS mapped separately) for cycle tracks, sidewalks and to a lesser extent parkings, and it is a mistake that is introduced all over the place regardless of editor used.
It is only the cycleway overlay in StreetComplete (and maybe some MapComplete theme) that reveals this issue.

Actually I would claim that it happens less with StreetComplete than with other editors, as one at least gets some visualization of what one is about to tag. I think I don't even have to claim that, but that may be a fact: StreetComplete offers the most elaborate visualization of input of cycleway data also for the quest.

From my experience cycleway=* is either edited by people who know what they are doing (then the editor doesn't matter) or or with StreetComplete. If I see errors I usually check where the error comes form and most of the time cycleway=* errors come form StreetComplete users.

Worse yet, my experience is that the majority of all places where the the tagging switches from on-road to as-separate-way are mapped incorrectly (i.e. missing the virtual "link" way), and there's not even anything we can do in StreetComplete to help fix these issue (as you can't edit geometry in SC).

In Munich this is not a big issue, most links are mapped here.

Anyway, what may somewhat reduce introduced mistakes could be to at least never ask again for the bicycle infrastructure and sidewalk when it has been mapped as separate.

That's a good idea.

---

Another problem is that StreetComplete treats e.g. cycleway:right=lane as no data available. Only as soon as e.g. cycleway:right:lane=exclusive is present as well it is detected as a cycle lane. So StreetComplete completely disregards the existing data in such cases.

The overall problem I'm facing is that the cycleway=* data in Munich is pretty good, but StreetComplete edits mess it up on a regular basis. There are places that I, by now, had to fix several times.
I even started to add all no values as well as cycleway:<direction>:lane values myself, to prevent StreetCompleters from solving the quest wrong. But that only solves the problem for Munich.

---

To have some numbers, I analyzed the AddCycleway edits in Munich in the last three months (August - October) (OSMCha):

Out of 32 edits

• 17 were correct and added only no values
• 9 were correct and added non no values (e.g. lane or separate)
• 6 were wrong

So that's an error rate of 19% which is extremely high, especially for StreetCompletes standards.

[westnordost]

Okay, well, please excuse me when I maybe get a little defensive over suggestions to just delete the whole quest. You can't imagine how many hours I've poured into exactly this quest, over many iterations of feedback, to make it as easy and descriptive as possible as it is now. Including, that we have cycleway:<side>:lane=* (properly documented) at all as a now established standard to distinguish exclusive from advisory cycle lanes, pretty much came from the development on this quest, back then I was searching for which real world situations relate to which OSM taggings and noticed that this was simply missing.

To deem cycleway mapping as something too complex for the average Joe to contribute to and have it reserved for those who allegedly are more thorough because they proved that they took time to learn to use an editor with a somewhat higher barrier of entry is exactly the elitist craftmapper kind of thinking that keeps the public at large from contributing to OSM, and ultimately, I believe, would be the death of OSM when the map just gets ever more complex through ever more detail while the contributor count stays roughly same or even contracts. JOSM user count is stagnating since 14 years(!!) and shrinking, iD user count is stagnant since 7 years, yet, ever more detail and complexity is added. This is the very thing I want to combat with this app, to make editing OSM more accessible to the wider public.

The above was not meant as an attack against you. I just needed to get this off my heart, in general.

---

So, anyway, that's that, and that's the reason why deleting that quest is out of question. What is not out of question is to improve it. We can do that, and with your help, we can try to understand why those users who (probably consistently) answered the cycleway quest wrong, answered it wrong. For example, maybe the wording could be improved, or the order in which the options are displayed (e.g. always ensure that the "separate" option is always in view, without scrolling?).

So, the first step is to contact these mappers and explain the mistake and ask them (politely, in a survey-kind-of-way) why they chose that other option.

---

32 edits in 3 months,... doesn't sound like much though. This could as well have been done by a single user in a single hour, walking around his neighborhood. Maybe the whole topic can already be solved by instructing those who made the mistake how to do it correctly and that's that.
(In any case, I don't quite understand what you mean with no values. cycleway:<side>=no? I thought the issue was that no (or track) was mistakenly tagged when it should have been separate?)

---

Another problem is that StreetComplete treats e.g. cycleway:right=lane as no data available. Only as soon as e.g. cycleway:right:lane=exclusive is present as well it is detected as a cycle lane. So StreetComplete completely disregards the existing data in such cases.

This is of course deliberate. Why would this be a problem? The user is on site, he should be able to answer it just fine. If "unspecific lane" was somehow displayed in the form, I don't see how this would be helpful for the user to correctly choose between exclusive lane and advisory lane. To display an item like "unspecific bicycle lane" at all might already be confusing to users.

[matkoniecz]

6 were wrong

can you link them? Is it the same mapper or different ones?

[map-per]

To be clear: StreetCompleate is a great editor. I'm not here for StreetComplete bashing. I just opened an issue because one specific quest has a high error rate. It's a rare quest (e.g. just 32 times done in Munich in three months) but users make errors quite often (19%).

32 edits in 3 months,... doesn't sound like much though. This could as well have been done by a single user in a single hour, walking around his neighborhood. Maybe the whole topic can already be solved by instructing those who made the mistake how to do it correctly and that's that.

Sadly it's not that easy. I monitor SC cycleway edits in Munich since 2022 and regularly write users, but after a while new users come and make the same mistakes again.

(In any case, I don't quite understand what you mean with no values. cycleway:<side>=no?

Yes, I mean cycleway:<side>=no.

I thought the issue was that no (or track) was mistakenly tagged when it should have been separate?)

The issue is more general, it's not using separate, but also inconsistent tagging along a road (e.g. alternating between exclusive and advisory). IMO the problem appears to be that users don't have context information. They only see one road segment and not the adjacent ones.

Adding no when it should have been separate is not an issue though, edits that add no values are almost always correct.

can you link them? Is it the same mapper or different ones?

It's two mappers in August - October (and a third one in November, but that's outside of the analyzed time frame)

August - October:
https://www.openstreetmap.org/changeset/158531556
https://www.openstreetmap.org/changeset/157378997
https://www.openstreetmap.org/changeset/157137715
https://www.openstreetmap.org/changeset/157118376
https://www.openstreetmap.org/changeset/156266361
https://www.openstreetmap.org/changeset/156009143

November:
https://www.openstreetmap.org/changeset/158666542
https://www.openstreetmap.org/changeset/159362188

[westnordost]

I've also reordered the choices so that related items are next to each other and the separate option is very much at the top, together with "no".

[map-per]

Thanks! Let's hope it works, fingers crossed

[matkoniecz]

And please open issue if there are systematic issues with new version.

And write a pleasant message to users on their changeset comments, they may learn or reply in way indicating what is unclear. 'there is no cycleway' was put on top after similar investigation. What almost entirely fixed problem of mass creation of 'there is no cycleway here' notes.