Real time 3D map using WebGL

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.

The soccer field was partly rendered with 3 surfaces. Grass, sand and tartan. But since today it is ok.

Understand. Wait… :wink:

we’ve located our bug in tile expiration and i’m working on it :slight_smile:

Fix this bug please:
http://map.f4-group.com/#lat=53.0285897&lon=18.6519808&zoom=19&camera.theta=67.993&camera.phi=152.349

fix the bug:
building=commercial
I believe, there are some other values for building=* which are not rendered…
Regards,
Marek

We handle every building tag value but “building=no”.

The “round roof bug” is due to the roof modelling algorithm that is based on minimal oriented bounding box so for now it won’t work on non rectangular shapes.

building values:
look here: http://map.f4-group.com/#lat=48.1320774&lon=11.5312780&zoom=19&camera.theta=69.082&camera.phi=-8.308

Let Your people adapt the algorithm for round roofs. This is often the case.

These buildings have:
_ “building:part=yes” that means we should extrude them.
_ “building:parts=horizontal” that means we should skip the extrusion process.

I’m not a medium but i’m a lazy boy so the code take the easiest: do not extrude anything :smiley:

I can not understand this tagging. Do You understand what the artist mean? :wink:
I guess he wanted to show the horizontal stripes on the facade. For me very helpful feature for rendering of two colours in skyscapers.
Simply ignore building:parts=horizontal in recent form.

Or you use some parts with min_height and height tags like here:

http://map.f4-group.com/#lat=52.2228702&lon=10.5071807&zoom=18&camera.theta=66.944&camera.phi=-67.666

Please talk to each other then i’ll may change the code :roll_eyes:

Or even here: http://map.f4-group.com/#lat=52.4051450&lon=16.9217806&zoom=19&ui.showMenuPage=true&menuPage.type=search&menuPage.id=Poznan&camera.theta=50.518

This approach produces too much shapes and should be used only for irregular structures.
Please give me time for clear specification of this problem and I think, cmif4 can order the adding of this function for rendering.

building:parts=… means, that it is building=…, which consists of several building:part=…, and we should skip volume rendering for such building=…, because we have several building:part=… for such purposes.

For example, this way now has:

Such tagging is, obviously, incorrect.

Ignoring building:parts=horizontal is not a good idea. I think, that better idea is deletion of building:parts=horizontal from elements in OSM database, for which using of building:parts=horizontal is incorrect.

This is redundant, though, because you could just look at the building:part=* polygons and their tags to find out whether they are arranged horizontally and/or vertically.

building:parts is basically your own invention and has not been discussed before it was presented in the wiki as if it was an established tag. Unfortunately, I still don’t think it is useful. The name is also very typo-prone.

Let me say in other words. It is your decision, to use some tag for some your purposes or not. But if you see, that someone’s work with incorrectly used tag leads to incorrect result, you can not say “ignore this tag”, you should say “delete incorrectly used tag from database”. In this concrete case we see incorrectly used tag - the reason of incorrect rendering is not in bad tag, but namely in incorrect using of tag.

For example, we have tag natural=water for water areas. It is your decision, to render it in some way or not. But if someone asks “why does this soccer pitch render as blue area in this render?” and you see, that pitch is tagged with natural=water, you can not say to author of render “ignore tag natural=water, because it leads to mistakes”, you should say to author of question “delete incorrectly used tag natural=water from pitch”.

P. S. Not all software can determine buildings, divided to parts, by analyzing building:part= polygons. There is a software, which use tag building:parts for such determining. If tag can help some software in some cases, why should we consider it as a harmful?