F4map.com was the 3D renderer, user did check their tagging with. Now we have Urban Eye 3D and should also have a full OSM 3D viewer. F4 looks gerat but lacks quite some details and accuracy of roofs i.e. It also implemented some ways to interpret 3D tagging, other rendered don’t have. So wie should list and discuss, what advantages and disadvantages are there. (If you have things to list, please add the OSM ID in your comment)
The difference in appearance was mostly because the roof did not have any height information, and OSM2World assumed a lower default height than F4 Map. I’ve since added a roof:height tag in OSM.
There is still a difference in that F4 Map apparently assumes there are no vertical elements on a building=roof at all, whereas OSM2World does still close off the front and back openings of the round roof shape. Without explicit tagging, I don’t think it’s obvious that one assumption is more correct.
Now it’s nice! And the glas openings and roofs around look really good.
Many used the F4 assumption, so we at last need a way to tag it to get the same view.
Something like building:material=none? height=0? …
From my perspective, the whole idea of bulding:part=roof is to suppress vertical elements, because it case of round or gabled roof those emblements are walls. (This can be easily verified by looking at which edges roof:colour is applied and which ones building:colour is applied.)
If one wants front and back sides be closed, it is no need for bulding:part=roof. In such a case just set roof:height=height [-min_height] , and that’s is.
Agree on that. If you are out of OSM2World coverage it’s kind of the only option to get a result out of your data, considering kendzi wasn’t working. Now with having Urban Eye in jOSM that advantage is reducing. At least on my end.
We have countless residential buildings here with a permanent roof over their garden terrace affixed with a long side to the building. No matter how many floors, F4 will attach it to the top of the highest floor of the building unless you specify at what height the roof starts. With Urban if you don’t it makes some height assumption too. On a 1 storey building that side affixed roof will float somewhere way above like were it a 2 storey or so. On one that was sloped/skillion had to play with a (building) height value to get it down to the ground floor and a roof:height, orientation and direction to show with a slope. That causes the sloped sides render to show as were they closed to the lower side of the terrace roof. Think of it as a fuel station cover but than at a tilt. Has no sides but for the pillars it sits on.
IRL, the station roof in the original post isn’t just open towards the ends, though. There’s at least some metal mesh as a vertical element (not sure if there’s also glass or not).
Does that mean it shouldn’t be mapped as building=roof?
I’ve looked around a bit while taking a walk yesterday, and while it was indeed more common than I had previously assumed for gabled roof building parts to not be closed off, none of them had a bottom. Which is what you would get if you just map it as a standard building part with min_height.
So either way, it feels as if we need a solution to control the presence of a bottom and/or walls.
I’ve filled the columns for the 2 renderers which I maintain, and the column for OSM2World according to my experiments with osm2world-as-library. The column for OSM-BI is blank, because I have not any practical experience with it.
So @Tordanik feel free to correct cells if I mixed something up. @karlos, please fill the column for OSM-BI. Also, fill free to fill the cells for F4 Map (if you are sure how it works in the described cases).
After it is done, I will rename the page, moving it to a more proper place, probably 3D development/Comparison of 3D renderers’ features
This thread seems to be as good a place as any to note some (welcome and unwelcome) roof changes in F4map recently (maybe around 23Oct’25). So this is one perhaps for @Cactusbone if they see this, to check if something is not as meant.
Since the last big roof rework (5-6yr ago now), more complicated building shapes (L-, T-shape and more complex plan shapes) have had decent attempts at rendering gabled and other ridge roof shapes, with roof:orientation left unset - recognising there are actually 3 cases: ‘along’, ‘across’ and ‘its complicated’. For some reason, 4-cornered shapes with roof:orientation unset (should default to ‘along’) sometimes, seemingly at random but consistent over time, got somewhat mangled gables. Looks like this is fixed now with the recent change, which is great. (Explicitly adding roof:orientation=along was always possible but only added in prominent cases).
However, a (big) downside at the recent roof processing change is damage to the rendering of skillions - specifically any skillions on building (parts) with a non-horizontal gutter and/or ridge line. So for many cases, no problem. But it seems now that skillion face nodes are either allocated to the top-most height or the bottom-most height, and not at linearly interpolated heights according to the roof:direction vector. Consequently, 4-noded skillion faces can get an unwanted fold (eg 3 high 1 low; or 2 high and 2 low but top and bottom edges are deliberately not parallel, see example below) or be otherwise misoriented/reshaped. And it’s not just correcting tiny height differences, it can be metres. Here’s a couple of examples of larger sloped facets with the new (wrong) rendering and a (green line) sketch of the approximate correct face:
And there are plenty more cases where skillions have been used to make up complex roof shapes out of tri or quad facets on even more interesting shaped buildings, with now ugly steps and gaps.
I think the skillion changes need to be rolled back, it’s always been perfect before.
(This can be easily verified by looking at which edges roof:colour is applied and which ones building:colour is applied.)
