Real time 3D map using WebGL

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 :slight_smile:
but yes it’s best to add them, for renderers using them and for the future.

I’ll check what’s wrong :slight_smile:

@robgeb : looks like we’re missing some changes from july 29th :confused: (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 ! :slight_smile:

@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! :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.