Parts of one building:part are not rendered with OSM2World

… and more building:parts missing.


there are some problems with rendering the shop of this petrol station. The part of the shop building below the blue bar is missing. Also the pillars below the large roof are missing resp. they only exist inside the roof, but not below it (nearly the same problem as with the shop).

For the car wash building I have attached the building=yes tag to the building outline, where the building meets the ground in contrast to the shop, where I have put the building=yes to the blue decoration bar, which surrounds a little larger area than the base building. Here at the car wash I am missing the surrounding blue bar completely.

Also, how can I model the small roof between the shop and the large roof? It’s laying on both roofs, which have a different height, like a ramp or a board, but with a constant thickness.

The version I am rendering small extracts for testing for OSM2World is 0.2.0.

With the Kandzi 3D view plugin for JOSM all parts of the buildings are rendered - other than with OSM2World.

So, what’s wrong with my tagging? I had no exception in the debug window.


Building parts “inherit” tags from the building unless they have other values for these keys.

So if a building has building:material = brick, then all building parts without a building:material tag will get a brick texture. And if a building has a min_height=4.4, then all building parts without a min_height will start at 4.4 m above the ground.

This also applies if a building:part is “dual-used” as a building.

I think Simple 3D Buildings isn’t able to do that yet. Diagonal lines are generally tricky. :confused:

That’s an interesting difference in the interpretation of the tags then and I would be interested to hear from Kendzi where exactly our interpretations of the tagging are different.

Hallo Tordanik,

thank you for your hints. Now it’s ok. That can be a reason why the central station of Lübeck has a building height of 10 centimeters

I have also added the doors to enter and exit the car wash as building parts.

But the Kendzi 3d view doesn’t recognize the entrance=main tag, which I have put at the shop.


I have currently support only for tag building=entrance. I will add tag entrance=* and investigate your building at Monday.


In v177 I added support for tag entrance=*. It is behave the same as building=entrance so it is possible to setup width or height. One problem is that you set node with entrance on both shop outline and small roof. I think this node with entrance shouldn’t be connected with small roof.

Short description about tagging windows and entrances. But it is not part of S3DB.

Small roof:
Currently the most problem is that it require schema for tagging. For me it should be skillion roof without walls and with some thickness. Marek as always have prepared images and short description for that here. It require some integration with S3DB. So please join to discussion here and add some proposal, images, description how it should be tagged. Implementation of it will be the easiest part :wink:

Currently I have simple switch so I use building parts or building outline. I don’t inhered tags from building outline to building part. The question is if I should? What do you do when relation have two building outlines? In my opinion relation should have always only one outline but what if somebody add more?

I have disconnected the small roof from both (the shop and the large roof) with layer=3. Thank you for the doors at the nodes tagged with entrance=. I also added the doors of the car_wash. OSM2World also understands with= and height=* of this entrance tag.

I remember having seen somewhere the roof with the tagging: roof:thickness:parallel:yes.

An other difference between OSM2World and your renderer is the tag roof:shape=pyramidal. OSM2World takes the roof area (top of the building) and uses this for making the form of the roof - works also with an other node count as four - also with a circle (e.g. node count = 32) to make a cone. But your implementation always uses four roof ridges, while OSM2World uses the node count of of the roof area for the count of ridges. Would be nice to have the possibillity to switch between these modes.


As I said it need to be described, discussed, accepted otherwise it will be changed several times :wink:

Yes I notice this differences. In my app you can currently achieve very similar behavior using roof type=9.0

The problem is that there are buildings with this kind of roof:

In short there is four edge pyramidal roof on non square building outline.

Maybe my implementation of this kind or roof should by named square_pyramidal?

Tordanik what do you think?

I still don’t have relation support yet, unfortunately, so I haven’t given this much thought so far. However, maybe I wouldn’t inherit from the outline at all if there was a relation - then the relation would be represent “the building”. But if there is no relation, then the outline is “the building”, isn’t it?

I agree that both roof types can occur and we need to distinguish between them.

However, reading Wikipedia, I get the impression that your interpretation is actually the better fit for the name “pyramidal” - that seems to imply a rectangular base. Mine would probably better described as a “tented” roof.

At least that’s the case with the German pages (Pyramidendach and Zeltdach). I’m not 100% sure about English.

I added tented roof to kendzi3d. It should behave the same as pyramidal roof in osm2world. Can anyone test if it’s so?

We should agree on common name for this roofs. So proposal are:

  1. square_pyramidal (square base) and pyramidal
  2. pyramidal (square base) and tented

Great! Thank You Kendzi!

For your example of a mainly rectangular building where the outline does not differ much from the minimal oriented boung box using pyramidal the way you do is perfectly fine. – but these are quite a few restrictions that need to be defined to apply this roof type consistently. So how to apply square-pyramidal to something simple as a triangle without having orientation aditionally defined?

otoh for the ‘tented’ pyramidal roof style one would expect the outline to be convex (or applied to the convex hull). It would be good to at least state these assumptions (whatever they are) in S3DB spec.

The same problem is when you want to put gabled roof on pentagon outline. In this situation roof:orientation tag don’t have sens. But you can always use tag roof:direction as discused this

But you are right square_pyramidal has most sense for rectangle like roofs.

To make interpretation of ‘pyramidal’ computable maybe we should list the possible way how to construct the geometries and see which name fits best.
Currently I can think of:

  • square_pyramidal as:
  1. take the minimal object orient bounding box of the outline,
  2. if oobb is not unique roof:direction is required.
    3 connect edges from center (of oobb) to all outline points and interpolate point height between center and oobb.
  • pyramidal:
  1. take the convex hull of the outline
  2. connect edges from center (of convex hull) to all outline points and interpolate point height between center and convex hull.
  • tented:
    1 connect edges from center (of convex hull) to all outline points.

I would also like to have an additional apex node to define a custom center. Any ideas how to model this avoiding additional relations?

[just realizing I was forwarded to a thread where this is also kind of off-topic :slight_smile: moving over to S3DB talk now…]