Real time 3D map using WebGL

Thanks for fixing this. Most areas seem to be ok :slight_smile:
There are minor bugs that might result from different defaults (roof angels, …) but they are minimal.

IMHO a nice last step could be to derive simple colors from the xyz:material tag. So brick is somewhat like orange/red, glass is blue, metal is grey, … . Maybe also using default colours as flat roof is grey and angled one somewhat red.
And if you have still time/fun you might add a default for building=garages (here in Germany 1 level buildings with flat roof with multiple doors for the cars)

Sorry, one more question:
I added yellow colour to all building (not part!) elements of the Schwerin castle, but it still appears in white. Isn’t the colour of parts derived from the building, or did it still need time to update the changes? (I edited yesterday afternoon)

Our osm-synchronization server was stopped for a few days so it’s a bit late. It should be synchronized again in 2 or 3 days.

It should now be in sync again.

I’m using ST_Intersects to determines if a part is in a building, but this leads to some parts having many building and i’m only keeping the last one (as returned by postgis), and this could make the part inherits unwanted attributes.
however using ST_Contains breaks some building too when the parts points are not snapped correctly to the building…

any advice as to what’s best ?

Where do you see this issue? I’m still working on my db functions for buildings.
Maybe this could work:

st_intersects(b, p) and not st_touches(b, p)   and st_area(st_intersection(b, p)) > st_area(p) * 0.99

or order by the st_area of intersection and pick the greatest.

BTW I tried to make the description of when to render the building outline more clear:
http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings

It does not state to subtract building:part areas from building area, but this is what OSM2World does and I find it the most reasonable way to handle things:
http://wiki.openstreetmap.org/wiki/Talk:Simple_3D_Buildings#Too_complicated_description_of_building_outline_rendering

The issue Cactusbone was talking about is here but it’s not visibile anymore, i fixed it on osm side by tagging roof:shape=flat

As a picture is better than a complicated explanation look here : .

The building:parts from the white building between the blue and red one sometimes inherit from the blue/red roof:shape=skillion attribute because they got common nodes.

I think your

not st_touches(b, p)

should fix this.

I’ve added st_touches (thanks for that i didn’t know it existed) and 95% area check (great thinking here thanks again!), and i have not yet found another part to building error.

it can take up to 24 hours before buildings refreshes :slight_smile:

@Cactusbone, do you know what the issue with this building is? Or is rendering of the ‘building’ way still disabled when there are building:part inside?
http://map.f4-group.com/#lon=980249&lat=6997486&zoom=19&camera.theta=49.315&camera.phi=-167.2

It has “building:parts”:“vertical” and our old behavior was to consider it as the outline of the relation. I will remove this as we now handle building and parts intersection properly on server side.

Hi, are you planning to add bridges http://wiki.openstreetmap.org/wiki/Bridge (man_made=bridge or relation) and 3d terrain?

Buildings look very good now! One more wish, could you please pick a less saturated brown? :slight_smile:

How to convert OSM lat long to F4 Map lat lon?
I try to add F4 Map link to http://wiki.openstreetmap.org/wiki/Template:Uk:Place

In fact we got a fallback table with color when it’s indicated with ‘words’ (i.e: black, red, yellow…) but if it’s a #ffffff hex color we don’t change it.

OSM is based on EPSG:4326, we’re using ESPG:900913 (you may have a look here for conversion: https://gist.github.com/springmeyer/871897))

We’re not planning to add 3d terrain (even if we got a working solution for that) because it strongly complexifies building placement and camera movements and we don’t want to add performance bottleneck. Adding bridges is linked to having a 3d terrain, without that it’s not very usefull.

F4 Map now uses geodetic coordinates in URL, and I fixed the template.

Thank you very much! :sunglasses:

Hi there you mysterious F4-folks :wink: very nice work you have done, it’s a pleasure to look at OSM this way!

I was wondering how your Flat-Map tiles are created? I couldn’t find any information. How did you achieve the pseudo-3d-style?

Thanks for some info!

Alex

If you already have a working solution, wouldn’t it be nice to make it optional for stronger machines? From my point of view, this would be extremely cool!

Hi, I noticed some issues:

1. Artifacts
See [1] and on O2W. I know such issues, it appeared times before when I missed some nodes that are shared by various building parts but usually this would affect O2W, too.

2. S3D interpretation
This green building looks very different on f4. I guess there are still some problems with defaults or interpretation of S3DB. IMHO this should be a higher priority (incl. all supported types of roofs etc.) if you want to make your map looking right.

3. Mixing weather data
I’m not a lawyer and don’t know how our copyleft affects your final product and all data included. But I recommend to use www.openweathermap.org with the same ODbL to avoid any conflicts with your commercial weather map provider.

4. Scrup as performance killer
Yes, the little plants look very nice, but they just kill my desktop and you see how they need still generated line by line. IMHO this slowdown is to radical.

Currently your map update seems to be paused. When will there be any updates?

Our tiles are created using TileMill and Mapnick we mostly use flat colors and textures for grass, sand… (using the polygon-pattern-file style)

We don’t want to release performance killer features too early to keep an overall satisfying result for most users.

This sometimes occurs when several nodes or ways sharing the same position are not merged in osm.

This comes from our interpretation of building:levels + roof:levels, i’m currently working on a fix for this issue.

In your example the building got conflicting attributes i think it should be simplified (for example i don’t understand how roof:shape=flat combined with roof:levels=1 could work).

I’m not either a lawyer, i’ll ask the team opinion on this.

Scrubs are currently a first version, we’re always working on optimization and performance improvement, for now scrubs and forests are performance killer when applied on large areas.

The synchronization server was paused for a week during the annual F4 team holiday, it should be back to normal in a few days.

Thanks for feedback. I will try to check the green building again.

Concerning the artifacts, I didn’t found any seperated nodes, but call me wrong. Will check this again, too.

Here is another example of obvious S3DB issues:
http://map.f4-group.com/#postProcess.enabled=false&lon=12.1114729&lat=54.0748619&zoom=19&camera.theta=74.239&camera.phi=-112.873
http://maps.osm2world.org/?h=128&view=W&zoom=18&lat=54.07494&lon=12.11015