Real time 3D map using WebGL

Yes, very impressive. Worked out of the box on Firefox 15 the first time, although going back a few hours later, I’m no longer offered the choice to switch between 2D and 3D.

I love the fountains and trees. In Munich the river seems to be flowing the wrong way - is this a problem with the underlying ways?

@OliverLondon maybe you could not switch between 2D and 3D because you were too far away, try to zoom in.

I think there are currently 2 problems in your interpretation of S3DB that makes the results very different:

  1. min_height ignored
  2. Inheritance is applied differently
    Please compare your results against the well mapped areas:
    http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings#Demo_area

As J3D says, a on-the-fly interpretation is impressive :slight_smile:

We’re handling min_height as explained in the OSM wiki (check,Petronas Towers, Kuala Lumpur and 26 East 23rd Street, New York)

The inheritance issue may be due to the lack of relation in our database, we’re handling building:part as building without any distinction.

Can you please link me some misinterpretation of the S3DB in our application so that we could have a look.

Here my examples:
http://maps.osm2world.org/?h=128&view=S&zoom=17&lat=54.18032&lon=12.0808&layers=B0FFFF (Rostock Warnemünde)
http://maps.osm2world.org/?h=128&view=N&zoom=17&lat=53.62492&lon=11.41809&layers=B0TTFF (Schwerin castle and surroundings)
As far as I remember I didn’t used a relation either, but of course my modelling can be wrong, too. But I make heavy use of inheritance, as IMHO we specified it at the 3D workshop.

Another aspect might be currently not within the S3DB specs: defaults
So kendzi/tordanik use yellow as basecolor for buildings. Even if your white looks really nice/modern we should try to unite the interpretations. Or no tool makes use of a default colour to show the user, that you need to specify everything?

For now we used 2 default colors for walls and roofs when they’re not specified with osm attributes, we specified a white/gray combo to get and architect sketch look.

I think the differences could come from our interpretation of building size:

total height (defined by ‘height’ or ‘building:height’ or (‘building:levels’*3 + ‘roof:levels’*3)).
roof height (defined by ‘roof:height’ or ‘building:roof:height’ or ‘building:cullis:height’ or ‘roof:levels’*3 or ‘building:roof:levels’*3)
wall height = total height - roof height [- min_height if specified]

Maybe it’s a wrong interpretation of this page mixed with this one

In addition to that i think that the aspect ratio & camera fov differences between your rendering and our make the comparison quite hard.

EDIT:

I just found out that removing the polygons with id=209603824 and id=96820490 gives a mush better look for “Schwerin castle”.
It seems that these 2 buildings are only partly rendered in osm2world.

A understandable decision. Unfortunatly this is different from the way the dev community handles it currently, which can result in artifacts. In the case of the castle, it’s really yellow. If a building is white, I wether specify it with building:colour=white

For now, only S3DB is the only semiformal agreement of the most of the devs. The levels should be only considered, if there is no other height information. Usually it’s just to generate a texture of windows and we encourage users to use dedicated height values to describe the geometry.

This is somewhat true, but O2W (for what I can say) is highly customizable, so you explore areas in the same interactive way as within your client.
I guess you know, that tagging schemas are only semi-formal here at OSM. So you need to consider, how it is used in the wild. Thats why the 3D staff offered the demo areas and example files to show you, how the current interpretation should look like.

Sorry, I have no idea, what you removed :frowning:
But please take care of the “we don’t tag for single renderers rule”.

I removed it locally in my client triangulation to see what would happen, i won’t change OSM data for my personal rendering :wink:

I checked the Schwerin castle in Kendzi3D and found that its rendering is matching mine.

It seams that by S3DB you should use relation for grouping building outline and building parts.

Hello,

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.

Franz

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 :slight_smile:

I saw your edit on Notre-Dame, i originally modeled it to test my geometry extrusion but it is based on this wiki page and these attributes are not defined there.

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.

Here for example the Neptun hotel at Rostock Warnemünde:
http://maps.osm2world.org/?zoom=18&lat=54.17914&lon=12.07683&layers=B0TTFF
http://map.f4-group.com/#lon=1344410&lat=7204050&zoom=18&camera.theta=42.743&camera.phi=-1.719

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

@cmif4: Could you have a look at
http://map.f4-group.com/index.html#lon=980595&lat=6996987&zoom=19&camera.theta=54.472&camera.phi=-128.629

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 :slight_smile:

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 :slight_smile:

That´s true! Let´s talk together about it. Don´t change because some people don´t understand it.
Best regards,
Marek