Certainly the implementation by renderers won’t be quite as easy as coming up with the tagging schema, I acknowledge that, hopefully if we can test some different shapes and scenarios we can find if the proposed tags are good enough or parts need to be rethought. I’m fairly happy with the tags as they are now (I know some people have suggested alternatives but hopefully it’s acceptable to most people now), so any experiments are welcome with the caveat that some tags may still change, but the fundamental logic and shape types shouldn’t. I will work on creating some test cases soon with some new or existing buildings (that I’ve mapped) to hopefully make it easier to see examples of real buildings and tagging and how they are expected to look.
How it is proposed to tag this one? The tower is round and narrowing towards bottom.
This is a quite common case in historical architecture. Model this tapering with multiple “slopes” will be quite inconvenient.
We have the same problem with this kind of roof shape too, I think the only solution is to officially approve using a multipolygon for this shape, which F4map already supports. See here: Relation: 18851215 | OpenStreetMap & on F4map: F4map Demo - Interactive 3D map
I personally think not everything has to get entered into the databse in extreme detail like this. Just a round building:part with a roof and be done.
But i see why it might be a nice challenge to map it in the most possible detail.
Yes, Zkir’s example is quite a small architectural feature and might be overdetailing adding it, but the issue is a real one for prominent buildings where they taper or have a (partial) conical base like the Gherkin as mentioned previously or this water tower
While using a multipolygon with a cone roof, and creating a second building part with a flat roof to fill the hole, could kind of work to simulate a truncated cone, that solution feels hacky. Especially because it seems like it would require entering an incorrect roof height for the cone.
Perhaps this rather suggests the need for a truncated_cone roof and bottom shape. (Or a subtag for cone and pyramidal roofs to truncate them?)
To make sure I understand the “can be replaced by arc” comment: so inverted_round would become base:shape:inverted_arc=90-270 and inverted_segmental_arch would be an e.g. 35-145? And a bad rendering of round would be base:shape:arc=90-270.
The arc base shape tagging is a work in progress, but logically base:shape=round would be equivalent to two (opposite) base:shape=arc. The tagging I was thinking of was to have (something like) arc:angle:bottom=90 and arc:angle:top=0 which would be a full curved piece starting vertical at the bottom and horizontal at the top. If the tags worked like this, there would be no need for any kind of inverted_arc. To invert the shape you would change to arc:angle:bottom=0 and arc:angle:top=90. Your idea of using a single tag e.g. *:angle=0-90 is interesting, I am looking at different ways to tag this situation clearly and simply. Any angle entered would have to be a maximum of 90 degrees or you would end up with impossible geometry. Also, something like a top angle of 10° and a bottom angle of 80° would be impossible (diagrams will be needed). I know this section is quite confusing currently, as it’s a whole new concept that could also be applied to roof shapes in the future.
As for inverted_round & inverted_segmental_arch, they could be officially defined if there are real building shapes that would use them (+ it shouldn’t be too difficult to implement given they are mirrors of other proposed shapes), but I don’t want to be proposing ultimately useless values just for the sake of it.
The logic I was imagining for a ‘truncated cone’ would be for example:
base:shape=inverted_cone + base:height=10
This would result in a cone being created in the lowest 10 metres of the shape.
If you then created a multipolygon within the centre of this shape, the circular edge (the inner of the MP) would be the lowest point of the shape and would still be 10 metres in height. So, there wouldn’t be a scenario where the tagged base:height refers to the height of the imaginary cone that has been truncated. Does that make sense? I will make a diagram explaining this concept too… I don’t think a subtag would be necessary, we’ll see.
Additional: if we can get an agreed upon approach for tagging arcs and truncated cones/pyramidal, it would be good to propose them as official roof shapes too.
Additional 2: I’m imagining a scenario where a roof:shape=pyramidal is turned into a MP and renders the exact same as a roof:shape=mansard (flat-topped). Maybe that’s right, maybe that’s wrong…
Please exhaustively indicate which shapes need base:direction and which do not, so that validator rule writing is easier.
Also, min_height + base:height + roof:height being greater than height should also either be a validator rule or have specified interactions.
(impossible exterior materials i.e. carpet)
I think that’s just because we haven’t seen an architect brave enough to carpet the underside of a building. 
Added.
It’s hard to visualise what kind of 3D errors/clipping could be caused by incorrect tagging, this is something to investigate once we have an experimental implementation. @Zkir - ready to try out some of these concepts in UrbanEye3D yet 
?
In the past couple days I’ve been tidying up the finer points of the proposal and updating the diagrams, at this point I’d consider the proposal frozen and ready for experimental implementations to see how it works/doesn’t work.
Likewise @Tordanik, if you were ready to create an experimental implementation in OSM2World that would be very useful at this stage - pending a few more explanatory diagrams and tables, I don’t anticipate any more tag or logic changes until we’ve been able to test out the tags in a real 3D renderer 
.
Also, if anyone finds any parts of the Wiki proposal page that are unclear or need expansion let me know, as I obviously want to make the proposal as clear as possible.
Well, I’ve promised @Tordanik to integrate OSM2World into UrbanEye3D, but still cannot deliver. (I am completely out of fuel currently, and my other project got just practically no reaction, just 2 likes. Well, it’s better than none)
Both features require significant refactoring in the core of UrbanEye3D. So we all need to live long enough to see this proposal implemented.
That’s ok, there’s of course no obligation to do anything . In terms of the integration with OSM2World, what’s the concept/purpose of that? Trying to match up UrbanEye3D rendering 1:1 with OSM2World rendering or something else? (Or if there’s somewhere with some info about this integration a link would be fine)
As for your openlandcover map it’s a really unique way of presenting OSM data, it’s a shame that it’s perhaps not been recieved as enthusiastically as you might have hoped.
Posting the work so far on the renders here to get some additional feedback. Unlike my roof renders these will be blue.
Major pain point is finding a way to show cone and dome.
The idea was (and probably still is), to use osm2world code as alternative geometry-generation backend for the UrbanEye3D plugin. osm2world supports more features, not only buildings, so it could be usefull.
I’m still planning to, just wrapping up some work on in-browser rendering first. 