I think, I have to correct you. You have defined ‘roof:height’ and ‘building:cullis:height’ as the same, but they are not! As seen on this wiki page the ‘building:cullis:height’ is the height of the top line of the wall just below the roof, not the height of the roof. I see it as the min_height of the roof.
Infact the code does it that way, the fallback for roof_height is building_height - cullis_height. I guess it really doesnt matter for now as in 99% of the cases cullis:height is used redundantly and for some other cases with wrong values (cullis_height > building_height - roof_height). It’s not in S3DB, but for rendering it would be nice to handle the case where a gabled roof extends over the building outline, i.e. when cullis_height < building_height - roof_height. (at least that is my interpretation for roof/cullis height)
I’m missing roof:shape=skillion,roof:slope:direction for Notre Dame Cathedral and roof:shape=round
Ok after reviewing lots of buildings, I really think, that the biggest problem is that you currently don’t use inheritance.
So you get wrong results, if someone specify the building with a height x and pulls parts artifically down.
P.S. For me it’s often hard to recognize the shape of the roof, as it’s often white, too. I’n most cases at least here in Germany a flat roof is grey and gabled/hipped roofes have a somewhat red/orange colour. Maybe this will help people and allow a better shading of roof elements.
Stop me if i’m wrong but to get building:part inheriting from its building you need to do a complex intersection code to see if they overlap and this is a time consuming process (we’re extruding buildings in real time on client side).
Btw we handle the building:parts tag, when a polygon got this flag we consider it as the outline and it is not extruded (it would fix the Neptun Hotel)
We are not handling this part of the spec for performances reasons.
The building:part inheritance is not that simple to do client-side. It can be done efficiently with the database query using PostGIS function though. It would also allow to let the buildings parts have the building id so that the whole buildings can be selected as a single object. I would suggest to write a (pl)sql function that just takes the tile coordinates to build the result, similar to https://gist.github.com/hjanetzek/5763848
I’ve just updated it and it now works with both kendzi3d and osm2world.
One thing I noticed is that you are the first to be strict about not rendering the ‘building’ outline unless it also has building:part=yes. I would like to discuss this case on the Wiki as in my opinion building:part=yes should be the implicit default (which, when really needed, can be turned off with building:part=no) This is also what I guess most people have done (applied only the tags nescessary to make it look right) I ran into the special case whare i would have liked to turn off outline rendering but couldnt with a previous version of the example linked. So you are correct here but might consider the more common tagging style in this case …
There is the comparison between our rendering on this church (you can’t see the changes by yourself as the release server osm synchronization was down but i made a screenshot from our map on the dev version)
We got a differences on :
_ non squared pyramidal roof
_ height of the roofs yours seem to be slightly higher
_ our algorithm does not handle skillion for now (we should work on it soon)
_ the building on the right side is built with complex relation that we do not handle
I believe the interpretation of pyramidal roof for more than 4 corners is still under debate. I would vote for the ‘shed’ style that you have as it’s already the more common* use and for the squared-pyramidal style it is really hard to define how to apply it consistently.
(* http://overpass-turbo.eu/s/l6, imported to JOSM and compared to bing)
Do you scale height according to ground resolution in mercator projection (relative to latitude) ?
Yes, it’s using a proposed tagging. I’ll fix it to also use proper tags for S3DB when possible.
And because of that where was proposed in S3DB relation which group all building outlines and building parts. When relation exist it is trivial to render building correctly:
if relation exist and have members with building:part tag => render all building:part=* from relation
if relation exist and don’t have members with building:part tag => render all building=* from relation
if relation don’t exist => draw both.
Relation give some more benefits as they group all building members for selection or they can define common ground level for all bulging parts.
Currently as I known only Osm2World try to guest without relation which building outlines should be hidden. Many people tags for this render.
I try to make discussion here but it seams no one is interested in it. So as most application render it this way I will change it in next Kendzi3d release. In my opinion squared-pyramidal roof can be apply consistently as the same any other roof
@cmif4: I was curious how the postprocessing looks (It does not work on any linux machine I tried). Chrome webgl inspector shows that no UV buffer is bound for the texture plane. As a work-around changing
“vUv = vec2( uv.x, 1.0 - uv.y);” to " vUv = vec2( clamp(position.x * 2.0, 0.0, 1.0), clamp(position.y * 2.0, 0.0, 1.0) );" in common2D.vshader to translate position to uv coordinates makes it work here. I would suggest to check why the buffer is not created in the first place :). WebGL inspector also show lots of warnings when capturing a frame which might have to do why ground textures do not show on OSX (using chrome) http://pastebin.com/etN0yGEM
Thank you for this report,
i was already aware that my outline/ssao code was not working under Linux but the uv code you gave does not work on windows (it renders only 1/4 of the screen)
This works for me under windows
vUv = vec2(position.x + 0.5, position.y + 0.5);
But the real issue is that linux driver “loses” my uvs (on JS side they’re ok as i’m using the same kind of geometry plane for post-processes and ground tiles).
I got a similar issue with MacOs where fountain/smoke particles receive the normal instead of the vertexColor (with right values on JS side).
I now have a integrated GL debugger in the engine so i’ll have a Mac cleaning task in a few weeks
We’re now handling the scale factor from lat and got the same sizes as in kendzi3d.
We are working on round/gambrel roofs and we expect to get your building:part (pl)sql function working soon (tyvm for the tips).
Ok, the issue depends on wheter the gl driver does strip unused attributes: When the postprocessing quad is initialized “depth” shader is the active material which does not use its “uv” attribute. That is why UVBuffer will not be created for the quad that should later be used by “outline” material, etc
changing material to something that uses uv before (first run of) update in postprocessing makes it work:
Ty for investigating it (i was a bit busy on roof triangulation and real sun light direction this morning).
Btw i think that Linux driver is more optimized than windows one because my depth vertex shader is using uv but the linked varying was unused in the fragment shader (removed by some #define), i presume Linux driver looks for unused varying stuff on fragment shader and remove them.
Server has been updated a few min ago you should get PostProcesses working fine now
Thanks for fixing this. Most areas seem to be ok
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)