Map the absence of a value

General talk Tagging general discussion
1

There’s no standard way to map the absence of a value. A few different ad-hoc ways are in use:

Especially for question-based editors like MapComplete, this would be useful: it would allow questions to be answered with “no value” so they aren’t asked again, instead of everyone having to skip the question (and potentially someone filling in gibberish).

Should we standardise a way to map the absence of a value? What should this scheme look like?

3 Likes
2

IMHO not, every case should be considered individually, we should not have a standard way to tag the absence of something, because it would invite some to clutter the map with *:*=no tags

1 Like
3

In hindsight, it would be nice if the raw XML data model could distinguish between a key being unset and a key being set explicitly to “no value”. Technically, that’s what v="" could mean, but in practice, most tools would strip out tags with that value.

To my surprise, there are only two elements in the whole database that use the has:*=* namespace, but not to indicate whether the feature has a particular taggable attribute. Instead, has:slurpee=yes looks like it could be replaced by sells=* or something in that namespace, probably without frustrating the mapper who wanted to promote OSM’s coverage of Slurpee vendors in a goofy post on on social media.

In theory, the has:*=* namespace could unify the various existing tags, as in has:name=no, has:ref=no, has:addr:housenumber=no, has:maxspeed=no, and has:brand=no.[1] However, some of these tags are very entrenched in OSM. A coordinated mass edit would be necessary; otherwise, the old and new tags could easily contradict each other.

Another wrinkle is that maxspeed=none is part of a scheme that also includes maxweight=none and other (absences of) restrictions. There are a few instances of maxweight=none per se, but a lot more usage of none as a value inside maxweight:conditional=* and other conditional variants. Splitting out a dedicated namespace sounds great until it comes time to express these conditionals, where the none value sometimes has to override some other value.

  1. Translating nonsquare=yes is left as an exercise to the reader. ↩︎

4 Likes
4

I read somewhere (maybe in the StreetComplete or EveryDoor GitHub, I don’t remember) someone suggesting to use the check_date prefix to indicate it, e.g. check_date:website=* without website=* would mean that someone tried to find a website and couldn’t find one in that date. I see we have 716 elements in the database mapped that way (no idea if as an error or intended): overpass turbo

2 Likes
5

I’m not convinced that this is a good idea given that question based editors are always desperate to find new stuff to ask, but for completeness sake: we used to have the validate:* hierarchy. validate:noname being the most common value.

In any case we do in general have a lack of meta data on individual tag elements. The other main use case is that there is no last modified date for tags and as a consequence no way to indicate that a tag has stayed the same vs. a tag hasn’t been checked/surveyed, outside of using check_date:* There’s a suggestion of mine on that topic on one of the mailing list a couple of years back.

Free form tagging tends to be the nemesis of any such proposal though (reserving the value no would seem to be a particularly bad idea, at least none is slightly less likely to conflict with actual values).

6

not:*= is “not” something, which may be something else. I see no:*= can be interpreted as no-anything of that there. It would be extending other no*=yes format-wise.