the osm spec has changed, when i did the material/colour code the spec was :
“building:facace:colour/material” specify wall colour/material.
“roof:colour/material” specify roof colour/material.
“building:material” cover the entire building (it was explained as a shortcut for wall+roof tags).
[Edit: building:material & material tags won’t be used anymore for roof on next release]
no, we don’t support tag roof:direction but i could do it in the futur
i need my database request expert to understand what happened to this building, it looks like something filters it from my buildings request.
[Edit: during import, multipolygon lines order makes a self-intersecting polygon so that it is not rendered, we’re fixing it and it should be ok on the map on next release]
this could be discussed, we already talk a lot about that within the team, we plan to use the browser language to choose the best matching name to display.
chris66
Our database relation import does not allow us to handle these tag for now.
We know that buildings are not so close to reality anymore when built on a sloppy spot.
For now buildings:parts are not aligned anymore with their “brothers”, we’re working on a fix to get every parts of a building inheriting from their outline building position.
Looks interesting
Sadly the SRTM is in to low resolution at least for my part of the world, so it looks more odd and a lot of details are missed
So there is still a need of getting a crowdsourced alternative, like http://www.opendem.info
As you started this thread with the intention to get feedback/interaction with the rest of the (3D) OSM community:
Personally, I would really like to please you, to work first on a maximum compatibility with other viewers esp. on the S3DB schema!
Even your visual progress is impressive (and as coder I understand, thats more interesting to work on bleeding edge features), it’s getting really worse for the whole community, if we get different ‘flavours’ of micromapping and everybody has a slightly different interpretation of our tags. If we (the 3D community) want to motivate other mappers to enrich their regions, we have to offer unique tagging guides, otherwise we will get very cluttered results, that are spread all over the world
I agree, but there is the problem that S3DB is a very basic minimum consensus. The world, (and the tagging, of course) is much more complex.
So you are right: We’re at the beginning of 3D-Mapping in OSM. When I fly true the F4 map all around germany, or around the world, there are very few buildings which have 3D tags.
I think, this is good: We see, what we tag, although we are just at the beginning. So we now have the chance to see the problems, to find solutions, and create a ‘complete’ tagging scheme.
So ‘we’ have to do our work. We have to create a Wiki-Page, that is standard, that is the base for all 3D tagging and that include all 3D tags. One starting page, an this has to be the base for all renderers.
So this is the 2nd step. But when I understand the post #11 by cmif4, the base for their rendering is the S3DB scheme.
What are the problems actually, where does f4 map differ from S3DB?
I’ve found, that natural=stone at areas (outlines of big stones) are rendered as areas with many small stones. I think, that is is incorrect rendering: areas with many stones are tagged with natural=bare_rock. Natural=stone - one stone. outline, link:
Yep, it’s Simple 3d buildings and a first step to get away from the basic LOD1 extruded buildings that we had before.
As you might know, we collect our experiences/impressions from the practical tagging with the schema here: http://wiki.openstreetmap.org/wiki/Talk:Simple_3D_Buildings
And some started to play with other approaches e.g. to describe roofs more detailed.
So there is no reason, why this shouldn’t result in a complex 3d buildings schema
Not sure if ''complete" is a good target, as describing 3d this way will always be a compromise between comfort of mapping/tagging and the level of details that you can realise.
Please check the thread backwards to find some problems. Mostly it’s the way how building:parts are mixed and support of all roof types.
A visual check can be done by having a look at the already tagged areas (even with support of our community) http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings#Demo_areas
We had a bug that natural=stone lead to polygons being handled as monolith=alignment. It is already fixed internally and will be ok on further release.
I am following the Simple 3D Buildings talk page but i disagree with most of the “adding complicated stuff in S3DB” because (in my opinion) it wouldn’t be ‘simple’ anymore.
I already got in touch with Kendzi to try to get similar interpretations for skillion roof, height tags, roof shape algorithm… but we’re working with different data input, under different technologies with different constraints (Kendzi3D takes its data from JOSM, OSM2World process data on server side and covers only some dedicated spots of the world, F4Map partly process data in server side then stream it to the browser that generated geometries in real time).
I’m following this topic since i opened it, feel free to discuss here.
