Imprecise description by me, sorry. Shown yes, but not with height/levels:
Nürnberg, Nansenstraße 21, Söderblomstraße 27 and Bernadottestraße 31
Also wrong:
http://demo.f4map.com/#lat=49.3899989&lon=11.0321651&zoom=21
Nürnberg, Geigerstraße 61 and 67- 69 should have an simple gabled roof.
http://opensciencemap.org/s3db/#scale=19&rot=-29&tilt=63&lat=49.39&lon=11.032
Thanks
The thing is, building parts in that area are inside actual buildings, but they are not connected together with a relation. This is what I mean: http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings#Building_relation
@pyram: same problem as above - there is no relation to connect parts to the building. Yes, I know different pieces of software interpret this sort of thing more or less forgivingly, but there really should be a relation…
Yes, I know. But it’s not the problem. I’ve mapped hundreds of buildings (some much more complex) and all are rendered perfectly. My building parts are always completely within one building and fill it completely - so no relation is needed. (@Cactusbone: Or not?). Such relations are only collecting relations and I do’nt like them.
And that is why I said that some applications are more forgiving about the relation being there than others. However, it is my perception that it’s the generally agreed upon way to do things, whether or not it’s strictly required in a specific target. Kendzi himself, the author of the JOSM building plugin stated a similar opinion multiple times - see http://forum.openstreetmap.org/viewtopic.php?pid=362193#p362193 and http://forum.openstreetmap.org/viewtopic.php?pid=363928#p363928
about relations for buildings, f4map do not use those at all right now. so adding them won’t fix anything for those buildings 
but yes it’s best to add them, for renderers using them and for the future.
I’ll check what’s wrong
@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
@pyram we’ve found 2 bugs here, this should be fixed. Thanks for the report !
@Asztalos Attila Oszkár : it looks like it also fixed http://demo.f4map.com/#lat=46.5464942&lon=24.5672072&zoom=20&camera.theta=65.054&camera.phi=-113.045
Excellent! Thanks!
Hi all. What about deciduous trees shown taken its leaves off at autumn and winter periods, ofcourse latitude dependently.
Demo seems to be down for a couple of days.
Is it going to be revived?
yep, our postgresql ended up with corrupted data so we’re reimporting it all… it should be up today i hope !
It’s back online ! sync should start catching up soon
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.
do you have a link to an example of the problem ?
Sure, basically every building has that problem somewhere… the simplest case would be this (this happens to anything gate-like, with a “hole”):
http://demo.f4map.com/#lat=46.5475630&lon=24.5657969&zoom=20&camera.theta=61.562&camera.phi=-88.808
It also affects anything with a wall-roof transition, like the round roof and the wall below it here:
http://demo.f4map.com/#lat=46.5460246&lon=24.5633714&zoom=20&camera.theta=54.167&camera.phi=-74.198
This building got particularly striped, because of the way it’s layered:
http://demo.f4map.com/#lat=46.5350075&lon=24.5944891&zoom=20&camera.theta=61.043&camera.phi=-120.321
Another example where both the building (at the top) and the tower (the geometry is fine, but there is no vertical break in the texture of the tower in real-life) are affected:
http://demo.f4map.com/#lat=46.5228385&lon=24.5986932&zoom=20&camera.theta=56.173&camera.phi=63.885
ouch 
looks bad indeed, we’ll disable it soon
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: