Please avoid "no" values

[NKAmapper]

I am not a user of StreetComplete, but I have noticed that StreetComplete is adding thousands of non-existing features in my country, i.e. tags with a "no" or "none" value.

Examples:

• https://www.openstreetmap.org/node/6373443058
• https://www.openstreetmap.org/way/850248073

Please stop doing that. Of course "no" is a permitted value in OSM, but it does not make sense to tag all things in the world which do not exist in a given place. After all, we are not tagging oneway=no everywhere, even though it is probably correct for most roads.

And please do not respond that adding all these "no" values provide more useful information than if not including them. I am sure that in a few cases, a conscious decision for example to add sidewalk=none to make a difficult routing situation explicit is ok. The problem at hand, however, is that StreetComplete is adding thousands of "no" values in a mechanical way so that users may move on with the next task.

If StreetComplete is dependent on a "no" value in OSM to be able to know which tasks have been checked, then I think instead you need to have a separate database which is tracking progress. OSM cannot be flooded with useless tags just because it is convenient for an app.

[BalooUriza]

On Thu, Jul 7, 2022 at 12:00 AM NKA @.***> wrote:

I am not a user of StreetComplete, but I have noticed that StreetComplete is adding thousands of non-existing features in my country, i.e. tags with a "no" or "none" value.

Examples:

• https://www.openstreetmap.org/node/6373443058
• https://www.openstreetmap.org/way/850248073

Please stop doing that. Of course "no" is a permitted value in OSM, but it does not make sense to tag all things in the world which do not exist in a given place. After all, we are not tagging oneway=no everywhere, even though it is probably correct for most roads.

And please do not respond that adding all these "no" values provide more useful information than if not including them. I am sure that in a few cases, a conscious decision for example to add sidewalk=none to make a difficult routing situation explicit is ok. The problem at hand, however, is that StreetComplete is adding thousands of "no" values in a mechanical way so that users may move on with the next task.

You may want to be aware that StreetComplete is used by actually observing the situation on the ground. Pedestrian routing is, in general, pretty bad across most platforms due to the lack of specific information; and tends to be better in platforms that use OSM due to it. For this information, I ask that you consider that it is being done in good faith by a person on the ground, and if that is in question, try messaging the user directly first.

If you're trying to monitor an area for bad faith edits using something like OsmCha, it can be useful to filter out users who are making a good faith attempt by flagging them as trusted; you can always change your mind on that later.

Message ID: @.***>

[legofahrrad]

See FAQ: https://wiki.openstreetmap.org/wiki/StreetComplete/FAQ#Why_does_StreetComplete_often_tag_the_absence_of_features?

[matkoniecz]

After all, we are not tagging oneway=no everywhere

Well , StreetComplete is not doing it everywhere, and limits it to places where one-way appears to be likely.

If StreetComplete is dependent on a "no" value in OSM to be able to know which tasks have been checked

It is

then I think instead you need to have a separate database which is tracking progress. OSM cannot be flooded with useless tags just because it is convenient for an app

The question here is whether this tags are useless enough to consider StreetComplete edits as negative in general.

Note that at least some such negative tags were in extremely wide use at intended to be added to every single way which does not qualify for normal tags, with filtering wider than StreetComplete is using (name and oneway tags see also Vespucci and JOSM).

Some people shared your opinion, some not and it depends on tags.

StreetComplete will be definitely not shut down based on a single complaint.

---

Note also that quests where answers would be spammy and visually obvious then questions are disabled.

[matkoniecz]

Closing, as definitely too wide and for example for road names and name noname tags StreetComplete is not more aggressive than what JOSM and Vespucci and Osmose and now defunct missing name later had for a long time.

Many quests which were actually leading to pointless tagging were disabled already in specific areas.

Also, https://wiki.openstreetmap.org/wiki/StreetComplete/FAQ#Why_does_StreetComplete_often_tag_the_absence_of_features

Not entirely sure what would be needed to disable quests which are considered as useful by SC authors (single complaint is definitely not enough, DWG blocking users for using SC and answering questions correctly resulting in not needed tags would definitely trigger changes).

But first, please read FAQ and report specific quests being problematic in specific areas.

[NKAmapper]

@matkoniecz Please do not simply shut down this discussion. I have been asked by several members in my local community to address this problem here on Github. This is an honest attempt of making an improvement, and I would like to have a serious discussion about this issue. I simply think there must be better ways for StreetComplete to handle "no" values than just adding a tag in OSM. The issue is general because I think the root of the problem is a general one, namely how StreetComplete in general handles non-existing features.

When expecting the flow of changesets from StreetComplete, it is clear that the mechanical "no" values by far outnumber real/positive values from the app. So the primary function of StreetComplete is currently to add information about features which do not exist into OSM. I believe this was not the original intention of StreetComplete, and it sadly undermines the otherwise good idea behind this project. If this practice continues, it seems to me that the app will keep adding tags until all remaining highways in OSM have been tagged cyclway:both=no.

When I have asked StreetComplete users, they say that they enter the "no" value because otherwise the task will keep appearing in the app, which I think is not a very good reason for adding tags in OSM. I think this is the root of the problem. My thoughts: If users could be less encouraged to add "no" by the app, and if still tasks would not reappear in the app even without a "no" tag, then I think this problem would be fixed.

If you need more specific cases, here is a list of the top problems I have seen in terms of volume:

• cyclway:both=no
• sidewalk=none
• bin=no
• shelter=no
• bench=no
• crossing:island=no

[HolgerJeromin]

With cycleway:both=no sidewalk=none shelter=no bench=no I see a big value to have them in osm. They can optimize routing or trip planing.

[matkoniecz]

they say that they enter the "no" value because otherwise the task will keep appearing in the app

Yes, user is expected to answer questions, also where contribution to OSM is something like "this place was surveyed and it turns out that it has no sidewalk"

This is useful, as otherwise it is not possible to distinguish "not surveyed" from "surveyed, feature not present".

Note that for some tags this is widely accepted, for some cases it would be clearly not wanted, and for some it is controversial

I have been asked by several members in my local community to address this problem here on Github

Can you link this discussion? Sorry if I missed link if posted already

mechanical "no" values

Edits in StreetComplete are manual, if someone is running bot edit not based on survey, pretending to be StreetComplete matter then they should be banned immediately.

Please do not simply shut down this discussion.

Note that issue is closed but discussion is not locked (that is a separate tool)

[NKAmapper]

This is useful, as otherwise it is not possible to distinguish "not surveyed" from "surveyed, feature not present".

I understand this thinking, of course. The problem is that this approach does not make sense on a large scale. OSM would then have a lot more tags about features which does not exist than about features which are in fact on the ground. This is already happening in the areas where StreetComplete is popular. For several tags, we now have in a short time more "no" values than positive values in our local community, even after many years of tagging positive values.

Can you link this discussion?

Here is one discussion: https://forum.openstreetmap.org/viewtopic.php?id=75557 Also other discussions on IRC in the local community and in changesets.

mechanical "no" values

I call them mechanical because users are clearly accepting the "no" values due to how the options are presented in the app, and to avoid having the task pop up again for the same object. No users added all these "no" values before StreetComplete became popular here (which is something to reflect on).

What I propose is for the app to not encourage adding "no" values, and for a different, internal mechanism to keep a log of objects already checked.

[Helium314]

When expecting the flow of changesets from StreetComplete, it is clear that the mechanical "no" values by far outnumber real/positive values from the app

I honestly doubt that. For myself, more than 70% of answered quests are about surfaces, buildings and whether ways are lit. In my area lit=yes far outnumbers lit=no (actually making "yes" the "spammy default"), and the other quests do not have a "no" answer. Thus in my case there are actually less "no" than "real/positive" values (nowhere near "no" values by far outnumber real/positive values).

it does not make sense to tag all things in the world which do not exist in a given place

Note that StreetComplete does not "tag all things in the world". Please keep it to things that are actually happening.

Is there an actual problem with things like wheelchair=no? Not simply personal taste things like "I don't like that many tags".

[matkoniecz]

does not make sense on a large scale. OSM would then have a lot more tags about features which does not exist than about features which are in fact on the ground

Personally, I do not consider it as a problem at all.

Obviously, is community consensus would be different then it would not really matter

https://forum.openstreetmap.org/viewtopic.php?id=75557

Thanks, I will look into it after I get back from a trip Edit: given info below this is not necessary at all, but I responded there while waiting in the queue

[eginhard]

I understand this thinking, of course. The problem is that this approach does not make sense on a large scale. OSM would then have a lot more tags about features which does not exist than about features which are in fact on the ground. This is already happening in the areas where StreetComplete is popular. For several tags, we now have in a short time more "no" values than positive values in our local community, even after many years of tagging positive values.

But what exactly would be the problem with that? Note that StreetComplete only adds no values where this is useful information, it is not adding oneway=no to every street. It is also not the case that no is always a sensible default value when a tag is missing.

Here is one discussion: forum.openstreetmap.org/viewtopic.php?id=75557

You seem to be the only one there who doesn't like tags added by StreetComplete, others explicitly disagree and point out how that information is useful.

What I propose is for the app to not encourage adding "no" values, and for a different, internal mechanism to keep a log of objects already checked.

I never understood this argument. Isn't the aim of OSM to have a common, open database? Why should we encourage such fragmentation?

[NKAmapper]

I honestly doubt that.

I guess the StreetComplete project itself has the best statistics, but a few examples for bus stop tagging in Norway:

• bin=no: 1255, bin=yes: 931
• tactile_paving=no: 1882, tactile_paving=yes: 780
• bench=no: 2284, bench=yes: 1869

Then consider that many of the "yes" values have been entered without StreetComplete, while "no" values hardly were mapped before/without StreetComplete.

You seem to be the only one there who doesn't like tags added by StreetComplete.

No, there is a balanced discussion, even from the users who are defending all their negative values, including a suggestion to raise the issue here.

[Cj-Malone]

• bin=no: 1255, bin=yes: 931

• tactile_paving=no: 1882, tactile_paving=yes: 780

• bench=no: 2284, bench=yes: 1869

• bin=no: 1255, bin=yes: 931, no idea: 85,417
• tactile_paving=no: 1882, tactile_paving=yes: 780, no idea: 84,879
• bench=no: 2284, bench=yes: 1869, no idea: 83,388

I added counts for the ones we have no idea about.

[matkoniecz]

Either, way given how StreetComplete is designed it relies on saving "no" values, which is done this way as it is treated as useful info.

In case of clear consensus that it is unacceptable something would need to be done, but it is not such situation.

@statistics - while interesting, please discuss it elsewhere (discussions tab? Diary entry?). Note that disagreement depends on how the same thing is defined (at least three variants were present)

Note that in case of large volume of not needed offtopic discussion this specific issue will be locked.

[mnalis]

What I propose is for the app to not encourage adding "no" values, and for a different, internal mechanism to keep a log of objects already checked.

But "no" is not there as a answer "just to not ask the user that question again" as it seems to be implied. SC has separate mechanism (other answers / hide) to facilitate that. "no" is there because it as useful answer as "yes", maybe even more - depending on the quest. (for example, lit=no to avoid places at night in high-crime areas, or when planing bicycle routes to make sure to only use such areas during day etc.)

I guess the StreetComplete project itself has the best statistics, but a few examples for bus stop tagging in Norway

As for the statistics (on which I won't dwell in detail to avoid locking the thread), I'd just note that (to me) the examples that @NKAmapper provided are if fact great example why both "yes" and "no" answers are equally useful, as they are used about same order of magnitude times. Because, when neither is mapped (and there is no default, which is the case here - proven by numbers), it means "situation is unknown" (as mentioned by others). And if we find that information (tactile_paving / bench / bin etc.) useful at all, then "unknown" is the only situation we do not want and wish to avoid.

Now, I could easily see the @NKAmapper point if one of the values was highly predominant (e.g. 99% "no" answers, and 1% "yes" answers. In such a situation, it would be prudent to document the default, and don't ask the quest at all (in that specific country or worldwide, depending). If fact Quest guidelines already requires that (in "No spam" rule). But that would apply equally well if the situation was reversed (e.g. 1% "no" and 99% "yes" answers, i.e. when "yes" might be assumed a default: like for example lit=yes on highway=motorway - in that case, lit=yes is the worthless tag, and lit=no is the valuable one).

But such disproportion in answers does not seem to be the case in provided examples, which means that neither state might be assumed by default when key is missing - thus for example bench=yes and bench=no are equally useful on bus/train stops. Now, someone might think that bench=* or amenity=bench are useless tags altogether, and they are entitled to their opinion, but I would disagree. And if we agree that bench=* is useful, then mapping it is there (where it otherwise might be assumed not to be) is as useful as mapping that it is not there (where it otherwise might be assumed to be there - as on a bus station for example)

So the primary function of StreetComplete is currently to add information about features which do not exist into OSM. [...] If this practice continues, it seems to me that the app will keep adding tags until all remaining highways in OSM have been tagged cyclway:both=no.

This fear however does not seem to have a hold in reality. The code (I've highlighted important part) is here: https://github.com/streetcomplete/StreetComplete/blob/v45.0/app/src/main/java/de/westnordost/streetcomplete/quests/cycleway/AddCycleway.kt#L332-L356

So it is far cry from "until all remaining highways in OSM have been tagged cycleway:both=no". If fact, StreetComplete will ask that question only on small subset of highways, where it is likely that the default of "no" is not the case, so only asking in places where giving answer to that quest would provide very useful cyclist routing information (regardless which answer is given, including "no").

Now, if the @NKAmapper or others would like to suggest even better filter (which would either reduce or expand the number of highways where it is reasonable to ask that as it often deviates from default), I'm sure that would be quite welcome! (Or to improve filter of any other quest, of course)

[Gazer75]

This fear however does not seem to have a hold in reality. The code (I've highlighted important part) is here: https://github.com/streetcomplete/StreetComplete/blob/v45.0/app/src/main/java/de/westnordost/streetcomplete/quests/cycleway/AddCycleway.kt#L332-L356

You're checking roads with speeds greater than 30? That makes no sense to me. Roads at 40 and below are most likely to have lanes.

[FloEdelmann]

Only residential roads with maxspeed greater than 30km/h. For other road types, this specific condition is not required. See the reasoning here: https://github.com/streetcomplete/StreetComplete/issues/2251#issuecomment-723866344

[Gazer75]

Pretty sure you could exclude any road with a speed limit of 50 or greater as well. At least 60+ is not going to have these lanes.

Taginfo shows over 93% of cycleway:both=no

You might as well just select all roads in Norway and apply this to them. 99.99% sure the cycle lanes on roads are already tagged as they exist only in the bigger cities and towns.

[mnalis]

@Gazer75 note that this quest is not only about bicycle lanes. It is also about cycle tracks (and other cycling infrastructure values) which are very much present on roads with higher speeds (like for example physically separated cycling tracks on highway=primary roads with maxspeed=110 km/h in my country).

It is also quite common here that roads with maxspeed=50 (or default HR:urban, which was 60 km/h until recently) have bicycle lanes (e.g. https://www.openstreetmap.org/way/882179726).

Now, it might be an improvement for SC to only offer subset of cycleway answers (i.e. only tracks, not lanes) if maxspeed>60, but that would needs a lot of research how cycling infrastructure is implemented in various countries (because what is true for my country might not be true for others), and benefit to end user would not be very much (they would still be asked the quest on all that roads, they would just be offered smaller set of answers to choose from - and if they're answering honestly which one would hope, there would be no difference in what data would end up in OSM)

[Gazer75]

What you call cycle track is basically a separate foot- and cycleway which would be mapped with its own highway=cycleway. Pretty sure the track value is not a thing in Norway. So we also have to tag all roads with this with cycleway:*=separate or something like that? This just affirm my view that this is tagging bloat.

[mnalis]

What you call cycle track is basically a separate foot- and cycleway which would be mapped with its own highway=cycleway

Yes. The same way as sidewalk=* might instead be mapped as separate highway=footway. Both methods are used and preferred by OSM community for various reasons. This is discussed at wiki https://wiki.openstreetmap.org/wiki/Bicycle and many other places; and is not specific to StreetComplete, so there is not much point in discussing it in StreetComplete issue tracker. You may want to read those pages and their Talk:* subpages for more background.

Also, SC does not ask this quest on roads where separately mapped cycleway exists (see https://github.com/streetcomplete/StreetComplete/blob/v45.0/app/src/main/java/de/westnordost/streetcomplete/quests/cycleway/AddCycleway.kt#L358-L361)

Pretty sure the track value is not a thing in Norway.

Per-country specific StreetComplete quest is probably not realistic due to maintenance load. (one could still fork and modify their own StreetComplete cycleway quest if they feel it would benefit them - I do so for example).

What could be done in upstream SC though, IF the whole Norway community feels that they would be better served by NOT having the cycleway quest enabled there, is that cycleway quest could be disabled in Norway. So you can start discussion on their mailing list (or whatever), and link the discussion here where enough time has passed and there is clear consensus what the overwhelming majority of Norwegians want. Several other quests have been disabled that way in some countries by clear community consensus.

This just affirm my view that this is tagging bloat.

My view differs, but hey, it is only human (I also find many other tags in OSM useless but still it is clear that some people find them useful, so I leave them alone and filter out / learn to ignore stuff I don't care about). But if (after reading mentioned pages and linked resources) you still think you have some new information which might lead to different consensus on *=no values in OSM community, feel free to bring it up on tagging mailing list, as the issue is much bigger that StreetComplete (and StreetComplete is only following accepted and documented mapping practices here).

[Helium314]

Pretty sure the track value is not a thing in Norway

It's very easy to check that you're wrong here. This value is used in Norway.

So we also have to tag all roads with this with cycleway:*=separate or something like that? This just affirm my view that this is tagging bloat.

Note that this issue is explicitly about no, not other values like separate.

[Gazer75]

It's very easy to check that you're wrong here. This value is used in Norway.

Checked a few and they should have been lane, not track as they were part of the street. Just painted line and red pavement. Suspect some are tagged wrong.

We do apparently have some "track" after checking with some on IRC

[Helium314]

Anyway, I think adjusting element selection for the cycleway quest should go into a separate issue. Especially because I would estimate this has a higher chance of being implemented than not tagging "no".

[BalooUriza]

Freeways in the far western US are typically bicycle=yes, foot=yes, with some having bike lanes (and Bend Parkway having bike lanes and sidewalks). I wouldn't be so quick to rule out situations that only come up when features for nonmotorists is a total afterthought.

On Sun, Jul 10, 2022 at 4:15 AM Gazer75 @.***> wrote:

Pretty sure you could exclude any road with a speed limit of 50 or greater as well. At least 60+ is not gonna see these lanes.

— Reply to this email directly, view it on GitHub https://github.com/streetcomplete/StreetComplete/issues/4191#issuecomment-1179689672, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWDFBVMAWU27PG3FY22FO3VTKIBVANCNFSM5237W24Q . You are receiving this because you commented.Message ID: @.***>

[Gazer75]

That is just weird. Its like they just repurposed the shoulder. Did not expect that at all.

Any highway=trunk in Norway defaults to foot=yes and bicycle=yes. Its specifically tagged no and/or with motorroad=yes if not.

[BalooUriza]

On Thu, Jul 7, 2022 at 6:08 AM Gazer75 @.***> wrote:

Any silly tagging like this will be considered vandalism and reported as such and deleted by me for sure.

I'm pretty sure this actually violates the OSM code of conduct.