I have recently converted two bicycle sheds in my city to areas for better visuals on the map. This is one of them:
I’m just wondering if it needs a building=* tag on it or not. It comes up as a suggested field in iD, so it might be useful but idk.
I would say it is not necessary, but it is also not wrong to add it. Worldwide, 53% of all bicycle_parking=shed have tagged a building=* too.
Ok, I won’t bother adding it, thanks for the quick reply!
if it is a shed building then I would definitely apply building=shed to it
if that is just roof I would apply building=roof
hard to imaging a shed that is not qualifying for building=
The parking shed has the tags
amenity=bicycle_parking + covered=yes + bicycle_parking=shed
which is already redundant information.
Adding another building=* would not make the tagging better imo.
Is such kind of bicycle shed really a building? yes roofs and sheds are in the building values but should we add the tag it if there are other options to tag the covering?
to me these look like buildings, light structures, ok. If I made a map, I would want to see that the area is occupied with a (eventually light) building, even if I am not interested in bicycle parking or other parking in this map.
This is surely legitimate but it does not need a building tag for it. bicycle_parking=shed implies the existance of this light structure so it is only a matter of rendering. There is not much doubt, that all these added building tags
are primarily used to enforce the rendering which we usually call “tagging for the renderer”.
grenzwertig für einen “Schuppen”
building=shed
Related to this - I’ve mapped (or updated) quite a few bus stop shelters (amenity=shelter + shelter_type=public_transport) and I noticed that many of them also have building=* tags.
In my own templates (pictured below) and presets, I now include building=roof on these because I have tagged some of the shelters (like this one) with more detailed building-related tags.
I do think amenity=shelter and building=roof on the same object is a bit redundant, but not harmful. (and the same for amenity=bicycle_parking + building=*)
Some building-related tags are implied by their feature tag, but specifying those details seems fine to me. Always open to better ideas.
Convention says building=roof gets a layer=1 in addition when over the ground, which then would turn it into a floating bus stop, like fuel station tags on service station roofs making certain QA checkers unhappy.
Roof is of course when open at least on 2 sides. The glass sides often do not last long over here, so really open all sides. 
I think it’s best to tag it as a building, which it definitely is. Then covered=yes + bicycle_parking=shed are redundant.
That’s fine with me, although no one would call one of this plastic shelters a “building” in real life … 
The same could be said about bicycle_parking=shed: amenity=bicycle_parking which is also tagged building=shed (of which there are 3.9 million) implies that it is bicycle parking shed, so bicycle_parking=shed (of which there are only 22k) might be called the redundant one.
No, that is not at all what is meant by that specific (and overused) phrase. The phrase “Tagging for the renderer” was historically unfortunately phrased, at it actually indicates a practice of mis-tagging for the renderer: Tagging for the renderer - OpenStreetMap Wiki
E.g. things like:
For example, if landuse=industrial shows up as a pink area on one of maps, and you have a flowerbed full of pink roses, then tagging your flowerbed as landuse=industrial would be incorrect and must be avoided.
On the other hand, adding tags which are correct and useful for some specific renderer (or for some router, or for some other data consumer) is actually useful and encouraged (and some might even argue it is the whole point of OSM existence).
Sure you can do that if you like, it’s fine with me as I have said already. Anyhow a building=shed is something different (according to the wiki page) than what is called here a bicycle parking shed.
My personal approach would be to tag such bicycle parking area as amenity=bicycle_parking + bicycle_parking=* (for the type of parking aid offered) + covered=yes. That’s it - nothing else is needed to describe this object and nothing else should be required to render it.
If for the sake of getting such objects rendered in carto mappers start to add tags like building=roof or ‘shed’ or simply ‘yes’ that’s fine but not my business. Call it as you like, I call it “tagging for the renderer”.
Far be it from me to try to dictate what you’ll call it; I just wanted to draw your attention that this particular phrase has completely different meaning for majority of OSM users (in case you weren’t aware of it). You can call it “inconceivable” if you like 
I think the point is that we might disagree on whether a bicycle_shed meets the definition of a building=shed. If not then it would be false tagging and if it’s just so that the object appears on the map then it would be mapping for the renderer. As you I also don’t see the redundancy as a problem in itself, just the question of whether it really is a building, especially a shed as described in the wiki.
That is a good point. There are bicycle sheds which are indeed building=shed, and there are bicycle sheds which are just building=roof, and there are (perhaps) bicycle sheds which are neither.
I usually prefer mapping enclosure type separately than actual parking in some cases, as that records more information. E.g. thing commonly called “bicycle shed” (walls + roof + place to park bicycles) can be tagged in several ways:
amenity=bicycle_parking + bicycle_parking=shed (or building or locker, maybe) (+ covered=yes – or covered=no, but then I probably wouldn’t really call it bicycle shed in the first place), or
building=shed (or building=roof if there are no walls; but then I probably wouldn’t call it bicycle shed in the first place) + amenity=bicycle_parking + bicycle_parking=stands (or bicycle_parking=safe_loops or bicycle_parking=ground or bicycle_parking=saddle_holder or whatever else is actual parking support for the bicycle
As the latter encodes more information (actual bicycle support), I’d usually prefer that.
Yet another alternative is to map building=* as separate polygon, and then add individual bicycle parkings inside (useful if there are multiple different supports inside same structure)
Absolutely agree. Overlapping (and even duplicate) tagging is not a problem, but false tagging definitely is.
