Real time 3D map using WebGL

Excellent! Thanks! :slight_smile:

Hi all. What about deciduous trees shown taken its leaves off at autumn and winter periods, ofcourse latitude dependently.

https://getsatisfaction.com/f4map/topics/support_seasons

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 :frowning: looks bad indeed, we’ll disable it soon :slight_smile:

gradient shading on vertical surfaces removed until we can fix it ! thanks for the report !

Thanks, it’s looking good again. :slight_smile:

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:

  1. Why is the building:part < building constraint even in place?
  2. Why don’t use outline member of the building relation instead?

Hi shrddr, welcome to the OSM Forum. :slight_smile:

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 :confused:

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 :slight_smile:

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 :wink:

areas of fountains generates multiple fountains indeed, this is intended :slight_smile:

shading glitch is the building shading itself, kinda hard to debug :frowning:

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.

img1 img2 url