De exclave rond Verlengde Ekamperweg 4 te Winschoten klopt, zie de BAG:

https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html#?searchQuery=Winschoten&resultOffset=0&objectId=1895100000006310&geometry.x=266123.492&geometry.y=576952.055&zoomlevel=6&detailsObjectId=1895010000016959

The German community insists on having their interpretation of the border in OSM, and this conflicts with the Dutch interpretation, see:

https://forum.openstreetmap.org/viewtopic.php?id=24840

Not all tools handle this double border well, Nominatim is one of them.

Because this border is disputed, the fix is not to change the data but to fix the tools that use this data.

As simple mappers it is not within our power to fix international border disputes.

relation:12039301 had no tags, and its only member (way:886464901) was already present in relation:12039231.

Voor adressering is in de praktijk voornamelijk de postcode van belang, voor Nominatim is de hierarchie van admin_levels van belang en zodoende de woonplaats grenzen.

Binnen een wijk/buurt kunnen meerdere landuses voorkomen, dus een landuse=residential voor de geometrie is niet de meest voor handliggende keuze, ook zijn er wijken voornamelijk bestaande uit bedrijven/industrie terrein. Daarom zijn relaties met boundary=place place=* tagging een goede optie.

Omdat buurten en wijken kwa naam lokaal bekend zijn is het prima om te mappen. Maar omdat de gebieden geen eigen bestuurslaag hebben is boundary=administrative niet toepasselijk. Vanuit de EU wil men zo min mogelijk bestuurslagen hebben binnen lidstaten, daarom zijn de stadsdelen in Amsterdam en deelgemeenten in Rotterdan hun status verloren en bestaan deze niet meer als administrative boundary in Nederland.

admin_level=10 is alleen toepasselijk voor officiele BAG woonplaatsen. Wagening-Hoog valt onder de woonplaats Wageningen.

Indien een place node niet voldoende is, en een relation gebruikt wordt voor CBS wijken en buurten kunnen deze beter gemapped worden als boundary=place place=quarter of place=neighbourhood voor wijken & buurten respectievelijk.

Zie Leeuwarden als voorbeeld, en de gerelateerde forum posts:

* https://forum.openstreetmap.org/viewtopic.php?id=65329
* https://forum.openstreetmap.org/viewtopic.php?pid=682555#p682555

Overigens is deze discussie niet toepasselijk in deze changeset, een PM of post op het forum is daarvoor de aangewezen methode.

barrier=fence is a appropriate to put on the outer way if it encloses the same geometry as the e.g. landuse for the outer way of the relation.

@Kemps Creek, mechanical edits are a bad suggestion, those have even less human oversight.

@SHARCRASH, your scenario suggests that they are two different objects. The nature reserve which can contain other area objects like forest, grass, water, etc. At the time the forest and nature reserve have the same geometry, but the forest could be partially cut/burned down which is unlike to affect the geometry of the nature reserve. Hence they should be two separate ways.

JOSM is in my not so humble opinion the only decent editor for relations.

What is there to discuss? old-style multipolygons aren't supported any more, but they still show up on a daily basis.

See the area project for some history:

http://area.jochentopf.com/

I moved the tags from the outer way to the relation so that it's not considered an old-style multipolygon anymore.

You should talk to wilda69 who created the old-style multipolgyon in:

changeset/91417820

It means relations with only type=multipolygon and no other tags describing the feature e.g. landuse, building, highway, etc.

The wiki briefly mentions this:

osm.wiki/Relation:multipolygon

This QA work is part of the area project:

http://area.jochentopf.com/

Just make sure not to (re-)introduce broken polygons, then they won't show up in the QA dataset, and other mappers won't be inclined to fix them upsetting you again.

If you want details of my changes, inspect the history of the objects in question.

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.