Clean up merging of two building relations

[bwitham]

https://github.com/DigitalGlobe/VGI-team-repo/issues/1283

[bwitham]

Attempting to narrow down what the actual scope of this task is right now.

From the original issue, there are at least three examples shown where users expected a building w/ a courtyard to have matched with another building that had a courtyard. In all three instances, the building in one of the layers had no attribution, not even building=yes, so actually that data can't even be called a building. I've seen hints that maybe the attribution is being dropped by incorrect cutting/pasting in JOSM (?). Hootenanny expects all input data to have at least basic type attribution (poi=yes, building=yes, highway=*, etc.), or the data simply isn't conflatable. So, I think figuring out why the types were missing and getting them added back in is step one.

A follow on step could be to try conflating the buildings w/ courtyards after the types have been added back in and ensuring that the matching/merging is done as desired.

A third part of this task could be detecting courtyards in buildings that haven't been properly tagged. The proper way to tag a building with a courtyard is as a multipolygon relation, building=yes with the building member having relation=outer and the courtyard member having relation=inner. I have also seen a proposal to add man_made=courtyard to the courtyard, but don't think it has been approved yet. Its possible we could try to detect and fix buildings with courtyard features where they weren't tagged properly, but that will be a very difficult task and only should be attempted if there is a supporting use case for it.

[sisskind]

What about kicking any courtyard to manual reviews? Is this an edge case or are there a lot of these situations?

[damianblanck]

Example 1 Example 2 Example 3

Looking at examples from OSM. I think the OSM way to extract these is to not label the ways (outer or inner) as a building but to label the relation as building = yes.

Here is an Overpass query for Baltimore with 263 relations where Building= Yes

Its also always going to have a spacial component where one way will always be inside another one. If you could pre-select all polygons who's centroid is within another but is not bigger that a given area, that might help. This would also be looking at unlabeled polygons. So that might narrow it down further.

[damianblanck]

@bwitham I think from an OSM perspective you need to flip your order above. Part three seems to be where it is at. Maybe we are not bringing in relations the way we should.

Just to confirm that its not an edge case, here is part of Rome with 3136 relations where building=something most seem to render as having courtyards in the middle. Example in Rome Italy

[damianblanck]

investigating a little further. Mroe info on this wiki https://wiki.openstreetmap.org/wiki/Relation:multipolygon With a link to taginfo https://taginfo.openstreetmap.org/relations/?rtype=multipolygon#roles outer 9.331.661 inner 6.760.871

https://taginfo.openstreetmap.org/relations/?rtype=multipolygon#graph

[bwitham]

I think this is largely or completely a problem of someone accidentally dropping the information from the building relation at some point in the workflow. In the examples Curran showed, I would see a dataset with mostly correctly tagged regular buildings but only the buildings with courtyards had their tags dropped. In all of your examples Damian, the courtyard/buildings are tagged correctly, so hoot won't have any problems conflating those (I think, need to test a little more).

If we're thinking of creating a cleanup operation to catch all instances where someone accidentally drops the tags, that may be possible (third part described above). The problem I'm seeing is that if you look at a bunch of polygons with no labels and look for polygons inside of them, what happens when one of them isn't actually a building, and you assume that it is? Although, I haven't been able to find an example yet where there are two way polys, one inside the other, and the polys weren't buildings....but that doesn't mean a non-building feature like that doesn't exist (needs to be proven). However if you know your dataset is all buildings to begin with, then I guess you can safely make that assumption.

I would lean towards being more careful with the data up front vs adding the cleaning op, but we can try to add it if you guys think its really needed.

[damianblanck]

@bwitham I think it was a know issue that in moving the data the relations were not being copied correctly in JOSM. This would lead to these types of errors. https://github.com/DigitalGlobe/VGI-team-repo/issues/1174

I don't think we need to do additional cleaning.

[bwitham]

Ok, thats good...what I thought. thanks. Getting ready to talk to Curran about it. I'm going to assume all the tags are correct and make sure hoot is matching and merging buildings with courtyards as expected. I think that all that needs to be done here.

[bwitham]

Spoke with Curran, and keeping the input data clean is the answer here. We're also going to add man_made=courtyard to the relation inner member part. That is actually still a proposal with OSM, but I think its worth going ahead and adding.

After cleaning up and conflating the first building/courtyard example, Curran was seeing correct matching, but the merging seemed a little off. So, I'll look at that next.

[bwitham]

After adding in the missing building relation and tags, I get the correct behavior of the two building matching and the reference geometry kept. However, the relation members in the secondary geometry remain when they shouldn't...working on that now.

[bwitham]

fixed and merged