I highly recommend, that at least the interpretation of buildings should be checked against the S3DB schema and compared to OSM2World and Kendzi interpretation. Otherwise, people might start (wrong) editing, if you roll out, because they expect the tags on the buildings to be wrong. After a short check, currently none of my multipart buildings look completely right.
My questions is, why didn’t you used one of the already existing converters, as OSM2World for example to create your vector tiles?
Concerning the question of kendzi, IMHO, your 3D object DB is derived from OSM dataset, thus it needs to be licensed under the terms of the OdbL? So I expect that Kendzi can take the models under the terms of OdbL?
P.S. Small note: Currently you lack osm attribution.
I’m definitly not a legal expert, but from my POV:
OSM dataset is ODbL and the base for that computation
It’s enriched with ‘magic’ (extruding houses, applying 3d markers, …)
this new dataset is combined and saved in a 3D database
If you reflect the complexity of the single objects, I (personally) would expect that the whole dataset (and so every single object that is complex enough) is licensed under the same terms. But maybe this is a good question for OSMF LWG, this is just my intuitive feeling
Actually the building models are created on-the-fly from raw osm2pgsql data on the client, which I find really impressive
Regarding your concerns; would you say one has to make a font freely available when creating tiles for a custom map style? I would think this is an analogous case here
We are not using a converter nor a ‘3D database’, the extruded stuff you can see on the map is computed client-side on the fly.
The osm copyright was displayed in the legal page but i just realized this page is not accessible anymore since the last UI refactoring (some heads will fall tomorrow…)
Concerning the “real” 3D models (the tree, the lighthouse, the Eiffel tower…) they were modelled in Maya and exported in a specific binary file format and so are property of our team.
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?
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]
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
But please take care of the “we don’t tag for single renderers rule”.
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
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.
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
