This happens from time to time, people that map all over the world stroll by, and do some mappings out of some principle. Just seen now, Changeset: 126423457 | OpenStreetMap that claims to enforce the Good_practice#One_feature,_one_OSM_element rule
The building is NOT the restaurant. There are different owners for a start. The restaurant also does not use all of the building space. Is this covered by the rule?
For me the ownership of the building is almost always irrelevant: I can’t tell when walking or driving by who owns the building.
I will merge the restaurant and the building if and only if the restaurant fills the entire building.
(1) if you complain about bad editing by someone, please let them know
(2)
To quote from One feature, one OSM element - OpenStreetMap Wiki
“Examples of bad situations (…) Shop in a building mapped as a single object with building=* and shop=* and name=* (which will often apply only to POI). This one is more debatable, and many mappers consider it as a valid tagging.”
Disclaimer: I think I added this line recently there.
This specific edit is making things worse and in my opinion should not be done.
In my opinion, the fact that the shop doesn’t occupy the full building is the most important thing here. To demonstrate this, you could in theory change the shop to an area within the building, and the footprints wouldn’t match.
Going forward, I would contact the editor as advised and perhaps add a note to the shop to say that it doesn’t occupy the full building area.
I don’t think “valid” is a good word here, this representation makes it impossible to tell whether the name applies to the building or the shop or both, so it should better not be done. It is done, but I’d consider it preliminary, certainly if both were already mapped as distinct objects we would not approve merging them into one object, would we?
This edit is clearly not justified by the guiding principle. Rather, this now results in two features being represented as one OSM element.
I did overreact. The message is quite bold though. I came here, because of what I see as a war on the POI, and this is not the first time I got to see this. The POI only tells you, there is a restaurant and an alpine hut. (The restaurant might be considered redundant, as alpine hut includes alimentation.) When merged with the building, one also gets to know the precise area occupied. This extra information is of little use though. It only complicates matter, if I wanted to e.g. tag the start date of the building, will I have to use a namespace? So much noise for so little.
the solution is using a different area for the poi, e.g. a mp relation or an overlapping way. You might not do it initially as long as all properties belong to both features, but you should do it when you want to add specific properties to only one of them, clearly preferable to namespacing.
Feel free to strengthen this if you think that this claim is too weak! I used relatively weak form as I at times discussed it with others and was not sure is it clearly supported by consensus
I have tried to improve it
I agree with you. There are frequent situations that other than having area mapped there is need for specific point that would be used as reference to the object. As they do not see better way, people tend to enter both - way and waypoint.
I guess it could be solved by introducing some kind od microrelation that connects area and waypoint. Using proper relation for that is overkill. I guess introducing tag that would be called microrelation and that would be used to point to other object would do fine.
Tendency is that people enter objects as waypoints, as it is simpler and usually they have no data or means to draw area and complete tagging. Later, area is drawn an done is expected to copy all tagging from waypoint to area and kill waypoint - removing that point reference that might be needed.
I see it as improvement if one can add area and microrelates it to already existing waypoint without need to tag it again.
In rendering if area is microrelated, then renderer would gather all tags from microrelated waypoint. That would give us the best of both worlds.
this also could work in opposite direction. If area is tagged than added waypoint could be microrelated to it to gather tagging info if needed.
Microrelation could simply mean: collect tags from that other object.
KISS: a building is represented as an area and a Point of Interest, should be mapped as a node, except if you have could reasons not to do so.
representing something bigger than a point as a point means using valuable information (namely about the size, shape and orientation). We tend to map POIs as polygons, e.g. hospitals, schools, museums, lakes, factories, supermarkets, etc. and only for many small ones it is not done (yet), but I expect that sooner or later we will add also smaller pois as polygons, particularly when we want to map things inside these POIs on their own.
I said so: There is a war on the POI. It is fuelled by people, that think, because two dimensions are more than one, everything must be mapped two-dimensionally. For an alpine hut, I agree, that it coincides with the building. For a restaurant, I do not agree. Who cares about orientation? The restaurant occupies part of the building. Is the kitchen part of it, it is not “where people eat/consume”? We have much better ways to tell, how many seats? Area is of no use here.
I think it’s perfectly defensible to map something with spatial extent as an area. It should be left up to the mapper to decide.
However, I also agree that tagging a restaurant, etc. on the building outline is not always a good idea, in particular if the building serves multiple purposes.
So we should try to find solutions for situations where this kind of conflict arises. IMO, saying “map your area as a node because we haven’t figured out a better way yet.” is the worst solution.
KISS, this kind of issue is usually solved by making a relation, like a boundary-type relation with a shape (defined with ways as inner/outer) and a node for the POI itself. But as said for a restaurant, it may make sense for indoor mapping.
The supermarket example is probably a bad one: tagging the building as supermarket is probably just wrong, like in a mall, the main shop doesn’t fill the entire building usually, does it? Then information for proper indoor mapping may be missing.
there is no conflict, we are handling these cases for years, we do not have to discuss all kinds of features one by one, buildings, and then lakes, or pitches, or golf courses, it is always the same. You can decide whether you want to add a thing as node, or as a (closed) way: no problem drawing another way atop the building way, but it is easier in creation and for maintenance to use a multipolygon with the building as outer member. 3 options to choose from.
The node is fastest and bears less information and cannot have other things nested inside, the other 2 options are equivalent.
I agree with you on the mapping matter.
However, the discussion here strongly gives me the impression that there does exist a conflict. 
KISS and advise to use a relation in one statement. I like your kind of humour. 
My practice on this topic is to generally prefer mapping a building as areas, and the businesses, amenities, or just plain addresses within as nodes. In medium to high density built up areas a building usually contains many distinct entities and trying to map them all as areas inside the building becomes very confusing and hard to maintain, especially for multi-floor buildings. Maybe in the future better tools will make this a non-issue, but for now, nodes just seem much more sensible. In low density areas buildings containing just one entity are common, and it certainly seems fine to put the entity and address tags on the same area as the building tags. However, I still generally prefer to keep them on a separate node for consistency between high density and low density areas. Unless the single entity building is very large. In that case recording it’s size does seem useful.
I definitely don’t consider mapping a building and the single entity it contains as two separate OSM objects to be a violation of the one feature, one OSM element rule.