Fixing old-style multipolygons wih JOSM

[nebulon42]

Here are some techniques that make fixing old-style multipolygons much easier with JOSM:

Use an Overpass Query or another data extract. Example query:

relation({{bbox}})
  [type=multipolygon]
  (if:count_tags()==1);
(._;>;);
out meta;

This returns all type=multipolygon relations within the bounding box and is ready for export to JOSM via Overpass Turbo.

Use filters in JOSM. I use two of them, one hides the corrected MPs from view and the other marks old-style MP buildings with an address on the outer way as I don't want the address to end up within the relation.

Hiding of fixed MPs: type:relation type=multipolygon tags:1 (set the check marks for active and hiding)
Deactive old-style building outer ways with an adress: building=* "addr:housenumber"=* | "addr:housename"=* | "addr:street"=* | "addr:city"=* | "addr:place"=* | "addr:postcode"=* (set the check mark for active, but not for hiding)

Use JOSM's built-in function Update multipolygon (Ctrl+Shift+B) in the Tools menu. This will move tags from the outer way to the relation upon one keypress. It will not work with old-style MPs with multiple outer ways and seems smart enough to me to prevent something weird happening. But it will also move address tags onto the relation, which is undesirable for me.

It is important to not blindly update things. I have also encountered type=multipolygon with no tags and no tags on the outer ways. The rendering was ok so the MP seemd to be redundant. There are also mistakes where relations only have one member. And I have encountered some ways with a lot of MPs on them, each with increasing number of members. Seems to me like an iD bug that sometime existed.

[HolgerJeromin]

Thanks a lot for the overpass query.

I also found a playground which was excluded from a park. So yes, the inner ways should be checked if a multi polygon is really needed.

[stoecker]

I have also encountered type=multipolygon with no tags and no tags on the outer ways. The rendering was ok so the MP seemd to be redundant.

That should not be the case. Can you give examples? Are you sure there have been no overlaps of identical ways, where one contributed rendering and the other had no effect?

I don't want the address to end up within the relation.

Why?

[ImreSamu]

We can extend the overpass query with the [ created_by ; source ; note ] keys , so we can catch the 99% percent of the old-style polygons :

(
  relation["type"="multipolygon"]({{bbox}}) (if:count_tags()==1);
  relation["type"="multipolygon"]["created_by"]({{bbox}}) (if:count_tags()==2);
  relation["type"="multipolygon"]["source"]({{bbox}}) (if:count_tags()==2);
  relation["type"="multipolygon"]["note"]({{bbox}}) (if:count_tags()==2);
);
(._;>;);
out meta;

Edited: added meta (based on: f78e80a)

[nebulon42]

@stoecker I was imprecise. I only downloaded old-style multipolygons in the first place. So there existed another multipolygon, which was the right one and the one I was looking at was redundant. So the situation was exactly as you described it.

As for addresses I think having them on relations makes it more complex for data consumers as it needs to be. So I prefer having them on points or on the way of e.g. a small house. But of course others may disagree and tagging them on relations is valid.

[ImreSamu]

imho : for JOSM "Update multipolygon" (Ctrl+Shift+B)" functions this JOSM filter is better:
type:relation type=multipolygon tags:1 hasRole:inner hasRole:outer ways:2

If somebody likes fixing a little complex cases :
type:relation type=multipolygon tags:1 - ( hasRole:inner hasRole:outer ways:2 )

[ImreSamu]

JOSM filter for tags:1 or tags:2 with [ created_by ; source ; note , ... ] keys

type:relation type=multipolygon ( tags:1 | tags:2 & (created_by=*|note=*|source=*|attribution=*|comment=*|fixme=*|import=*) )

[wolfbert]

@nebulon42

As for addresses I think having them on relations makes it more complex for data consumers as it needs to be. So I prefer having them [...] on the way of e.g. a small house.

I wonder whether this makes a subtle difference. The building multipolygon defines the shape of the building. The outer ring by itself may define additional objects (namely, an area that covers the whole building or a line surrounding the building).

Putting the address on the outer ring, strictly speaking, does not associate it with the building, but with a line that is in the same place as the building outline (if the relation is deleted, this line with the address remains). It is also not feasible if the outer ring is composed of more than one line, or there are several outer rings (which shouldn't happen in the first place, assuming buildings come in one piece, but for which there are (ab)use cases).

Maybe I'm overcomplicating it, but it seems to me this would be an argument for putting the address on the relation (along with everything else that describes the building), or a separate point.

[nebulon42]

Yes, I have sort of changed my mind since then and think that addresses on relations are just a reality that has to be handled. So I made adjustments e.g. at gmgeo/at-address-compare@ff5edd1.
But I still think a point would be also suitable (or even better) just like you said.