I can’t agree with this statement. All building parts building:part=yes must be located inside the building outline tagged with *building=**. So the building outline for a building:part=yes can be easily found visually.
I agree with you if we talk about simple buildings.
But if you ever will try to model a church for example with different building:parts overlapping each other for a tower, with building:* and roof:* and ridges and … then it is much easier to name and sort all ways using a type=building relation.
Also some 3D renderers can handle such complex buildings much better.
Think about an ID user wants to change the address of a building with a lot of overlapping ways. I see much better chances here to select the correct outline if he follows the members and structure of the relation.
I would be strongly against this. I think both the type=building relation and the building outline (which should preferentially have role=outline set as its role if it is a member of a type=building relation) have their function in OSM.
Just assuming anything tagged within the outline is part of a certain building, can lead to problems as well. What about buildings that kind of interlace / overlap each other… There are plenty of real world cases of this. Only a type=building relation will allow you to properly separate out the different parts and assign them to the correct building.
By not requiring that all building:part fall within the outline, but leave it up to a relation to define what parts form a building, we might also consider to have more sensible or flexible 2D footprints/outlines, that do not necessarily have to contain all parts. E.g., in some cases, limiting the buildings outline/contour/footprint to just what is at ground level, like in most “topographic maps”, instead of ending up with much larger contours to kind of artificially contain building:part below or floating above ground. It is kind of strange and at times very confusing to see building footprints considerably larger than what the feature on ground level represents. Of course, what represents the footprint or outline of a building, is to a large extent an arbitrary choice with these kind of complex buildings…
Of course, this latter suggestion is not the current standard, so sticking with the rule of an outline containing everything to allow rendering in most current 3D OSM renderers, is probably wise at the moment.
I would go confirm with that, although it may not reflect the complete truth.
I’m not sure, but I think some building’s need relations to be modeled. For example if the outline “covers” some building:part, e.g. if using building:min_level only on one part (Checked with Kendzi3D).
I would be in favour of discouraging the relation. This would make 3D mapping seem less scary to mainstream mappers, and is pretty much what happens anyway – most buildings in the database do not have a type=building relation, so 3D renderers already need to handle that case.
The only exception I see is if the situation would be ambiguous otherwise (i.e. overlapping buildings). But that’s a very rare case, and no reason to add relations to all the other buildings.
tl;dr: Use building relations only where they are necessary, which is almost never.
OSM is a bit of evolutionary: use Tags as you think. If the A) majority of users and B) the renderer use it to, you won.
To have more than one solution means more to do for the renderer developer.
In this case, both solutions for Building:part are useful
if you, vvoovv help me with the algorithm “This Way is inside that Way”
Are both implemented in all actual 2D/3D render?
Just do mention it: There are Multipolygon relations for buildings with “holes”.
The role:inner Way may not have any Tag at all. The outer to, if they are at the relation.
I think, Tags at outer is “old style”, at the relation “new style” and quite some updates are done.
So we have that “ugly” relation there too.
Vvoovv’s concept used here would mean a Tag Building:inner
That would work to, I thing and good to use for newbies IF the renderer agree accept it.
Will “the renderer” implement it? (I have never ever written a proposal)
Of course you did not, I did. I see the same challenge for holes and parts. To be consequent,
we could use the same two solutions: by relations and by “is-inside”.
And I will find, how you do “is-inside” it or ask you.