Streets GL has prompted me to look into multipolygon relations for 3D buildings.
I’m trying to see if the tagging can be improved for the Balmoral Hotel. This a hotel with a inner courtyard and a tower.
At the moment there’s a multipolygon (MP 1) with a building tag, it has the building as visible from the street as “outer” (way 1) and the courtyard as “inner” (way 2). If it wasn’t for the tower, we would be done here. And then there’s a building:part for the tower (way 3).
F4map is happy with this, but StreetsGL isn’t, it only renders the tower. Looking into this, the Wiki says that if there’s a building:part present, some 3D renderers will ignore the building itself. So this seems to be an issue with the tagging, not with the renderer.
So I think I need to duplicate the multipolygon so there is one with building for 2D rendering (MP 1) and one with building:part for 3D rendering (MP 2). Then I can keep any tags related to the hotel (such as its name) on MP1, but move tags related to 3D rendering, such as building:levels to MP2.
Should the two MPs have the same members, so way 1 and way 2 are both members of MP1 and of MP2, or should I duplicate the ways as well?
If I’m duplicating the ways, they should still be sharing nodes, correct? (After all, it’s the same walls)
Here’s a sample of a big museum in Izmit, Turkey I put in a relation, parts, outline, different levels, courtyard, the latter taking some trickery to get that working, needing an MP inside the type=building relation to get it right (in the picture). Fashioned it so it rendered correctly in F4map, and it looks proper in Street GL at the same time just now checking. OSM Buildings has not updated in a longer time so can’t say what my fixing this building does there. Summary though this is 1 type=building relation and a part is MP to deal with the smaller of the 2 courtyards.
Without the courtyard, ways sharing nodes would be the straightforward approach, but if multipolygon relations are needed anyway because of the inner ring, might as well re-use the members.
I don’t think so, because the building parts of that building don’t have holes and therefore aren’t multipolygon relations. The only reason why there are two relations involved in this example is because there’s a type=building relation (which is optional) in addition to the one multipolygon for the building footprint.