Problems, implementation and development of S3DB

this should be topic for every things around Simple 3D buildings definition:

  • Usage
  • Development
  • Implementation
  • Suggestions / Ideas


This is true, but didn’t we started that sort of discussion already?

This discussion is currently very large, and it is hard to known what is important there. Some topic was discussed and we mostly agree on them eg. like roof:direction tag. So maybe it is time to make little cleanup there and make some sub-page for discussed content? For example we can make page for roof:direction tag and move all discussion about it to that page?

I have already suggested the next codification meeting because (although I very respect our Forum and Wiki discussions) we should go forward. And standard definition during such codification meetings are simply very effectively.

What I mean with this topic is a space for ongoing discussions on various “small” topics and ideas.

Implementation of 4.3 = pyramidal-diagonal

Please take a look:
It is impossible to make 3D models without such surfaces.

I see here 2 solutions:
A. Implementation of 4.3 (

or / and

B. Implementation of 3D surface described as:

with exactly 3 points with known height value on the outline.
The points are easily to determinate for the user without deep knowledge in 3D modeling:

In a standard case 2 points on the Eaves edge [1] and one point on the ridge…

I believe, it´s very easy to implement B.
If we had B, we could write import filter for *obj files and import all shapes which are not orthogonal to the earth surface as such roofs.
I did it already successful for an other project.

Regards, Marek


This shape is very specific and i don’t think it deserves a special S3DB case that will be nearly never used.

This could be mapped with skillion roofs like i did here.

it´s not specific. And skillion roof is here wrong, because the ridge line (see ) is in this case not horizontal.
Anyway. I believe Kendzi hat´s already.

You can do non-horizontal ridge line with skillion tag.

Check out the semi circular greenhouse part here (ridge is not horizontal).

There is an other possibility alredy implemented. Also in your tool:

See this:

Skillions are more powerfull than they seem :smiley: i did the Faisal Mosque.

PS: sorry for the ground tile delay but our tileserver is currently spammed by a huge amount of users…


Wnat we need is definitly the extended description of usecases for the roof shapes.
The OSM wiki page can recentlsy not explain, how the elements works in detail.

How can we cope it?

Hi 3D friends, i think we definitly need some tags to describe the ceiling of a building:part with min_height.

We could use “roof” similar tags to define the ceiling/arch under a building:part with min_height (this is clearly inspired from entrance table but matching the S3DB tagging).

arch:height=number in meter

Left: 1 building + 1 building:part to define an entrance
Right: 1 building:part to define a tunnel through a building (outline building is not represented)

We could improve it altogether then i could make a proposal in the S3DB talk page

Very good idea, please do it!

I would very much like a set of tags for the shape of tunnels and entrances. Nevertheless, there are some ways in which I would like to see your proposal improved.

One issue is that the terms for roof shapes might not be the best choice here. I might be mistaken but afaik they are not used for things that aren’t roofs in English. So using values from the entrance table may be preferable after all. It would be great, however, if you could suggest a set of values for the top of tunnels (including, but not limited to tunnels through buildings) and entrances at the same time due to the similarity between the topics.

Perhaps more importantly, I don’t agree with the tagging in your examples. Building parts should not be necessary for entrances (use entrance=) or tunnels through buildings (tag the way with tunnel=, ideally the value tunnel=building_passage that has been suggested for that particular purpose). These tags are useful for other applications besides 3D rendering and adding them is easier than modelling the shape with building parts. The linear nature of tunnel ways would also help a lot with calculating the shape of the cavity - a building part could have an arbitrary shape, making the construction of e.g. a long, curved tunnel with a triangular top unnecessarily hard.

I’m ok with the entrance table naming (it could be improved using this list). I used roof:shapes as an example to be sure everyone already used to 3D mapping will understand what i meant.

My main objection against using Tag:covered and Key:tunnel is that there is not always a way under the ceiling we want to represent in 3D.

Here are 2 example :

  1. Arc de Triomphe in Paris.

The whole circular pedestrian area underneath the building can’t be used to map the ceiling of the passages as they do not exist (and are not needed) as way in osm.

  1. Roman architecture like Coloseos or Aqueducts hve no way under the arch i want to tag in OSM.

That’s why we now handle straight skeleton in F4Map so this is not hard anymore :wink:

While your examples indeed illustrate that arches without ways passing through them exist, they illustrate a different case than your original “entrance” and “tunnel” examples (and I meant to criticise these examples in particular). Furthermore, the examples are also buildings which would probably be among the first candidates for a hypothetical free building repositoriy for hand-creafted models of buildings that go beyond what can be reasonably mapped and maintained within the OSM data model.

I usually tend to start from less prominent buildings when thinking about tag-based mapping (which is, as terms such as “Simple 3D Buildings” hint at, best suited for simple cases). And in those cases, you will often find openings which the simple purpose of letting a way pass through. Modelling such tunnels through buildings using ways with a tunnel=* tag is a practice that far pre-dates 3D mapping, which is why I considered it essential to support it in OSM2World.

This is true, of course. However, I would like to point out that there is not always a building above a tunnel either. Therefore, I think it’s clear that we need way-based arches at least for tunnels through the ground. And as I said above, it’s relatively common practice to map ways through buildings as tunnels, too - so using those same shape tags seems sensible. If nothing else, adding a tag is a lot easier than having to map multiple areas.

Admittedly, there are those more complicated situations that you describe, and we need a solution for them. Since I don’t have anything better to offer, it is likely that this idea will be your idea of tagging the bottom of a min_height building part. But I still don’t think that this should be the only approach.

Well, congratulations for having that powerful algorithm into your toolbox. I wish I could say the same about OSM2World.

I agree that a new tag to indicate the tunnel ceiling shape should be used in combination with Key:tunnel it would be easier and less intrusive for mapping.

But my objective is to improve the key:min_height for buildings because the ceiling is rarely flat in real life.

We can thank postgis, it does the hardest part :slight_smile: