Roughly 0.06% of barrier=fence are used on relations (Taginfo). That seems to suggest a tagging mistake, unless there are edge cases I am not aware of, like a super rare fence with the thickness of a city wall that also has empty space inside.
For now I’m leaving the multipolygons with a barrier tag aside, but those could also be worth looking at in a future project.
How are you filtering the data? If Overpass please post the routine.
Here is a list of 56k “fence polygons” in UK and Ireland, sorted by size. Some of them seem a bit implausible, even before worrying about linear and area tags on the same object. The largest is this.
… and actually, that’s a great example of how these cockups occur. Before v9 the area didn’t have a fence tag on it. The fence tag came from this object (only 2 nodes!) which was merged in. An outstanding question is how much of the large area is really heath - it’d probably need a chat with all three mappers from the relevant history.
Will do once I’m behind my pc.
Likely initially tagged on an area that then got turned into a multipolygon. Both are incorrect, but yes probably best not to touch them unless you also fix that issue.
Multipolygons where the outer way has more than one parent relation should probably also be excluded (or turned into two separate polygons if appropriate).
Doesn’t look too bad overall judging by the pictures of the area that I was able to find.
https://www.geograph.org.uk/photo/6451874
https://www.geograph.org.uk/photo/3197992
https://www.geograph.org.uk/photo/6554005
Since you asked nicely I took the time to compile what I have so far:
Glossary:
this = a shortcut with the keyboard or something in JOSM’s searchMy workflow so far for finding and simplifying one-member MPs:
ctrl F → type:way -untagged
RMB → “Select relation (add)” → ctrl shift P
ctrl A → shift U → ctrl alt D
ctrl F → type:way and parents:2-100
RMB → “Select relation (add)” → ctrl shift P
3 to zoom in on itRMB on the MP, then “reconstruct polygon”shift V to run JOSM’s validator and fix issues if they appearMy workflow so far for finding and simplifying simple polygons mapped as multipolygons with multiple unclosed outer ways:
ctrl F → type:way and closed
RMB → “Select members”RMB → “Select relation (add)”ctrl shift P to remove selected data from the layer
ctrl A → shift U → ctrl alt D
3 to zoom in on itRMB on the MP, then “reconstruct polygon”shift V to run JOSM’s validator and fix issues if they appearSome thoughts:
Make sure to download the reltoolbox and utilsplugin2 plugins for JOSM. The utilsplugin isn’t strictly necessary until you find MPs that you want to edit.
If you do this without care, without downloading all parent relations or without the reltoolbox plugin you might end up breaking boundary relations and coastlines. In the worst case scenario you might even accidentally delete a camp site.
The reltoolbox still has some minor bugs, so if you try to undo a step you did with it you may get errors. This issue has already been reported, but more reports might help, and if this happens to you I recommend opening the .osm file in notepad++ or similar and manually removing each of the affected ways and relations, then reopening it in JOSM.
I just discovered that unnamed multipolygons with multiple outer areas should in most cases also be simplified to separate closed ways, but I haven’t done anything with these cases yet. The workflow to find and fix them should be pretty similar.
You can remove [!barrier] from the queries or even just remove the ! if you feel like looking at or even fixing the MPs with barrier=* tags. So far I have mostly left them alone. It would be nice to have a clearer consensus on whether barriers should be tagged on other objects, mapped on top of them or even mapped without shared nodes.
Especially for unnamed parking areas, water bodies and landuses it’s not necessary to visually confirm for each of the MPs that they can be reconstructed. Basically all of these cases are the result of someone mapping areas in overly complex ways. If someone could upgrade the reltoolbox plugin we can automate this step and thereby improve OSM considerably with limited efforts.
Update: this query seems to do the trick.
I hope to write a diary post about this in the future, but I think I’ll wait with that until this project has matured a bit.
Restriction to the “outer” role is a good idea. I checked my area and found one single-member relation where the outer member had been accidentally removed. “Fixing” this by tagging the remaining inner member with the relation’s tags would have led to a wrong result.
Given that user-friendlyness - especially for non-expert mappers - is a reason to change MPs to ways, I’m still curious:
in the case of multiple overlapping identical ways over the same nodes (rather than several 1-member MPs that all have the same outer as a single member),
how can a non-expert user that is editing the map in iD :
(a) intuitively see that there is a second and perhaps third way hidden under the “upper” way for which the tags are shown
(b) switch to editing the tags from the way currently hidden underneath the upper way ?
(instead of the top way shown by default)
In the case of several 1 member MPs, it is immediately shown by the iD interface in the left column under “Relations” the different elements that this refers to (islet, campsite, forest etc…) and you can click any them to directly start editing the tags of that element.
With overlapping identical ways, I only manage to edit the hidden ways in iD if I first (repeatedly) unglue nodes and move nodes
Am I missing an obvious and intuitive easy way to reach the hidden ways in iD here that all other 9and also beginning) mappers do see at first glance?
(learned some nice JOSM-tricks here after 6.000 edits 
)
Those seem like good questions to ask in #help-and-support. You might get better answers there than at the bottom of this long thread.
You might actually be the best person to answer this question here since :
and no, it is not just about his one campsite…
That had nothing to do with iD, though, and I don’t map based on how difficult something is to map in iD anyway.
One question on your description, what does “RMB” mean?
Probably also good to mention that with “relation toolbox” you mean the JOSM/Plugins/Relation Toolbox.
Right mouse button
Sure, I’ll do that. You can simply find it in the list of plugins in JOSM itself, though.
There must be a type or something - The /optional/ purging step leaves me with lots of multiple member multipolygons.
This is a follow-up of @Taya_S’s suggestion to look for MPs that are simple polygons constructed out of several outer ways, like this building part. I apologise if I haven’t made this clear enough.
I’m not am iD user at all, as Josm is much more intuitive to me. But I took a look to see if I could find an answer to the questions below.
In answer to point (a), once I select a way, nodes that are connected to one or more other ways are grey. Unconnected nodes are white.
In answer to point (b), you can select a grey node on the way and press Ctrl+Arrow-Up to find all ways connected to the node and select one of them.
So yes, as a non-iD-expert, I managed to answer the 2 questions, but only with the help of my expert knowledge of I could do this in Josm. Its still not intuitive to me, but that goes for iD in general.
Having said this, I still prefer the single-multipolygon solution in cases like the scout group example. At the moment it is a mix with one way for the scout group without relation and a second way that is used in the grass landuse multipolygon and the islet multipolygon.
What if the water around the islet were mapped as a multipolygon. Which of these way should have the inner role in the water multipolygon? Any one of the 2? Both? Or yet an other copy of the same way?
That water multipolygon did in fact exist until I found an excuse to split it up.
Thanks for looking at this Gertjan !
So tags on several overlapping identical ways can be edited in iD , but it requires more advanced editing skills from the user than on several single-member MP’s, just like in JOSM.
For the avoidance of doubt : do you mean
Cheers
After reading your justification for your edits
I assumed for a while that user-friendliness -especially for beginners- actually was your motivation for these mass edits you already have made without prior consulting. That is why I asked how overlapping ways could easily be edited in iD, a question you refused to respond to
But after seeing your remarkable indifference here to the loss of information your edit has led to and after reading :
I realised you summarized your motivation for editing quite accurately here
If you had any local knowledge, you would have realised this splitting up of the water area is quite nonsensical, it isn’t a canal next to a river in the sense of OSM : none of those two bodies of water is naturally flowing down towards the sea.
Both are -for quite a few centuries now- part of the same isolated boezem-basin below sea level, which only reaches the sea or a river when it is being pumped up by one of four pumping-stations that -when working- connect the boezem up to free flowing water.
The eastern part has been dug out as well, not in the 1930’s like the western part, but somewhere in the 1200’s , when part of a former tidal stream was converted to a canal for carrying excess water northward.
If start-date would be a reason for splitting up water, you can have endless separations in lakes that have expanded over time due to wind-induced erosion.
Please don’t go out and to find excuses to change things, but look at how you can actually improve our common database and make it more fun to contribute here instead of making things worse.