Let me say in other words. It is your decision, to use some tag for some your purposes or not. But if you see, that someone’s work with incorrectly used tag leads to incorrect result, you can not say “ignore this tag”, you should say “delete incorrectly used tag from database”. In this concrete case we see incorrectly used tag - the reason of incorrect rendering is not in bad tag, but namely in incorrect using of tag.
For example, we have tag natural=water for water areas. It is your decision, to render it in some way or not. But if someone asks “why does this soccer pitch render as blue area in this render?” and you see, that pitch is tagged with natural=water, you can not say to author of render “ignore tag natural=water, because it leads to mistakes”, you should say to author of question “delete incorrectly used tag natural=water from pitch”.
P. S. Not all software can determine buildings, divided to parts, by analyzing building:part= polygons. There is a software, which use tag building:parts for such determining. If tag can help some software in some cases, why should we consider it as a harmful?
A tag shouldn’t be ignored because it is sometimes used incorrectly. You are right about that.
The reason why I suggest to ignore building:parts=* is different, however: Because it is redundant, and burdens mappers with a task that should be done by computers.
There are other reasons to determine the parts belonging to a building. For example, the parts are generally understood to “inherit” attributes such as colour from the building. Furthermore, placing parts without grouping them to a building will also cause problems if you place them on a terrain surface, which would introduce unpredictable vertical shifts. So the tag does not actually free software from that task (and even if it did, I would still consider it questionable to trade mappers’ time for CPU cycles in this manner).
Great.
I would suggest adding of couour tag for every possible elements. Of Course we have it more detailed for the buildings, bot there are another elements like e.g. street lamps etc…
Approximation of circle by use of closed semi-circular polygon from the ground floor shape
Use as “height” for this element calculated radius.
Resulution of segments in ground floor by use of closes multipolxgon shape which is drawn.
In z-direction resolution depend of calculated radius. In this case i would say app. 6x dividing…
Thank you for the help proposal but we’re already updating potsgis to get the StraightSkeleton computation done on server side, then i will be in charge of the roof refactoring on client side.
I hope we won’t spent too much time on this improvement
Well,
this is the 3D community discussion portal.
And, this is doocracy. The people do, what works. And this idea is obviously and comes by the way not from me.
The users from the polish community and some italian friends suggests me such solution.
I currently try to figure out to create proper ‘gabled’ roof types from the outline skeleton. It seems to be reasonable to extend only those ridges nodes to the outline which have two incoming edges that directly connect to the outline and where the edge pair must roughly have an angle of 90 degrees and point away from the ridge.
Well,
it´s impossible or probably impossible with the recent definition. I´m working on the new definition for such purposes.
The answer is - please wait some weeks.
Es tut mir Leid, dass ich Dir keine bessere Antwort momentan geben kann. Da tut sich aber was.
