This changeset was part of the Jochem Topf's area fixing project, I was fixing polygons per the changeset comment, not mapping healthcare facilities. The tags were likely moved from the relation to the single outer way.

You can change the tagging to whatever you or the local community see fit.

Stop met tijd verspillen, arguing on the Internet is like winning the special olympics.

Jouw vraag is al beantwoord in mijn eerdere comment: changeset/187320293#c1642982

De barriere is te hoog de extra imagery, dus wanneer je mapped op basis van imagery die niet standaard beschikbaar is voor andere mappers blijf je dit probleem houden.

Ik kijk naar beste imagery die beschikbaar is in JOSM, als er betere imagery is moet die aan JOSM toegevoegd worden zoals de PDOK imagery dat ook was.

De wegen bestaan op de latest PDOK imagery.

Als jij zeker weet dat die portaal imagery recenter is en wil reverten, be my guest.

way:972046451 moet dan opnieuw ingetekend worden, want die bestaat wel degelijk, daar heb ik zelfs de GPS trace van.

start_date wordt gebruikt om te bepalen of de geometrie in de BAG nieuwer is dan de relatie in OSM.

Deze change is ongedaan gemaakt.

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.