Have a look at the history of the objects to see what changed.

As the comment mentions, old-style multipolygons were fixed, that implies setting tags on the relation instead of the outer way.

See:

osm.wiki/Relation:multipolygon

And:

http://area.jochentopf.com/

I'm fixing objects in the old-style.osm.pbf dataset, which includes relations with only type=multipolygon and no other descriptive tags, the changeset comment reflects that.

See: http://area.jochentopf.com/

If a mapper doesn't notice that his incomplete/incorrect relation is gone, it's not a loss.

I don't have time to educate mappers about their edits, I already spend my time on fixing the issues.

To any of these mappers reading this, here's some advice. Use the only decent editor: JOSM, it has a great validator and tools to help you map correctly, catching issues like these before upload, or preventing them all together. iD is not a good editor for none trivial objects like relations, and its developer has shown a disturbing disconnect with the OSM community, making it highly unlikely that it will ever become on par with JOSM or even superseding it.

I did. You shouldn't upload invalid multipolygons. Upload it when it's ready. If iD doesn't allow that, switch to JOSM.

"It will be removed sometime in the near future.", why wait. Just delete them now if they can't be tagged appropriately.

The relations don't have tags describing the feature, mostly just the note: "Nantahala National Forest"

That implies landuse=forest. If it's not than it should be tagged accordingly by someone familiar with the on the ground truth, e.g. you.

As long as these (kind of) relations show up in the old-style dataset, they will be on my daily todo list to get them out of it again.

The relation has no tags, and serves no purpose.

If you want a proper multipolygon relation move the tags from the outer ways to the relation.

See: osm.wiki/Relation:multipolygon

Invalid multipolygon, touching outer rings most likely.

If you want the details revert to the version before this changeset and run the JOSM validator on the objects.

You can't make volunteers do work. If you want to ensure that I didn't break anything, that's on you.

Block my account if you want to prevent me from breaking anything in the future. You'll need to find someone else to do this QA work and maintain the administrative boundaries in The Netherlands.

JOSM Validator is your friend. It started with fixing broken polygons (inner way outside mostly), then on initial upload there were several easy to fix validator issues. Just removing the deprecated is_in tags doesn't need to be checked for every object.

You're welcome.

May I suggest using JOSM, it has a much better validator than iD, which greatly helps when editing non-trivial objects like relations.

You should not make assumptions about others.

I fixed the issue in the most appropriate manner, since we don't have a well establish alternative relation type for collections.

If you disagree with changes, you can just revert them and make the changes you see fit. Arguing in changesets is not a productive use of our time.

When your polygons don't get flagged as old-style or broken by osmium, they won't get on my radar.

http://area.jochentopf.com/

Because it wasn't a valid multipolygon, it has touching out rings. A collection of rings like this cannot be modelled as a multipolygon.

The individual rings were tagged with those from the relation to fix the invalid multipolygon.

Why did you not inspect the changes in the object history?

In the context of the area project every relation with only type=multipolygon is old-style.

http://area.jochentopf.com/

You're wrong, removing the relation _is_ a fix for old-style multipolygons. The object won't be detected as an old-style multipolygon again.

Instead of arguing in this changeset, you should have inspected the history yourself and taken the actions you see fit.

I did, and the change looked sensible, it should have deleted the relation instead of just removing the tags.

With your revert you risk the duplicate information being removed from the relation again.

It had no tags after the duplicate tags were removed in the changeset before mine:

relation/9349785/history

Disconnecting the node is sufficient to fix this.

Does iD not allow you to do this?

It's fixed with changeset/70519490.

What are the IDs of the nodes in question?

All settlement (woonplaats) boundaries are relations, no exceptions.

Osmose should be updated to not complain about single member boundary relations, those are perfectly valid. And very much preferred for consistency with other more typical boundaries with multiple members for the outer ring.

The tagging of both the member ways and the relations are correct. We've used this scheme for the administrative boundaries for several years, and we're not about to change because you or Osmose think differently.

Please spend your time on more worthwhile efforts. The administrative boundaries are well maintained.

Don't delete boundary relations. Only having a single member is not a problem.