[Tagging] noaddress=yes and (possibly) implicit buildings

[Matija Nalis]

On Sun, 17 Jan 2021 10:41:24 -0500, Alan Mackie <aamackie at gmail.com> wrote:
> On Sun, 17 Jan 2021 at 10:14, Tobias Zwick <osm at westnordost.de> wrote:
>> The discussion has been revolving around earthquakes in Croatia mostly,

Thanks Tobias, talk has indeed mostly converged on only one half of the question
posted (so far). I'll try in this subthread to help focus on SC case exclusively.

>> Is this still about the proposal to let StreetComplete...
>>
>> 1. ask its users for the housenumber of every building=yes (worldwide)
>> 2. tag noaddress=yes on a building if it has none (cause it is a
>>     shed or whatnot)
>> (3. remove noaddress=yes if/when that building is later tagged to be a
>>     type of building that usually has no address (like a shed or whatnot)
>>     via the app)

Thanks Alan,

> I see 2. as being potentially problematic. In some places addresses are
> not always displayed even when they exist, and even the ones on display can
> be in poor condition or obscured by foliage temporarily.  A StreetCompleter
> would not be able to answer this question definitively. They could only say
> if they can see one or not right now.


Actually, in StreetComplete case (as opposed to the "drone photos + official
address registry" case) the mapper IS on the ground and sees (in majority of
the cases) what is there. 

The mapper does care very much about addresses (as s/he considers it very
important part of map, eg. for navigation), but however does NOT care much
about specific building types (and/or they don't like to provide possibly
FALSE information, see [A] for more details).

Hence, they would see on the ground that there is no address on the building, 
AND they would see that it is very unlikely such type of building would have 
address anyway, so they'd opt to map it as "noaddress=yes".

Later, another mapper with local knowledge might (or might not) come by and
mark it as "building=shed" (s/he knows for it fact because it is his/her
friends house for example), which would remove "noaddress=yes" as redundant.

If there were "building=some_generic_type_that_does_not_usually_have_address" 
which implied "noaddress=yes", that would certainly be an welcome
alternative to just using "building=yes" + "noaddress=yes", but I'm not aware 
of such value being used/documented (maybe we could invent new one like 
"building=non_living" or similar which might fill this role? but probably
with a better name)

Or, if 100% certainty (does such even exist in life, much less in OSM?) was 
an absolute requirement for "noaddress=yes", then value "noaddress=probably"
or something similar might be considered as an option?

> 1. could get tedious very quickly in areas with many separate garages sheds
> etc., I presume this is why the address query is normally suppressed until
> after building type ID in the first place.

It would be choice for user - while the default in SC currently is to map
firstly building type and (some time later) the address; the user which
wanted to focus only on important tags might want to reverse that order 
(or even to skip building type quest altogether).

[A] There are multiple problems and reasons why person might not want to map
    explicit building type via "building" key: it might not be easy or
    possible to know what was original purpose of the building was:  
    Was it originally built as a hangar, or a garage, or a shed or a
    warehouse?

    Even the much easier to answer "building:use" key is often hard to get
    right; many a "garage" has been converted to "shed" and vice versa.  
    Or it might be mixed of multiple subtypes.  

    Or they could just consider it a less of priority (or a complete waste
    of time), while still considering the fact that the building does not
    have an address important enough to record.  

    Or they might be frustrated from experience that the tag is very often
    incorrectly used (eg. "building=house" even for "building=apartments", or
    "building=shop" instead of "building:use=shop" etc.) and do not see it
    being possible to fix.

    (Or any of hundreds of other reasons, I'm sure)


-- 
Opinions above are GNU-copylefted.