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.