Then go and delete the building. This changeset fixes broken polygons as noted in the comment, whether or not the features actually exist is out of scope.

Should be fixed with the changes in:

changeset/119515523
changeset/119515586

This changeset triggered conflicts that couldn't be resolved easily, every resolution caused more conflicts.

The changeset couldn't be closed earlier.

Woonplaats-, gemeente-, en provinciegrenzen zijn ten alle tijden relaties.

osm.wiki/Relation:boundary

Ook als het maar een member heeft.

Consistentie is een groot goed.

Deleting boundary relations is not a fix!

Adres node ligt de change in 117256190 weer in de verkeerde woonplaats.

The start_date for BAG boundaries also contains the timestamp, you should not remove it.

Bedankt voor de building correctie, bij het downloaden van de adress node waren de gerelateerde ways niet mee gekomen.

"
Note that before May 2017, some multipolygons also had their tags on the outer way (if there was only one such way or all ways had the same tags) while keeping the respective multipolygon-relation untagged. But when consuming older OSM data excerpts, it is necessary to handle such old style multipolygons, too. See old style multipolygons for historic notes.
"
osm.wiki/Relation:multipolygon
osm.wiki/Old_style_multipolygons

The dataset from the areas project also includes relations with only type=multipolygon and no tags on the outer way.

http://area.jochentopf.com/

Thanks for your DWG work. The scope of my work on this building was limited to invalid geometries.

Broken polygons come in various forms, the solution varies. If you disagree with that, you're welcome to improve upon the fix.

There is no need for changeset discussions, they have little value. Map contributions have much more value.

You'd do well to have the local community involved in resolving these issues before the global community does.

The data and related tooling is available at:

http://area.jochentopf.com/download/
https://github.com/osmcode/osm-area-tools

The data is also used by:

http://tools.geofabrik.de/osmi/?view=areas

Invalid polygon will keep being fixed, if you want to prevent objects you care about to be touched as part of that QA effort you need to ensure they don't trigger QA issues.

Grouping buildings with intersecting ways in a multipolygon relation is an error, that's not a valid use of type=multipolygon. See:

osm.wiki/Relation:multipolygon#Valid_multipolygon_conditions

If you insist on grouping the building parts in a relation, consider type=building (although that's intended for 3D buildings)

osm.wiki/Relation:building

Deleting relations that are beyond repair is fine. Properly maintained boundaries will get re-added.

The relation has no members, it is of no value in that state.

Thanks for your work.

The relation was already there, I just fixed the open rings.

I leave further improvements to the local community.

Uploading more frequently makes the QA work too tedious, so no. The data is already split into separate countries, that's the best you're going to get.

In the future, don't bother with changeset comments if you're fixing the issue.

If you noticed that, why didn't you fix it?

You guys seem pretty active, perhaps you can keep an eye on broken polygons too.

http://tools.geofabrik.de/osmi/?view=areas&lon=122.18701&lat=13.03025&zoom=6
http://area.jochentopf.com/

That should be fine if the broken polygons have not been reintroduced.

Those roads were connected to buildings with duplicate nodes, and those duplicate nodes were fixed in this changeset along with additional issues reported by the JOSM validator for the changed objects.

Fixing broken polygons is a never ending endeavour, so any reverted fixes are not a big deal.