I’m already working on this issue, it’s the “remove parts from outline” algorithm from Cactusbone that sometimes keep some edges as if they were not snapped.
I will try to detect and fix it on client-side.
If i got enough time today i’ll fill the demo areas links to F4 Map.
Could you switch off volume rendering of building outlines (building=yes), which have tag building:parts (building:parts= ) and don’t have tag building:part= (except building:part=no)? It can help to switch off volume rendering manually in cases, where tag building:parts had been already written by editor.
But considering building=yes with tag building:parts= as a building, which has volume dividing to parts (building:part= ) is correct. If building doesn’t have volume dividing to parts, using of building:parts= is incorrect. Switching off the volume rendering of building, which has volume dividing to parts (building:part= ) is correct, isn’t it?
In other words, not every building with volume dividing to parts (building:part= ) has tag building:parts (building:parts=), but every building with building:parts= tag has volume dividing to parts (building:part= ) and we should switch off volume rendering of such building outlines.
This relation has building:part=roof, but your renderer shows its walls.
I think, it is a mistake.
As I see, man_made=chimney is rendered now, only of there is also tag building=yes, but there are ~11 000 man_made=chimney on nodes, and less then 2 000 on lines and areas. Less than 10% of man_made=chimney have combination with building=yes. What do you think about rendering all man_made=chimney even without building=yes? If we have man_made=chimney at node we can use some standard diameter for chimney, if we have man_made=chimney without height, we can use some standard height.
Buildings with building:parts=true aren’t extruded anymore.
building:part=roof are now handled like building=roof.
Check our changelog for more news
For now we can’t handle man_made=chimney without building=true as our building request is based on polygons so we can retrieve them the same way but we’ll think about that in further updates.
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…
Hedges makes sens, you said “barrier=fence” on last post that’s what confused me
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).
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?
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.