I created Key:building:name - OpenStreetMap Wiki where I describe it as unwanted and not needed and bad mapping.
Is there any case where it is useful or is it something clearly unwanted and fine to be marked as status=deprecated ?
6 Likes
Just saying Iāve only ever added a ānameā for buildings that has one with addr:housename IIRC. Donāt remember if itās rendered and at what zoom, so will check in a momentā¦ so checked one I knew was tagged with addr:housename and it renders fine
Good point, added " addr:housename=* can and should be used if building name is part of the address"
(though I would not use āis it renderingā check too stronglyā¦)
I agree building:name is bad mapping, it only would make sense if you had a building and another thing mapped to the same OpenStreetMap object, which is not desirable at least if you are going to add additional information that applies only to some. In this case you should rather have distinct objects in OpenStreetMap
5 Likes
I support the idea of marking building:name=* as deprecated.
1 Like
In the US there are buildings that have names independent of their current use or occupants. For example, the Flat Iron Building. Many of the smaller towns and cities will also have some buildings with names that are independent of their current occupants and street address. And the names are used in giving directions, etc.
If we cannot use building:name=* for those what tagging should we use?
2 Likes
Tag used in cases where POI such as shop or museum and building were mapped as one object despite being two different objects, even with different names (violating One feature, one OSM element). In such cases this objects should be rather mapped as two separate objects.
In general, offices/shops/museums in a building and building should be mapped as separate objects. Especially if both have separate names. And where there are multiple POIs in one building, or when POI takes space only of single floor etc.
See One feature, one OSM element - OpenStreetMap Wiki
See Way: āŖFlatiron Buildingā¬ (āŖ264768896ā¬) | OpenStreetMap for building and Node: āŖT-Mobileā¬ (āŖ10177726834ā¬) | OpenStreetMap for likely one of many POIs there.
5 Likes
building:name sounds bad indeed if it can be replaced with addr:housename or simple name. On building polygon and not on amenity one of course :d
4 Likes
There are many buildings having a specific name which is not part of the official adress (like the Flat Iron Building in NYC) which can be tagged by simply adding name=* to the building (+1 to @jimkats ) which is consistent to the use of the ānameā tag for hundreds of other objects.
My support for the deprecation of building:name.
4 Likes
If building:name is depreciated/unwanted how should I map the following:
- Many scout groups are the only users of their scout hall so there is no reason to have a "club=scoutā node separate from the building
- A good number of scout group halls have a well established nickname
Since the polygon is a club=scout and name=Scout Group name, where can I write the name of the scout hall. addr:housename sounds wrong since this is usually not an official name. But I donāt see an obvious alternative. Hereās the guidance Iām trying to write: Tag:club=scout - OpenStreetMap Wiki
1 Like
I would consider fact that building and club being different things to be a good reason to not map both as one object.
Sky will not fall if you map both of them as one object but it does make things worse.
And avoiding building:name is already a good reason here, no need to make editing and processing OSM data harder.
4 Likes
I would consider fact that building and club being different things to be a good reason to not map both as one object
yes, and you do not have to use a node for the club to separate them, you can also have 2 overlapping polygons.
1 Like
In situations where the whole building is occupied by one business itās common to add the shop=* or amenity=* to the building way. In that case name=* is for the shop/business name and building:name=* would be needed to set the building name (since addr:housename=* only applies where its part of addressing, which isnāt always the case). This is common practice.
I agree that the building and the shop are different things and should have different objects in OSM, that provides a clear separation for which tags apply to the building and which to the shop/business and then the regular name=* tag can be used.
However we canāt do that yet, editor support is simply not there.
In iD try drawing a new area over an existing building area and mark it as a cafe, iD will just merge the tags and merge the ways into one.
Weād either need changes to the OSM data model (API v7?) or editors to be able to better handle different ways with the same nodes, to represent the building and occupaants as different objects.
A node for the shop/amenity inside the building wonāt tell you that the whole building is occupied by the shop.
If you insist on areas you can do multipolygons.
Still easier to wrangle then terrible prefixes.
And nodes may lose a bit of info, but are still superior over terrible building: prefixes that are
- confusing to mappers
- obnoxious to data consumers
- not supported by data consumers, with rare exceptions
- without support in editors
- against OSM data model
4 Likes
I do not see this behavior in iD, I can draw an area over a building just fine. If I select cafe from the search bar, it does add building=yes to the new area automatically (as in, there would be two overlapping buildings), but I can delete the building tag from the new area and itās perfectly happy to allow an overlapping area.
Sorry youāre right, I thought they were being merged, but itās just that iD added the building=yes tag automatically as part of the cafe preset. iD doesnāt make it easy to see that there are two different ways here with different tags, nor is it easy to cycle through the two. In JOSM I can middle click to cycle through each, but in iD if Iām lucky I can move the mouse to get a different selection, but with 3 different objects itās impossible to select each of them.
A multipolygon relation? I guess you could, that way you just have one way, and the shop/business could be a relation. It does make it a lot more complex, and I can see new mappers continually making a mess of things done like this.
1 Like
can you even distinguish the multipolygon in iD from stacked ways? Last time I used iD it handled multipolygons transparently
Thereās a residential street here with just 1 civic number, and the 3 apartment buildings lining it having a tag at their main entrances as Palazzo A, B, C. Often these streets have a sign at the front too with Condominium XYZ, I just slap the names on the entrance points, but see no problem if the buildings themselves get to carry the designation tags, albeit, āPalazzoā is a pretty generic reference to a condominial building or apartment block.
it is definitely more complex than building area + POI node, but more editable and usable than building: prefixes
