Always convert trivial multipolygons to closed ways

[DujaOSM]

In general, simple multipolygons with a single closed outer way are undesirable, and can be safely converted to closed ways in most* cases (well, whenever the outer way has no tags, particularly fence).

The basic functionality was introduced in #5085, and released in iD 2.17.0 in 2019. However, it does not work in the use cases I'm listing below, and I don't see why it shouldn't. Here we go ("Doesn't work" mean that the multipolygon is preserved)....

Group 1: starting from valid multipolygons;

Donut-shape

• Remove inner way from relation: doesn't work
• Delete inner way: doesn't work

OO-shaped

• Remove one way from relation: doesn't work
• Delete one way: (can't be done, just listing for completeness)

D-shaped

• Merge ways: works as designed in Automatically convert trivial multipolygon back to closed way when merging #5085

(Continued in new post, just in case...)

[DujaOSM]

Group 2: starting from invalid multipolygons;

C-shaped (incomplete):

• Continue the outer way (so as to close it): doesn't work
• Reshape the outer way (drag the end node to start node): doesn't work

P-shaped (overdone):

• Backspace the "tail": doesn't work
• Split way at the knot node and remove the tail from relation: doesn't work

---

I think I've encountered all of the above cases during my real mapping sessions, and there are possibly more that I didn't think of. I learned to be vigilant as to the end result, but I think that iD should just be consistent and always convert automatically.

[matkoniecz]

However, it does not work in the use cases I'm listing below, and I don't see why it shouldn't.

To be clear it does not seem indicate that mentioned PR was wrong or buggy or bad, as case described in the title is working

[DujaOSM]

Indeed, and I didn't mean to imply otherwise. Just kind-of wondered why the solution covered only that case. (I most frequently encounter the "C-shaped" case, when I want to extend or reduce an existing area by means of splitting it first). I'm not sure if handling is possible to implement in a single place in the code, or one has to cover all possible use cases, like I tried to do above.

For completeness, let me mention the quickest workaround if you end up with a multipolygon like this: just split (X) the outer way at any point, and combine (C) the resulting ways back. That triggers the handled "merging" case.