Id: Requesting preset for 'Storage Unit' business

[afonit]

In my region we have lots of storage unit businesses - I think it would be usefull to tag them as 'Storage Unit' Businesses.

[bhousel]

@kepta you were asking about this before:

• You can copy any of the other presets under the shop folder
• This one will be for shop=storage_rental
• Fields operator, address, building, opening_hours.
  Note: change building_area to building because these things are not necessarily located indoors.
• Name: "Storage Rental"

[ghost]

Please be aware that the tag you have chosen is explicitly rejected. This means the tagging community found that it was bad.

[bhousel]

@M1dgard, the tag is documented on the wiki and in use.

What tag do you suggest we should use instead?

[ghost]

I don't think there is a suitable tag yet. I don't know enough about these facilities to propose one. IMHO when something is rejected, it should not be promoted in editors though.

[bhousel]

Let me get this straight. The tagging community rejected a tag for storage businesses, but did not suggest an alternative, and left the tag on the wiki, both documented on its own page, and also linked to from the shop page, and left the data in the OSM.

Why should anybody pay attention to what this "tagging community" says? The process is so obviously broken that anybody participating in it should be embarrassed.

[d1g]

I don't think there is a suitable tag yet. I don't know enough about these facilities to propose one. IMHO when something is rejected, it should not be promoted in editors though.

@M1dgard yes but arguments "against it" make no sense:

• shop/amenity by Mateusz Konieczny (Nobody defined what exactly should be in amenity=*, how this key could be better for anything?)
• shop/non shop - by Foxxi59
• shop/amenity debate by Peter Mead

proposal

Latest voting resulted in 2 repeated arguments _against_, one comment, 3 approvals.

Definitely not widely a discussed feature, but if amenity=storage_rental was used, then proposal would succeed?

Proposals shouldn't use yes/no as synonym to Facebook/Twitter votes, but use arguments and counter-arguments.

In most cases you simply should vote yes, UNLESS there a clear problem with other tag usage or this tag was already defined and used in different way in database.

We could a garbage in database, agree on one proposal, then simply re-tag questionable objects.

We should minimize re-tagging and plan approved features better.

tagging

Both shop=* and amenity=* are insane in their definition.

If our users simply document tags AAA=yes "you can do AAA here and by AAA I mean ..." it would be better for everyone.

Arguments "tag it BBB=AAA, not ZZZ=AAA" makes no sense when BBB or ZZZ were never clearly defined.

A consistent tagging scheme would help, but please don't use absence of good tagging scheme as an argument to reject every third tag.

I don't see how this tag or object is problematic to OSM as whole. Bad decisions were made 10 years ago with amenity=* and leisure=* tags/keys. Now users waste everyone time fighting about key definitions (which were never stated in the first place).

[bhousel]

I don't see how this tag or object is problematic to OSM as whole.

@d1g: We are in agreement that it's not problematic. That's why we added a preset for it in 3f73696