The Wiki page Key:amenity - OpenStreetMap Wiki states that «As an area, e. g. amenity=pub. If the amenity shares a boundary with a building, both features may be mapped on a single area element.» (this sentence originally was written very badly and later fixed to the for it has now, but it’s not clear if the addition was in consensus of community discussion or not) but, to me, it seems this is in contrast with One feature, one OSM element - OpenStreetMap Wiki since the building and the retail or commercial activity that are done inside it should not be mixed. Mapping the amenity/shop/leisure on the same way of a building mixes tags and at a certain point something is wrong.
I used to think it was better to combine them - now, I stick to “building is just the building” and prefer a POI node, either in the building’s center or near its main entrance.
15 Likes
I’d like to also make some points about this thread since this was born from a discussion in the Italian community group.
This change has been discussed here Talk:Key:amenity - OpenStreetMap Wiki by @Mateusz_Konieczny and another user, but the discussion seemingly stayed on the wiki and it didn’t go outside.
With this said I would like to point out that the discussion states it was done in accordance with the building tag description and that in my opinion it would be more chaotic having two overlapping areas that an area and a node on the outline and an area.
Also personally the latter strategy is the one I prefer since it gives us the opportunity to tag the area where a function is done and a node, except in some cases, should be discouraged if an area tagging is possible and well defined.
For now since it seems to have made some chaos I’ll also add the Questioned template to the line on the wiki just to mark it and also hear more opinions about that line.
See one of my previous comments about this. There’s just too many downsides to tagging both amenity and building on a building way.
4 Likes
Also, since it seems like it wasn’t mentioned, another proposal that was proposed in the group is to tag an overlapping area for the amenity on the building, what do you also think of this?
And as a comment I fully agree that a POI may be better, but, since I can’t change every single building and amenity tagged on the same area, I was discussing about how to do this in a specific case and I found this last option kinda strange, while the POI on the way of the building was also one option I would use in other cases.
ugly and annoying to edit
in my experience drawing a bit smaller area inside or having both POI and building as multipolygons on a single way works better
still, two areas is better than building:name + name and similar silliness
2 Likes
Drawing a “bit smaller area” likely translates as “duplicating all nodes” (as in literally, create additional node objects with coords), which is IMHO worse than duplicating just the node references (overlapping ways), because these additional nodes add nothing to the “information stack”, their only advantage is easier selectability and maybe also being easier to spot than different objects (i.e. usability issues that could be handled in the editor UI and are not required to be dealt with on the database level).
I agree that having a node instead of an additional way (or a double tagged “building” + something else) is loosing information, so it should not be tolerated for “conversions” of already existing data, but can of course be done when you add something new (although it is inferior so should not be promoted as the “preferred way”).
I think the better alternatives to ambiguous (“mixed”) mapping is either a multipolygon or overlapping ways if you don’t like MPs, where the latter is IMHO more complicated to handle in the editors (because you have to know how to select something specific from stacked geometries).
I agree it is better in most cases to have separate building and POI geometry.
The reality is, there are very many buildings that have amenity|office|shop|... tags as well. This is not always wrong.
Of course there has been discussion about the best tagging already, for example here:
In that thread a lot of good arguments are given, so we don’t have to repeat them here again 
Now, we may discuss changing the recommendation on the wiki pages.
I would be in favour of discouraging mappers to add POI info to the building outline, and maybe encourage to slowly “disentangle” existing building/POIs. We could recommend to use a single node for a POI. If you know the actual geometry of the shop/amenity inside the building, you could consider using a closed way.
We should clarify that buildings with POI tags were a common way of tagging for a long time, and in some cases may still be OK, but point out why we think separate geometries could be better even in those rare cases.
What are the pages we should be looking at?
key:building, Buildings, Key:shop, Key:amenity …?
2 Likes
The way I see it depends on how much of the amenity is tied to the building: Is it the sole occupant of the building (like most supermarkets are) but if the amenity only makes up part of the building, use a node or (ideally) draw it as an area.
2 Likes
Except from some very specific cases most pois are better tagged as a separate object, and not to be combined with building tags. This is because combining them causes unintended and unwanted collisions with attribute tags like name= start_date= website= etc.
For example, a building can be started in 1900 and a poi in 2015. They have different start dates. This applies for all attribute tags that can apply to both.
Pois where I think it is ok is where the poi is the building like for example in historic=manor
7 Likes
For transparency, I replaced the unwieldy {{Questioned}} template with a link to Dual tagging, which I then expanded to summarize the contents and the controversy.
Since this practice is not limited to amenity-es, I will also add a similar link to Key:shop and Tag:man_made=works, which are also prone to dual-tagging.
2 Likes
I feel like this would be some rudimentary form of indoor mapping. As in, the new nodes represent the inner wall, which can be refined later.
This of course leads to the next question, do we tag amenity on the indoor:room? I don’t really have experience with indoor mapping.
Double tagging, as stated by many, brings some problems and I would argue that the building and the activity inside it (shop/amenity/whatever) are two different things: the building is a thing, the activity it’s another and have different tags, of cours,e but some could collide (as stated: name, start_date and more).
Yes, I think that way of tagging belongs in the past, we can go on and tend to separate buildings from POIs
I don’t think a multipolygon fo these cases is correct, since it still correlates things that are not correlate but they just share the location.
1 Like
like the user of a building and the building itself? Maybe I didn’t understand you correctly, are you arguing they are not related?
1 Like
They are partially, they share the same ground, but there could be multiple differences, first of all the operator could be different. Moreover, which tag should be on the multipolygon? The POI tags? The building one? I think a multipolygon it’s a bad idea (and a relation an unnecessary element for these cases).
3 Likes
The keyword here is could. On the contrary, there are many cases when the business represented by the POI is the owner and/or operator of the building, and has occupied it since forever). That is the case with many supermarkets (Lidl, for example, only operates bespoke-built shops in many markets), factories and hotels. Also, there are many cases when the business occupies several buildings on the same plot (resorts, large factories), and there is no clear “primary” location within it.
In such cases, I find it perfectly reasonable to tag the whole building or plot (landuse=retail or industrial) with amenity/shop/man_made as appropriate. Insisting on a single point element everywhere would be counterproductive.
The problem is that most of the time we can assume that those tags are the same, but we can’t be sure (except if you can access some data of sorts). So, the point come to this: we map them together not knowing what the effective reality is, or we map them separately just in case they do not share the same operator/owner (apart all everything stated before about other tags)?
My main observations on this are:
- Many buildings have more than one occupier. Locally, mappers have often included the ground-floor occupier as part of the building and occupiers on other storeys added as nodes.
- When you have lots of small shops on a street: OpenStreetMap and there is a mix-up, there can be a huge difficulty in sorting the mix-up if the building and amenity share the same object. If the amenities are separately mapped as nodes, just move the node.
- When the amenity changes (new shop opens, office becomes a shop, etc.), some people may add the amenity to the node, while others will add it to the building, resulting in **two** Frankenstein’s monster tag sets.
- Somewhat differently, with highway=* that have lots of tags: Way: Dublin Tunnel (129662536) | OpenStreetMap any changes in one tag means splitting the way into two very similarly-tagged ways. So, if the amenity has 10 tags and the building has 10 tags, it can become messy in trying to determine which refers to which.
3 Likes
Personally, I always prefer to merge nodes with buildings. This is because they can clog editors, especially in a downtown area. They can even cause lag when editing those places. Take, for example, Washington, DC.
No? I think this is perfectly fine. Having two overlapping areas makes them harder to select and edit.
If you combine these two, then it should be tagged like this: construction_date=1900; start_date=2015.
As long as you are fine with mapping data that is not really being usable and is not being used by data consumers.
2 Likes