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.

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.