I have written a proposal (3D tagging for building base shapes) to introduce a new set of tags for representing the shape of building undersides, for example archways and spherical building parts, which cannot currently be accurately represented in regards to 3D rendering. I am seeking constructive criticism and comments about the tags I have proposed, particularly concerning the suffix :inverted, where I am open to changing the recommended tagging for differentiating between a downwards arch shape and an upwards arch shape, please see the Examples section for how this tag is intended to be used.
Please leave feedback on this thread, not on the Wiki talk page.
Looking forward to reading everyoneās feedbackā¦
Strongly support this concept, it is very much required. Iād had something very similar in mind, including the choice of base: prefix and eg. base:direction sense all as described.
Itās been a shame to be able to nicely define the upper half of a fancy building and then for the bottom half to āgo all Minecraftā due to the current assumption that (modern) buildings are all biggest at the bottom, with only flat-topped holes.
Iād not considered directly copying all the roof:shape names but rather adding what is needed with appropriate names. āroundā and ādomeā and āpyramidalā(or āconeā) - and default āflatā of course - make sense as natural mirrors of the roof ones. I was imagining āslopeā rather than the very roof-related term āskillionā for a non-flat planar base, and something like āround_archā (for semi-eliptical eg semi-circular if height=width/2), āpointed_archā (for a Gothic one with 2 arcs meeting at a top centre corner point) and it seems flatter arches get called āsegmented_archā (for a circular arc that has height <width/2).
(The diagrams in the proposal should reflect the semi-eliptical shape implemented for āroundā, not a general parabolic-ish shape unless we more carefully define roof and base curve shapes. Actually, being able to explicitly choose a flatter arc not necessarily a semi-ellipse would be useful for roofs too, but thatās another matter).
Seems unnecessary to specify or invite use of the other roof shapes (incl onion etc) unless we really have examples? But fine if we do.
The presence and meaning of base:levels might need a little thought. roof:levels is a bit strange in being additive to the building:levels (but values of height are total with roof:height subtracted to get the walls-only height). Would base:levels also be additive? (not sure; probably yes if they are proper 1-storey arches). But base:height being subtractive like for roof makes sense. Havenāt got my head around this yet but we need to check what makes sense here. What if roof:levels and base:levels are both large so that the remaining (wall) levels is negative - this is wanted for the overall diagonally sloping building case. Also I guess same for heights for the case of the matching arched base and top, having height - roof:height - base:height as negative is a realistic case.
Another issue for the base that doesnāt occur for roof is interaction with the ground. Not an issue in many 3d renders, but already hurts peoples head with a flat building base and slopey ground where ground shape is implemented. May need to choose if we specify that the skillion/slope base is specifically meant for in-the-air undercut faces, or not. Again, needs some more thought to be sure we know what we want to do. Matching building shape to slopey ground is really another subject but itās unavoidably linked once base shape can be set.
Iāve one other undercut shape for which this opens up only partial solutions - the lower part of āThe Gherkinā in London is a symmetrically undercut circle - which would either need a tall downward dome deeply embedded in the ground, a ring of undercut planar facets, or to stick with the current horizontal slicing. At least itās good to have choices, even for unusal cases.
Thanks for your comments Cebderby, thereās some good suggestions here that will incorporate into the proposal, for example:
to not suggest all these roof shape equivalent values until someone finds a real life example where it would be useful
to change some of the roof-centric tag names to things like slope instead of skillion and arch (or round_arch) instead of round:inverted
proposing some entirely new, useful shapes like gothic arch and segmented arch (this one will need a bit of thought because it would be an arch shape that begins already at a very shallow angle, which isnāt something possible even with round roofs)
As for base:levels, I think in contrast to roof:levels it must be subtractive, say for example you have a 4 storey building where it has a sloped underside for the bottom 1 level, it must be tagged building:levels=4 and base:levels=1. I donāt think thereās any other way you could tag this. You canāt have building:levels=3 and base:levels=1 (for a total height of 4) because thatās really confusing in respect to existing building tagging.
Iām not really sure what point you are making in regards to how this could be affected by āslopey groundā, so Iād appreciate more info if you think there is a potential issue there.
As for the Gherkin, thatās going to be a tricky one to solve. I think itās a similar problem to where the roof shape is a cone but thereās a multipolygon inner to create a flat central section for example (which isnāt official or supported well as far as I know). Certainly though we shouldnāt be encouraging editors to tag building shapes that go down underneath the ground just to provide the desired effect. Height=40 and base:height=100? No thanks
I havenāt updated the proposal yet, but Iāve rethought all the base:shape values that Iām going to present in the proposal. I have eliminated things like onion and side_half-hipped until I can find a real world example where those would be useful. Iāve flipped around which way is inverted and which way is normal, I think it makes more sense like this (most uses will probably be non inverted tags now). I have added a few new values such as pointed_arch and segmental_arch that were suggested. I am also featuring gabled, gambrel and saltbox, as these could actually be very useful for representing the overhangs present at the ends of some of these rooves. Also Iāve changed the tagging (for example) from dome:inverted to inverted_dome, as this eliminates the colon in the value field and is also the more natural order that a human would use to describe the shape. (āThatās an inverted dome, not a dome invertedā)
Mentioned it now in advocating for base:shape=arch + base:shape:arch= to replace base:shape=*_archProposal talk:3D tagging for building base shapes - OpenStreetMap Wiki
Thereās a caveat if you know bridges more. Basket handle arch bridge has a different meaning. Itās for non-vertical arches that moves closer to each other at the top. Therefore I was thinking three-centered is a better term.
What would be the difference between round as it is now and basket arch? You can use base:height to make the arch shape shorter which seems like is exactly what basket arch isā¦
Iām not a fan of this three-centred arch shape, namely because itās ambiguous the exact shape it should form. Thereās some complex geometric maths going on and you would need a way of explicitly tagging the radius of the smaller arcs. (See image). When you reach a situation like this, I think it would be simpler to introduce a partial arc shape that could be used to construct complex curved shapes (for example a wavy archway, if that exists)
At a glance, it does seem workable. In fact, Iāve already gone ahead and added base:material and base:colour support to OSM2World. (Would be easy to change if we agree on some other tags.) But I canāt be sure if there are non-obvious problems unless Iāve tried implementing it. So if you plan to move this to a vote I feel there should be one or two experimental implementations first to verify the idea.
This case, for example ā¦
ā¦ is going to be quite tricky to get right, especially if I want to support indoor mapping inside those levels which are simultaneously part of the base and the roof.
Some more unorganized thoughts: There are similar challenges with modelling the shape of windows (window:shape and especially window:top:shape), the shape of doors, and the shape of tunnels. If some terms works across those domains, that would seem ideal.
This is a minor aside, but: The tag doesnāt seem established in the context of indoor mapping, so IMO the wording shouldnāt suggest that it should be used for that either. Judging from Taginfo, the bulk of uses seem to be from imports or organized editing campaigns.
Thanks Tobias, any experimental implementations would be very welcome! One key thing to know for the implementation is that base:height and base:levels are both going to be subtractive from the overall building height and levels. E.g. if I set min_level=4 and base:levels=1 the base shape is going to occupy the fifth level of that building shape, not the fourth (contrasting how roof:levels works). Iāve decided itās necessary to do it this way in order to be able to handle more complex situations where the top of the base shape could overlap with (level-wise, not literally), the bottom of the roof shape.
Iāve adjusted the wording surrounding floor:material=* to remove any suggestion of redefining that tag within the scope of this proposal. The proposal still of course encourages people to use base:material.
Please note the addition of partial_arch/arc (placeholder value, opinions please!) for creating a custom arch piece beginning and ending at whichever angle the user wishes to specify. This will also need a new tag for specifying said angles at the top and bottom of the arch. The rationale behind adding this is that some complex archway types and geometry involve too many parameters and mathematical equations to be practical to map and render. Hopefully, with a partial arch shape, this unlocks many possibilties of any type of arch or curved piece that needs to be represented. (Maybe next we can add partial arch as a roof shape!)
In addition Iāve also rewritten sections of the proposal page to reflect the new base:shape tags Iām proposing and to incorporate the feedback Iāve recieved, so feel free to re-read it. Still to come will be a proper table with all the base:shape values with example tags and real example buildings where they can be seen.
I have problems with the basic premise that simple 3d building mapping should have any where near the level of detail that is being proposed. It was always intended as an rough approximation of the buildings outer hull not a near photo realistic model. Now while the scheme has been, not unexpectedly, misused a lot, that doesnāt justify continuing down that path, particularly considering that it makes adding actual useful information vs. eye-candy much much more difficult to add.
I wanted to highlight the fact that this proposal aims to reduce the misuse of building parts by providing simple shapes that 3D mappers can use instead of creating blocky undersides with dozens of building parts, where one would suffice. For example, each orb of the Atomium (Relation: āŖAtomiumā¬ (āŖ19189219ā¬) | OpenStreetMap) is currently represented with 21 circular building parts - with this proposal it could be done with one. Likewise, the Puerta de Europa towers in Madrid (Way: āŖPuerta de Europa Esteā¬ (āŖ11103227ā¬) | OpenStreetMap) consist of 27 stepped building parts each (one per floor), under my proposal this could be reduced to three.
While I agree that some buildings have been mapped in an extreme level of detail (See this church in Chelyabinsk with its 6000 building parts Way: āŖCathedral of the Nativity of Christā¬ (āŖ419266377ā¬) | OpenStreetMap), I donāt think that warrants the argument that the Simple 3D Buildings schema is problematic in some way. I have specifically limited this proposal to only 3 new types of basic arch shape, including a partial arch in order to reduce the burden on 3D renderers to calculate the complex geometry required for some of those shapes. All other shapes in the proposal are already existing roof shapes. If, in your opinion, people are misusing building shapes or will misuse these new building shapes, it should be up to the OSM community to police how building parts are used, similar to how the response to tagging for the renderer is to engage with users doing it, not removing icons and area colours from carto simply because theyāre being misused.
Additional: in response to your mention of āthe level of detail that is being proposedā - there is no minimum, maxium or recommended level of detail being proposed or even mentioned in this proposal. Itās up to the editors how much detail they want to add, like everything in OSM.
Maybe we could remove the āarchā from pointed_arch and segmental_arch for slightly shorter tags? (or alternatively, add it to round for consistency)
I picked pointed_arch and segmental_arch because theyāre very clear what they mean (base:shape=pointed to me sounds quite vague). However I chose to use round for consistency with the existing roof shape, as I felt people would be familiar with the tag and shape. I donāt think round_arch or rounded_arch is necessary as round is clear enough to me.
