Probably the boundary=place relations using their own way members instead of reusing the ones from the administrative boundary.

admin_level=11 wordt niet meer gebruikt in Nederland.

Woonplaatsen (admin_level=10) zijn de kleinste administratieve eenheid.

De juiste tags voor plaatsen (wijken, buurten, dorpen, etc) die binnen een woonplaats van vallen zijn:

boundary=place
place=*

Ik onderhou alleen de woonplaatsgrenzen en de gemeente/provincie grenzen die dezelfde boundary ways gebruiken.

The polygon was broken two years ago (the geometry was not a valid polygon).

No need to contact me about these changes, just update the data to reflect the current on the ground truth.

The areas project is no longer active, not is the website for it. For some background information, see:

https://github.com/osmlab/fixing-polygons-in-osm/issues/15

Grenscorrecties dienen eerst bij de relevante (lokale) overheden aangekaart te worden, daarna worden de grenzen in OSM bijgewerkt mbv de officiele geodata wanneer de wijzigingen daarin verwerkt zijn.

Dankzij Schengen is het deel van de kamping in Nederland overigens geen probleem.

De boundary way is al hersteld:

changeset/135478508

De grens is correct, het is daar een rechte lijn, zowel volgens Nederland als Belgie:

https://app.pdok.nl/viewer/#x=193890.15588053412&y=307563.68101496215&z=11.84&background=BRT-A%20standaard&layers=01d4dab6-03ad-4e82-b719-4daf8b96ea14;AU.AdministrativeBoundary
https://topomapviewer.ngi.be/?l=en&baselayer=crossborder.topo&x=760749.36&y=661896.69&zoom=10

The tags moved the relation the way was an outer member of: relation/110752

That's how proper multipolyons as structured, see: osm.wiki/Relation:multipolygon

Ideally get authoritative data from a national geo agency under a license that can be used in OSM and use that to correct the border.

Google maps is not a source that can be used in OpenStreetMap.

This changeset just fixed broken polygons, the accuracy of geometries is out of scope.

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.