@robgeb : looks like we’re missing some changes from july 29th (including your changes)
I’m not sure how we ended up missing those, my guess is we have a bug after world import where me miss the first changes.
I’ll try to check for it
@pyram : this is weird indeed, data seems good on our side so it should render properly, we’re working on it
Nice to see it back online. However, I noticed you seem to have introduced a gradient shading on vertical surfaces. I urge you to reconsider this decision, because most buildings more complicated than a simple box outline are built with several different layers stacked - which previously blended perfectly into a seamless surface as they were meant (for the simplest example, just think of a “Stonehenge” style portal at a building entrance); now, however, those layers are rather painfully obvious cutting buildings into vertical sections at the seams. Internally simplifying the geometry into a single surface where the sections meet would solve this, but I’d think that would be a seriously major job to do.
Take the pictured chicken-foot-building. If I have the footprint tagged as building=* (which makes sense AND is common OSM practice) and then have a building:part wider than the footprint, this part doesn’t render in F4. So I have to stretch the building=* way to a top-view projection, which I feel bad about. Would be nice to map 3d data without altering the existing 2d data.
I’ve tried what I thought makes sense: instead of the building=* way, create a new untagged way representing the building top-view projection, and use it as the outline role of building relation. The footprint is not included in the relation at all. As you can see here, it didn’t work. The parts wider than the footprint magically disappear, leaving the ground levels and a small floating cap. An identical building to the right is rendered fine because it has its footprint adjusted to the widest part.
Two questions:
Why is the building:part < building constraint even in place?
Why don’t use outline member of the building relation instead?
I’m not part of the F4 team, but as your question applies equally to other 3D renderers, I hope you don’t mind if I reply.
Well, that restriction is not something that F4 came up with, but part of the Simple 3D Buildings specification.
Back then, we decided to specify it for two main reasons (iirc): First, this definition allows us easily identify which building parts belong to a building even if a relation is not used. With your changed definition, that would still be possible for building parts that are partially inside the building outline, but not for building parts entirely outside the footprint (which would inevitably happen for some buildings). Second, almost all building outlines are drawn based on aerial imagery, where the footprint is not visible.
Personally, I think that was the right decision to define it this way. It’s also not clear that the footprint is always what we want in the 2D map, as this would e.g. reduce buildings supported by columns to only a few dots on the map.
The building relation could of course be an alternative for matching buildings to building parts. It doesn’t even require an outline for that, as you can add the parts to the relation directly. But many mappers struggle with relation editing, so avoiding relations where possible is preferable imo.
You’re right, there seems to be no need for a top-down view if the parts are tied with a relation. That outline role should contain the building=* way in order to share its properties with parts. What it should not do, I think, is limit the parts visibility. However, in F4 it does.
Note that the very same Simple 3D Buildings page implies that the renderer should first try to use the relation data to match a building with its parts, and if it’s not present, then fall back to plain old inside/outside criteria. This flexible approach allows for both complicated chicken-foot designs and easy relation-free mapping. I’m puzzled why the F4 renderer dumps the existing relation data and tries to recreate it from scratch using geometry (unsuccessfully).
I’ve fixed a bug with building height with undergrounds part. i’ve also added a default roof type (hipped) when a height/level is specified but no roof type. If you notice anything weird, please report it
Looks like water cooling towers need building=yes to be displayed, is it intended?
Also shading looks funky on these hyperbolic things imgurl (depends on daytime)
…and area fountains generate two jets of water