Check for two or more multipolygons sharing the same outer way

[danfos]

While fixing old-style polygons I see semi-often that there are two or more multipolygon sharing the same outer way. Often, the inner ways are not (completely) the same so I think that one user created the first polygon to get a "outer-inner" and the next user wanted to do the same but was not aware there is/was already a polygon.

Example:

Most of the times you can merge the two relations deleting one of them.

[mboeringa]

In one instance I fixed quite some time ago, I encountered almost a dozen similar MP relations in one location, where each subsequent MP had one or a few inners more than the previous one.

It is way to easy to copy a relation in JOSM...

There is a special button for it, and it unfortunately sits right next to the button for modifying a relation. This means that if people accidentally hit it while intending to modify an existing relation, they may create a new relation without even knowing it, as it will have all the members and properties of the original. This is especially likely with novice JOSM users.

It would be good if JOSM somehow warned for this type of (accidental) misusage in the interface, maybe even simply showing a blocking modal dialog with the question

"Are you sure you want to copy an existing relation? Yes/No".

[joto]

I suggest opening a ticket in the josm tracker.

[danfos]

I just updated the initial entry with a more clear screenshot.

For what @mboeringa is reporting a JOSM issue is indeed the best to do, but I am wondering if it is possible to add a check and post the statistics for this on the Statistics page. That way it is clear how "big" this problem is.

[HolgerJeromin]

IMO it would be correct to model the full area (only outer) as a MP leisure=park and the outer plus inner ways (lake) as a second MP with landuse=grass. Most people would say the lake is part of the park but not part of the grass

[danfos]

@HolgerJeromin I think your comment was for the previous version of the picture I uploaded...

[HolgerJeromin]

I just wanted to add that there are valid use cases for having the same outer ways. This is probably important when generating stats

[joto]

@HolgerJeromin Yes, there are definitely valid cases here and I don't know how to distinguish between valid and, lets say, questionable cases. We would have to look at the tags of all objects involved. As long as we have the total mess of the old-style multipolygons this is even harder to do right. So I'd think this is something we can keep in mind for the future and have a look once the old-style multipolygons are done.

[danfos]

Re-reading what @HolgerJeromin wrote I agree that that case is a valid case, but at the same time I think it is a very unlikely case:

• In most cases the outer with "leisure=park" will be a single way and that same way will be the outer for the MP landuse=grass
• I did never see this kind of constructions fixing over 50 groups of MP's sharing the same outer way

The "Errors: Duplicate segments" has with it "This is often, but not always wrong." which would also cover the exceptions.

For this kind of check the overpass API is not useful while I think it is relatively easy with the dataset that is used to generate the current graphs on the statistics page.

[HolgerJeromin]

In most cases the outer with "leisure=park" will be a single way and that same way will be the outer for the MP landuse=grass

Will this render right? I would suspect this would be interpreted as a confused tagged old style multipolygon.

[danfos]

If it will render right I do not know, but as far as I know things should not be done because it renders correct.

An outer way with "leisure=park" with that same way being the outer for a MP landuse=grass will not be confused as old style multipolygon as an old-style MP is a MP that has no tags other than "type=multipolygon" and tags like comment= or source= as far as I know.

[HolgerJeromin]

If it will render right I do not know, but as far as I know things should not be done because it renders correct.

But it would influence what mappers actually do :-)

[wolfbert]

On a possibly related topic (see #26):

The wiki pages on multipolygons ([1], [2]) state that

when the relation has tags, the tags on the outer ways should be ignored

This is true only for the area in question. In another pass, the ways are processed by themselves (without considering the multipolygon relation), and this may in turn create new areas. Also, other MPs may make use of these ways, creating yet other areas, all of which may or may not be in conflict with each other.

For instance, a building MP with building=* in the relation as well as on the outer way will sometimes (but not always, maybe due to old tiles?) be rendered (correctly!) as two buildings on top of each other. Use leisure=* or amenity=* on the outer way instead and it makes perfect sense.

I understand it like this: the multipolygon relation defines an area (excluding the holes), and what this area stands for is tagged on the relation. The ways just happen to be used by that relation, and may be used otherwise, with different tags, and/or in different relations, to describe other things. It is up to the mapper to correctly employ these possibilities (a non-trivial task).

[danfos]

While fixing multi-polygons in Poland I saw one more extreme example:

One outer-inner MP for every inner...

Fixing this I downloaded an area along the other way and found there was even one more MP with 17 inner ways that was tagged as "landuse=forest" so that was not downloaded when using the JOSM overpass query.

Eventually fixed this by moving all inners to the "landuse=forest" MP and deleting all other MP's.

[mboeringa]

One outer-inner MP for every inner...

Fixing this I downloaded an area along the other way and found there was even one more MP with 17 inner ways that was tagged as "landuse=forest" so that was not downloaded when using the JOSM overpass query.

Eventually fixed this by moving all inners to the "landuse=forest" MP and deleting all other MP's.

This is exactly the same type of issue I encountered in Belgium and fixed quite some time ago... Now with Easter, I will try to create an issue on the JOSM bug tracker for this. A simple warning with a Yes/No dialog about the copying of relations should be quite effective to prevent this I think, as I have suggested before.

[danfos]

Would be good to have JOSM improved but I think the JOSM button being close to each other is not the main problem. The problem is I think that people want to add an "inner" to an "outer" but doing so they are not aware that the "outer" had already a relation.

[mboeringa]

The problem is I think that people want to add an "inner" to an "outer" but doing so they are not aware that the "outer" had already a relation.

Yes, of course, that is the whole point of creating a multipolygon. Thinking about this, I think this error could also happen in iD, but is less likely, as the "+" button for adding new relations, sits right below the list of existing relations. Also, the workflow in iD differs from JOSM, and although you can certainly make big errors in iD, it would be quite difficult to create this kind of repetitive stacked MP relations in iD, while it is very easy in JOSM.

Actually, @danfos, could you find out in what editor those relations were created you fixed by looking at the history in JOSM?

Still, the whole concept of relations is confusing for any newby. I remember how it took time for myself to get my head wrapped around the whole concept of OSM relations. Once you get it, its not to difficult, but it is to newbies.

[danfos]

could you find out in what editor those relations were created you fixed by looking at the history in JOSM?

From what I remember fixing about 10 of these cases I only noticed JOSM as editor, but let me keep looking.

Thinking on how to prevent these errors, I think JOSM could emit a warning if you add a way to a multi-polygon that is already part of another multi-polygon but that is not catching everything because it can also be that first the ways are added and then only "type=multipolygon". The JOSM validator could do this but I think those warnings/errors are also semi-regularly ignored.

All-in-all I still would love to see a check being added so there is an idea how "big" this problem is.

[mboeringa]

I suggest opening a ticket in the josm tracker.

Done: https://josm.openstreetmap.de/ticket/14701