gradient shading on vertical surfaces removed until we can fix it ! thanks for the report !
Thanks, it’s looking good again. 
Great map, having a fun time 3d-modelling. One thing I don’t understand though.
Same thing illustrated here: http://wiki.openstreetmap.org/wiki/OSM-4D/3D_building#Building_outline
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?
Hi shrddr, welcome to the OSM Forum. 
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).
yep, we need to work with relations. I have no idea when we’ll have some time to look into it 
There is no exception to the rules for the building outline when a relation is present, though.
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
img url (depends on daytime)
…and area fountains generate two jets of water 
areas of fountains generates multiple fountains indeed, this is intended
shading glitch is the building shading itself, kinda hard to debug 
indeed cooling towers requires building=yes to be displayed, i’m not sure why though …
Some dome roof buildingpart weirdness
levels=18, min_level=2 → 2 levels shorter then it should be
levels=16, min_level=4 → 4 levels shorter then it should be
levels=13, min_level=10 → no walls + a roof at level 3
levels=11, min_level=8 → no walls + a roof at level 3
levels=9, min_level=5 → no walls + a roof at level 4
However, if you change roof shape to pyramidal on these parts, everything works as expected.
good catch ! seems like we’re doing something wrong for dome roof with min_level.
http://wiki.map.f4-group.com/wiki/3D_Render#Colors
there’s something off with dictionary colors… roof:colour=green is not rendered as #008000, but as #66CDAA instead (same as mediumaquamarine)
yep we’re using another color mapping on top of this one to prevent “lego rendering”, so green ends up as #55C29A
http://demo.f4map.com/#lat=53.8913337&lon=27.5506650&zoom=18&camera.theta=52.785&camera.phi=148.858
At zoom 18, streetlamps’ height changes depending on the camera position
Could it be a wrong rendering:
http://demo.f4map.com/#lat=49.5874579&lon=11.0081891&zoom=20&camera.theta=39.32&camera.phi=-32.945 ?
http://www.openstreetmap.org/way/49132126
Also: why are roof:shape=gabled in this care rendered flat:
http://demo.f4map.com/#lat=49.5842082&lon=11.0118811&zoom=20&camera.theta=53.071&camera.phi=13.751
http://www.openstreetmap.org/#map=19/49.58479/11.01126
Best regards,
Marek
Was ist falsch? Kein roof:shape = keine Dachform für’s Rendern.
Vielleicht solltest Du ein Gebäude insgesamt für 3D aufbereiten und nicht nur kleine Teilgebäude. F4 kann in Deinem Beispiel keine Verbindung der Gebäudeteile finden (der Umring wird ignoriert, wenn ein oder mehrere building:part erfasst wurden) und daher auch kein Gebäude errechnen. Ein 3D-Gebäude nur mit Dachform und keinerlei Höhenangaben? Ich finde das konsequent, weil es oberflächliche Arbeit nicht unterstützt (Sorry, wenn das jetzt hart klingt!). Man sieht dann auch gleich, dass es hier noch Arbeit gibt - ansonsten brauchen wir ein Qualitätstool, das unvollständig erfasste Gebäude findet…
Stimmt nicht. In diesem Beispiel sind die roof:ridge und roof:edge Linien vorhanden.
Und roof:shape=gabled wird seit Kurzem auch nicht für einfache Einzelgebäude gerendert wo man keine Relation benötigt. Beispiel: http://demo.f4map.com/#lat=49.5829910&lon=11.0089616&zoom=20&l=l
http://www.openstreetmap.org/way/229683578
Das bestreite ich nicht. Ich denke aber, dass F4 das nicht unterstützt. (Wird am Montag von Cactusbone beantwortet!?)
Das Gebäude hat keine Höhen irgendeiner Art. Das ist aber wohl das Minimum. Schließlich fängt man mit LoD1 an (Höhen) und macht dann mit LoD2 weiter (Höhen+Dachform). Natürlich kann man das umgekehrt erfassen. Man sollte aber nicht erwarten, dass alles unterstützt wird.
Es wird unterstützt. Sehe z.B.Neustädterk Kirche in Erlangen:
http://www.openstreetmap.org/#map=19/49.59567/11.00566
Die meisten Gebäude in Erlangen haben keine Höhenangaben, die Dächer (gabled) werden aber gerendert. Nur die neu eingetragenen gabled nicht.