Thank you for the replies both Escada and Cactusbone.
It may be that I caused the whole confusion by making my intial question too broad.
I should have concentrated on the initial closed way only, and then maybe from there ask for further guidance.
This should have been the actual question:
R0bst3r answered to me directly, but I never understood the reply:
I’ve never found information to upper question on wiki nor on 3d page.
Also what MKnight initially said, he partially withdrew after discussion with vvoovv, so I do not know which part of his reply R0bst3r referred to.
Is it possible to give one or two examples of how this issue can be solved?
So when a closed way representing a building outline, completely matches up (coincides) with one of its building parts, then:
We need to have two different closed ways: one representing the building outline, and another one representing its building part, and both of them along with other building parts would be grouped in a relation? Is this correct or not?
What would be the other solution?
I apologize for prolonging this topic even though I got so many answers. But I simply do not understand the conclusion. Thank you for your patience.
I apologize to everyone for prolonging the question, to which it seems the answer(s) have already been given. It seems I am the only one not understanding it.
But can anyone post an example of how Is it possible to give one or two examples of how this closed way can be solved?
The upper closed way representing a building outline, completely matches up (coincides) with one of its building parts.
How can we solve it?
I edited the link. My apology for posting a wrong one. Thank you for pointing this out vvoovv.
Whturner, thank you for the article! Is it possible to comment on this specific way? How can it be separated from the building part which covers exactly the same area/
Using both building=* and building:part=yes for the building outline is completely legitimate and useful.
Recently I added building:part=yes to the outline of a number of buildings including Brandenburg Gates in Berlin and Westminster Palace in London.
The greatest advantage of setting both building=* and building:part=yes is that a mapper doesn’t need to create additional OSM elements.
A disadvantage is that height is related to the part not the whole building. But it’s questionable what to call the height of the whole building if the building is composed of several parts. So it isn’t problem at all.
So set both building=* and building:part=yes for the building outline if it reduces the amount of mapping.
No doubt, but I feel we should still avoid adding incorrect data, and it’s not typically possible to add one height value that is correct for both the building as a whole and one of its parts.
The “height of a building” is a very commonly used concept in the real world, and often comes up regarding skyscrapers, towers, monuments, or pretty much any tall building. Normally this would be the height of the building’s highest point, although one might argue about specifics, such as antennas on top of the roof.
So this piece of information has value independently from 3D rendering, and will be used by applications that are not 3D-aware (such as a map rendering, a listing of the highest buildings in each city, and so on). That kind of use case is what tags on the building outline are intended for. So the building outline should contain the height (and other tags) for the total building, which precludes re-using the building outline as a building part.
Thank you for the useful replies, both vvoovv and Tordanik.
In that case, what will happen with the building part? Another closed way on top of the building outline will have to be created, and be tagged with: “building:part=yes”? Regardless of the fact that now the building outline and building part closed ways coincide with each other?
That would be correct, yes. It doesn’t feel satisfying to do it like that, but that’s ultimately a result of representing 3D data in a 2D format: The building is different from the building part in the vertical dimension (that is, the 3D shapes do not coincide), but it has the same footprint. As a result, the two look identical in your editor, but still need to be distinguished for 3D rendering.
The nodes also get bigger if there is more than one way using them, letting you spot shared nodes. Or you can just middle-click on the way(s) and get a list of them.
Using multipolygons like this is already possible today. After all, way-based areas and relation-based aras are semantically interchangeable.
Whether that’s better than overlapping ways is a matter of personal preference. I have no problem with this tagging, even though I don’t use it myself.
This would be a possible solution if we want to update the standard to allow this. For backwards compatibility, though, it would be better to keep the regular tags for the total height/levels (after all, tags like height pre-date 3D mapping), and invent new ones for parts.
In spirit, this would be similar to things like bridge:name, which was kind of necessary before man_made=bridge was invented. I feel like this type of solution never really caught on elsewhere, though, and would prefer following the “one feature, one OSM element” rule.
