Open gitToad opened 5 years ago
Just wanted to comment on it. We've added in some basic reading of tags for the multipolygons so the tags trickle down to the individual polys, but you're right if a building is made up of multiple shapes we don't capture that currently.
The one example we saw (MIA airport) had multiple relations using the same shapes, like Terminal 1 and Airport had shared polygons, and I thought the users would probably not want to have duplicate data, but I might be wrong here.
I do see the value of the buildings with holes though, so I'll keep thinking about it
Hello! Relation is really are a problem. Some parts of the maps are missing due. Since OSM is open source, some relation may not be set correctly. I can not draw the outlines of the lake (lake). Let there be excess data, but it will not be emptiness. In multipolygon, there is also the role of the paths "outer" and "inner" - it's easy to use in boolean functions.
Please add all relation, even if all of them will be surplus data and propeties "role". (At least check box for this or propeties "relation"=1 )
Thanks
This is probably more of a missing feature than a bug. Implementing it would likely make things quite a bit more complicated (as OSM relations not just nodes and ways would have to be imported) So perhaps this is just to point it out and perhaps put it into the docs to save other users some headscratching.
Background: OSM represents some buildings - namely those that contain holes in their floorplans like an atrium - as a relation (type==multipolygon) with two separate members. One is the outer, the other is the inner polygon(s). Quite different from regular buildings. The outer and inner ways currently have no useful attribute values that would allow reconstruction of the building (just hou_id, hou_way==1, hou_node==1)
A couple of examples (they are fairly common): https://www.openstreetmap.org/relation/5495938 https://www.openstreetmap.org/relation/1796505 https://www.openstreetmap.org/relation/6480743
One workaround could be that the importer itself reads these multipolygon relations and copies the parent buildings attributes to the outer and inner members which are already represented in the imported dataset as hou_ways. And adds a multipolygon attribute to each, with "inner" or "outer" as the values. Probably a "parent_id" attribute which is the hou_id of the mutual parent building (just a convenient unique placeholder to allow pulling the various inner/outer prims together) This would enable processing of the building prim without bringing relations into the OSM importer mix, just using the existing prims and attributes data structures.