Real time 3D map using WebGL

This is now fixed on server side.

This is now handled properly with a 1m radius building.

Please use for barrier=fence also area=yes tag for rendering of volumetric bodies.
Also highway=footway with area=yes for rendering of ways as surfaces…

Best regards,
Marek

Can you please be more precise, i’m not sure to understand what you mean.

This is already handled but we sometimes got ordering issues on overlapping areas (i.e: footway as area within a surface=grass or leisure=park).

It´s easy to understand.
Look here: http://map.f4-group.com/#ui.discoveryOpen=false&lat=53.0287356&lon=18.6555022&zoom=19&camera.theta=46.768&camera.phi=-12.318

Hedge can also be an area and not a kind of wall :wink:

You have to remove grass or leisure surfaces from such areas.
I know, it´s not so easy…

Hedges makes sens, you said “barrier=fence” on last post that’s what confused me :smiley:

I’m working on graphic details optimization/improvement i’ll try to push this request in my refactoring (i could also handle barrier=wall + area=yes).

PS: this could lead to unexpected results on some polygons i.e: a pedestrian area surrounded with walls will get highway=footway + area=yes + barrier=wall/hedge and i would fill the whole place with a wall/hedge. Not sure if it exists in OSM for now but it would be hard to handle.

Sorry, my mistake. Of course- hedge…
Wall with area is a good idea. I have already described in OSM-4D Definition.
Unexpected results: Its easy: Yu may cot the wall in 2 segments and this problem is fixed…
Do You already support several natural=tree geometries?

Yes we’ve got 3 models for trees: deciduous, conifer and palm.
I try to deduce it from tags “tree”, “type”, “wood” or “species” using some voodoo regular expressions or using latitude to semi-randomize type.
From pole to equator we’ll add only conifer then deciduous+conifer mix then palm+deciduous mix.

In such cases the barrier should be tagged as a separate way (might use the same nodes), so a strange rendering for this would be fine (so people notice this error).

cmif4, about trees geometry:
Please look here - http://wiki.openstreetmap.org/wiki/Tree_table#Types_of_crown_geometry
This is the result of discussion with dendrology specialists.

Best regards,
Marek

I already saw your crown geometry page, it is quite precise and complete but for now there are only 79 usage of crown_type tag, so it is not a priority to us.

What´s first? Egg or chicken? :wink:
Nobody do it, because no rendering.
You can use the crown geometry without knowing which species is it. It´s more easily than to decide which sort of tree is it…
Thank You for adding of area definition. Looks much better.

Best,
Marek

Next release will handle some fallback to your crown_type definition with our actual models:

A or B → deciduous
I → palm
H → conifer

We may add more model shape in the futur.

Hi,

I made a 3D model of ORCO Tower in Warsaw:

http://www.openstreetmap.org/browse/relation/3190068

While Kendzi3D shows it correctly, the F4 has some (like half =} ) completely missing parts and some other visible in a strange way (for example http://www.openstreetmap.org/browse/way/237160224 in some direction has the walls, but only from inside - outside they’re invisible). Is this the problem with the renderer or maybe with the model?

I used successfull different tree geometries for city modelling already 2004:

Some cadastrial offices have databases with trees |type definiton | width | estimated height | position.
Just ask. They have often only excel sheet and provide such models.
If You do more different tree models, your visualization could be interesting for dendrology students. They have no tools for visualization and during of practical work collects such information…

You are using “building:max_level(s)” but this tag is not defined in the specification, you must use building:levels instead to get something right.

Thanks for your quick response and the hint! I repaired all the tags and will look at the rendering when the data in F4 will refresh. I don’t know how to be sure the changes are in effect, but F4 tends to be refreshed pretty fast.

However that still doesn’t explain the problem, since the main tower was badly tagged the same way as the others, but this one is visible, while few others weren’t. So the real problem has to be something else than the tag you suggested. And there are two more parts, which has another issue: they are displayed, but incorrectly (one of the walls is “translucid” from the outside but “solid” from the inside - I can look inside because of the missing roof). Which suggests me we have at least two problems, putting the “building:max_level(s)” tag aside.

(If you want to know exactly which parts are invisible and which are badly rendered, just let me know here.)

hy, this looks a bit weird:

http://map.f4-group.com/#lat=52.2186822&lon=10.5054918&zoom=19&camera.phi=-33.346

does it take more time to render the tiles, or does there excist an problem?

(I changed some amenity and surface tags there about a week ago)

tiles are cached for 1 day client side, 1 month server side. we seems to have some problems with server side tiles not expiring properly when an osm change occur, we’re still working on it. what’s the exact problem you’re seeing ? taking a look at your url, I notice a white square near the rails but that’s it.
Thanks for the feedback!

cmif4,
please add a rendering cathegory
highway=traffic_island.

According to taginfo this value is just a big mess, we would handle it if the contributor find a compromise on how to use it properly.