cycleway=no is not helpful about streetcomplete HOT 15 CLOSED

if no cycleway is tagged it usually means there is no cycleway

Well, there is no way really that the latter can be inferred from the former.

If no cycleway-related tags exists, it might alternatively mean that nobody got around to tagging cycleway there. Just with any other tag - OSM problem is that is there no way to know what "missing tag" means:

• it might mean that nobody has gotten around (or didn't care enough, or didn't have enough time, or whatever) to mapping that tag yet (in which case it is important that mappers go there and map missing infrastructure), or
• it might mean it has value of some default for that tag for that region, and people didn't tag it as they thought there is no need to tag implied defaults

Since there is no way to know which one is the case, and there is a world of difference for data consumers and mapper alike between "unsurveyed state of cycleways in the area" and "carefully surveyed area with many cycleway values which happen to be the default most popular one", there is a need to differentiate those somehow.

What would be alternative to tagging cycleway:both=no to make that very important distinguishment? Tagging instead cycleway:both=default (with "default" values being specified somewhere else) or tagging check_date:cycleway:both=2024-03-07 without specifying cycleway:both=*? IMHO, that would produce the same (or higher) amount of "bloat", would me much harder to tag, parse and use, more likely to break (e.g. someone removing check_date:* bloat) and would be overall much less useful.

One should also note that this conundrum applies not just to no values like cycleway:both=no; but for any "implied default" value. E.g. one might equally well argue that there is no point (and that it is bloat) in tagging lit=yes in most advanced cities in western countries, as it will be assumed default in overwhelming number of cases and that only unusual exceptions of lit=no in some cul-de-sacs should be tagged; or that there is no point in tagging surface=asphalt on highway=residential as that should be assumed default in those cities.

However, for some other place, implied defaults (i.e. the values that should not be tagged to avoid "bloat") might actually be lit=no and surface=compacted.

But even if the issue of "what is the default for some tag for some specific region" could somehow be solved (and there were discussed solutions for that problem in the past; but none which were general enough really caught on, and few that had, like maxheight=default or camp_site=standard or default_language=*, brought their own set set of problems), the much bigger problem remains: that the OSM has no way to differentiate the reason WHY some tag is missing and that is crucial piece of information -- because, unless we have guarantee that 100% of planet is always mapped in all details (in which case we mappers are no longer needed at all, eh?), there is significant chance that the value is not tagged NOT because "its value is default implied no", but because nobody got to mapping that level of detail yet.

And all-round easiest way out of that conundrum is by explicitly tagging values which might be "implied default" - even if that means little more database usage (which should not be confused with "bloat").

from streetcomplete.

What about tagging covered=no?

Sure, I tag covered=no where I think it is useful. As do mappers of those other 816k+ uses... In fact, it is more popular than covered=yes. Perhaps there is some reason for those usages, wouldn't you agree?

oneway=no if we‘re sure from survey,

Again, StreetComplete will tag that too, as do I. And there are some ~4.5 million uses which also seems to imply that other people care about that too. And it does not look its exclusively due to StreetComplete; in fact that history line seems to have about the same upward trend nowadays as it had before StreetComplete even existed.

But I get it - You don't seem to agree about usefulness of those no tags, and that's fine too, just ignore them. Alleged "bloat" does not really harm you directly, does it? And it helps others.

For example, I don't care at all about at least 90%+ of the other OSM tags either. Yet I don't call for removing them all from the database, even if they are completely useless to me, do make my downloads somewhat bigger, and many of them are not very well though out, and even more are not neatly put in right namespaces etc.

Any tag you like is a central tenet to OSM, is it not? If so wide range of people think those tags/values are useful to them, who are you or I to contradict them and call those tags useless and demand that they should only tag what we would prefer? Especially as we don't get almost any benefit if they do submit to our bidding (apart from somewhat smaller download sizes)!

That would not seem like reasonable demand to me. There should always be some sort of pro/contra cost analyses, yes? What are the gains of implementing such idea, and what are the losses? I see a lot of losses, and no real gains (again, apart from somewhat smaller download size, which is really hardly worth mentioning as some "benefit").

negative attributes because there is an infinite number of properties that could be there but aren’t.

StreetComplete does try to ask and tag them only on places where it makes sense as one might otherwise expect the thing to exists, though. See e.g. the filter in the code given above for when it is asked and tagged for cycleways, or this one for oneway=no.

It is in fact one of central tenets of StreetComplete not to be spammy. It even mentions the oneway example you pulled out, i.e.:

💤 No spam: It must be possible to determine whether the quest should reasonably be asked. A quest which is to be answered in 99% of the time with the same answer is not a good quest, don't bore the users. I.e. asking for any road if it is a one-way road, is silly, because the vast majority of all roads will not be one-ways.

But if you do have ideas for their improvement when such quests are asked (i.e. making quest filters more restrictive), please do open other issues specific to such quest improvements. If those suggestions result in less spam to the users while not loosing their usefulness in cases where they do provide benefit to OSM data, such ideas would be very welcome!

That's about it; I'm out of arguments. If those so far managed to at least somewhat convince you that those no tags might be sometimes useful for some people, or even in cases when they perhaps fail to be very useful to you they're at least not harmful, that would made my day! If not, well, that's life and it's fine too; in any case, let it not be said I didn't try my best 😺

Anyway, if you think that oneway=no, covered=no, cycleway*=no etc. should be discouraged/forbidden/whatever, you should really take it with wider community on forum, tagging ML and/or proposal, as that is not really StreetComplete-specific issue -- if use use those no values is found so detrimental by the OSM community that it significantly outweighs their usefulness to the point their use should be discouraged/forbidden; then other editors like Vespucci, iD, JOSM etc. should be forbidden to tag them either, right?

If you do decide to start community discussion about that, please do however post a link here linking to them, so interested parties can follow; thanks! ❤️

from streetcomplete.

it would bloat the objects so that essential information is not easily visible any more

"bloat" is a very common and in my opinion really unhelpful line of argumentation. I remember that guy who was removing house numbers because they would bloat the map. There are people urging users to stop creating low priority notes because it would bloat their list of recent notes, making it hard to find essential ones.
Is it really hard to find e.g. old_ref here when someone would add cycleway:both=no?

In my opinon most of the complaints that "essential" information is not visible are due to choice of tools.
E.g. when I enable my "everything" custom overlay in SCEE, things look bloated because of boundaries and landuses. The trick here is to hide those, even when I think I want to see "everything".

Further, what is considered essential varies heavily by user.

unlikely that new cycleways aren't mapped

In my area, "proper" cycleways are well mapped, while lanes that are just painted on the road are not (thus not tagged and no is very different in what you can expect to find).

In other areas I know there are no cycleways/lanes at all, and the quest is rather useless there.
But if it's clear enough that no is just the case for the whole area, then we need to provide this information so a data consumer (who doesn't know the regional situation of all regions worldwide) can actually use it.

only add explicit "no" values [...]

Why actually only no? In a western city one would expect streets to be lit (much more than 90%) and possibly have a more than 90% predictable surface (which may depend on the city), so you could reduce the perceived bloat by switching what not tagged means depending on the key.

properties that are expected to appear at least about 10-20% of times in the given context

Could you clarify the "given context"? Is SC (and any data cosumer) expected to magically know, or is there some wiki page or other source providing the necessary data?

E.g. in my area, all post boxes are signed as being emptied at 16:00, except the ones at post office entrances, so SC would only need to ask near post offices (to avoid "bloating" post boxes with information that is clear in the given context).
But: I actually don't know the boundaries of this area Even if I did, I don't provide this information to data consumers.

from streetcomplete.

and if there is, it will be mapped.

I suspect that this claim that all cycleway infrastructure in Italy (?) is mapped already is not exactly accurate.

from streetcomplete.

In case you are not aware of this, if the quest is spammy in your region (because you feel that pretty much everywhere where it is asked, the answer is "no"), you can disable it in the settings.

from streetcomplete.

Also, this quest is disabled by default: https://github.com/streetcomplete/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/quests/cycleway/AddCycleway.kt#L35

So just not enabling it and not using cycleway overlay is enough to be not asked it.

Though it seems that @dieterdreist is unhappy about others using it.

from streetcomplete.

Very well-written write-up, thank you @mnalis! I should bookmark this, this topic comes up time and again in OpenStreetMap and your post explains very well why StreetComplete tags values considered as defaults in some places (or why it makes sense generally). Maybe link it from the StreetComplete FAQ?

I'll close this as question answered / will not fix.

from streetcomplete.

But even if the issue of "what is the default for some tag for some specific region" could somehow be solved

It's off topic, but actually that would already be really useful.
Having some nicely accessible/parsable data set of default values by region, similar to the default access values. I'm specifically thinking about public holidays, working days, U-turn restrictions, speed limits, weight limits, height restrictions, right turn on red, ...

from streetcomplete.

that’s why I wrote to you. I agree tagging oneway=no occasionally can make sense, just as cycleway=no, systematically less so.

Well some time ago you might've had some point there. How old are those changesets that you are looking at? Can you provide few examples? Are we even sure they are using Cycleway Quest (and not Cycleway Overlay)?

Because, nowadays, they are not being asked systematically Cycleway Quest? As it has already been pointed, this quest is disabled by default, and one has to go to settings and try to manually enable it, and then a warning pops up, and then the user needs to confirm that warning to even get the quest to show up at all (much less to start adding answers, of which some might be cycleway:*=no).

And if they are using Cycleway Overlay, than it was never systematic in the first place, and is as explicit and as intentional and as manual as it can be in any editor (Vespucci, iD, JOSM...)

Any tag can make sense if someone chooses to put it,

well, the procedure above seems to me like someone really wanted to do it, as they really had to go out of their way to enable that quest. (That is assuming recent StreetComplete versions, it that was some times in the past the quest was enabled by default IIRC). Or that they manually & intentionally use Overlay to add exactly that tagging. Anyway:

• If that was done using older SC version, the issue has probably already solved itself automatically by now, and nothing needs to be done
• If that is latest SC, but only few individuals, perhaps you should comment on their changesets and try to persuade them that they should not be doing that.
• if it is a lot of individuals using Cycleway Quest in latest StreetComplete, then something looks suspicious - If they go out of their way to enable that quest and tag such cycleway, perhaps they have a reason? You could try contacting a few and getting those reasons, and bringing it up with Italian community -- and if those reasons are deemed invalid by Italian community consensus, there is an option of disabling that Cycleway Quest in Italy completely (especially as you say "what doesn’t make so much sense is asking people with an app to do it systematically for very unlikely properties (like cycleway in Italy)") (users would still be able to continue to use "non-systematic fully-manual maximally-intentional Cycleway Overlay" to update cycleway infrastructure in Italy.
• it would be nice to get feedback from those users why are the doing that (if using Quest in recent SC). Perhaps a warning text when enabling quest might be customized/improved? Or (if they are using Overlay), why are they explicitly selecting some streets and forcing such an answer to them?

what doesn’t make so much sense is asking people with an app to do it systematically for very unlikely properties (like cycleway in Italy),

I don't want to come out as insulting by posting the link to quest selection filter for the third time, but did you perhaps have time to look at it? Could you suggest how the filter could be improved to produce less Quests in cases where it doesn't make sense to ask them (i.e. making it less systematic and more specifically targeted)? Such filter should make sense globally, though (while theoretically possible, we can't easily tune it per-country, and it would likely be maintenance nightmare).

But I'd suggest finding answers to questions above first (because, if the problematic changesets are not produced using the recent StreetComplete Quest to tag those cycleway:*=no, then there is no need to waste time on looking how to improve the Quest which was maybe not a problem in the first place 😃)

Also globally it is much less likely to find cycleinfrastructure than to see a oneway. It seems 99% of the cases this will be negative, just in your quote. https://taginfo.openstreetmap.org/tags/highway=residential#combinations

Well:

• As noted earlier, cycleway quest filter is already much more complex than just asking the quest on all highway=residential. IOW, it doesn't show "all highway=residential" at all. So showing taginfo for whole of highway=residential is not really relevant to Cycleway Quest in StreetComplete...

• when comparing, one should take into account that oneways in OSM are currently mapped much more than cycleways, possibly because there are much more car-centric mappers then bicycle-centric mappers.

  For example, in my city, while I very rarely (few times a year at most) I find road which still misses oneway=yes tag, every day I map I find several residential streets where cycleway*=yes infrastructure is not mapped! That would indicate (roughly) that cycling infrastructure over here gets about 200-500x less attention then car infrastructure. IOW, if oneway got same attention as cycleway does here, there would be significantly less than 0.1% of oneway=yes mapped in OSM (even if reality there is about 10% of them)

  As for the example in my city (far from universal I know, but I know it is at least somewhat mapped by StreetComplete by me) there are (on highway=residential) about 585 residential streets with cycleway* tags, of which 91 cycleways has some positive (i.e. not no) value. That is about some 16% - which is far call from <1%. And note that Zagreb is not particularly well known for its great cycling infrastructure (to the contrary, it is quite realistically 😢 often used as a negative example in that regard). Of course YMMV, and I grant you that you'll know situation in your city in Italy significantly better than me; I'm just trying to point out that claim that is spammy is very unlikely to be universal.

from streetcomplete.

from streetcomplete.

I find a good use case for cycleway:*=no is to explicitly show to other mappers that there isn't infrastructure where it might be otherwise expected. An example would be for a road that used to have lanes but now doesn't. I also map from city databases that are often outdated, and if someone else uses the same data, tagging 'no' could show that certain pieces of data are inaccurate.

I don't think there's anything wrong with the tag, but I do think it's best used judiciously.

from streetcomplete.

Updated SC FAQ: Why does StreetComplete often tag the absence of features?

from streetcomplete.

from streetcomplete.

And there is in general some balance between "this is bloat and pointless, tagging this is absurd" and "we should have comprehensive coverage and tag whether it was surveyed". It partially depends on how big problem is that some value is missing, how often it actually appears, personal preferences and so on.

Note that StreetComplete will ask whether playground has restricted access but will not ask that for every single road. And that oneway quest is restricted to cases where there are indicators that it can be oneway.

from streetcomplete.

from streetcomplete.