For some picnic tables (1772369726 and 1779578673), I got the following question from StreetComplete: “Is this covered (protected from rain)?”, for which the answer must be “Yes” or “No”. This adds a covered attribute.
In the present case, there is some kind of protection, but not sufficient for the rain: there are wooden planks with small spaces between them. I suppose that the goal is to protect from the sun (while allowing some light), but not from the rain (or in a limited way).
The Key:covered documentation is not explicit about the specific protection from the rain, so I’m not sure what the value should be. Since this is available, I’ve manually added covered=partial, together with a description attribute. Is there a better solution?
I’ve also noticed Key:weather_protection, and I’m wondering whether this should be used instead (but this is not what StreetComplete uses). The value pergola seems to be what is the closest to the above case.
=partial should be interpreted as a filled, ungapped cover partly over the facility. This should not be used. weather_protection= was informally proposed, but not used as often for some reason. I don’t know why, while I use it. Tag:leisure=outdoor_seating - OpenStreetMap Wiki
If covered means protected from rain. then it’s not covered. Since I don’t expect picnic tables to be covered, I would not add a “covered”-tag at all, and I would simply not answer this SC-question. And I wish that all mappers refrain from answering questions resulting in =no tags, unless =yes is to be expected and =no is the exception.
You may of course decide that it is not worth your time and effort to explicitly tag details you assume to be defaults, but adding *=no is definitely useful for things that are not universal, and I would not assume that a picnic table specifically is always uncovered.
That’s what I thought. Until I encountered more and more lists of =no tags set by SC-users without them even knowing it. Such as simple crossings of a footway on an unclassified, which don’t need any tags at all, tagged with
highway=crossing
crossing=unmarked
crossing:markings=no
crossing:signals=no
tactile_paving=no
crossing:island=no
and then discovered that SC does this nonono-tagging with a gazillion of objects, just to keep track of which questions have been answered.
These are not universal. For example I can think of simple crossings of residential streets that are tactile_paving=yes but markings=no, and others that are vice versa. A signalized crossing can also be markings=no. Meanwhile crossing=* has been skunked, so crossing=unmarked does not obviate the need for markings=no.
I was talking about locations where the intersection of the two ways is the only thing there. Still, SC-mappers think it’s useful to add a list of no-attributes. For data users, this adds no value. It’s a workflow thing.
If OSM wants to treat explicit no’s different than absence of the attribute, there should be a generic mechanism for that, so that data users, mappers and tools can tap into that for their workflows. Not willy nilly no-values in the tag data.
There is - many tags have defaults, but the problem is that it is a bit of a minefield, and varies between regions, even within individual countries.
Any binary property in OSM can have three values, “yes”, “no”, and “don’t know”. Data consumers can make assumptions for missing data (assuming “no” for bicycle access on a motorway, for example, or “yes” for motor vehicle access on a many other roads), but these assumptions all have exceptions.
How do you suggest that mappers record the fact that “common access value for highway X is as expected” to avoid asking the question again and again and again?
This is not the case. It is useful to know “It has been confirmed that there is no tactile paving here” vs “The safest assumption we can make based on the limited information available is that there may not be tactile paving here.”
There is a mechanism for that - adding the *=no tag!