The deletion of the camp site was accidental and as I said I learned from my mistake and have multiple safeguards in place for it:
Omitting (purging) 1-member MPs of which the ways have multiple parent relations when working on 1-member MPs (text edited)
Omitting (purging) closed ways and their relations when working on MPs with multiple unclosed outers.
The choice to make a closed way of the camp site was deliberate. That’s not hidden, it just overlaps. You can find it right here: Way: Zeeverkennerscentrum Kagerplassen (1191402332) | OpenStreetMap
Other mappers have already taken the time to explain how you can select it in the editor, and I’m very sure that most OSM-based apps, websites etc. will also be able to find it.
As I said right after that sentence, which you forgot to include in my quote, I’ve been quite thorough to prevent these mistakes, this one just slipped through the nets. And like I’ve said repeatedly, I now have multiple safeguards to prevent future issues like that. How often do you plan to circle back to this one camp site that I already restored?
For those who are interested in edge cases I have an interesting example here. I already fixed it, but with this .osm file you can see what it used to look like. The boundary relation was descriptive and arguably invalid, so I made the choice to remove it.
That was me not checking what I was typing.
Corrected version: Omitting (purging) 1-member MPs of which the ways have multiple parent relations when working on 1-member MPs
Yesterday did quite a few conversions merging the outline segment of MPs but then forgot to hit the reconstruct on 1.
And then I zoomed out and looked at all the pins for 1 member MP AND mixed nature MPs, e.g. a combo of tags for same are of nature=scrub + grassland or landuse=commercial + landuse=industrial in the same MP. Does not look good and the battle of what to render this at… maybe the first label encountered ?
No - the one that I had in mind was here (not one of yours). In that example the fence and the landuse are the same object… Imagery suggests that there’s a gate at the southeast of the property, that hasn’t been mapped, and that the landuse=grass area is actually a much smaller area within that property. I’m not sure that landuse=grass is the best tag for it, either.
Multipolygons should really only be used when it’s absolutely necessary because something could not be represented with just a normal polygon.
From a mapper/user point of view:
A lot of mappers simply don’t know the details of how multipolygons work. Editors try to abstract some of the complexity, but that’s not always possible and the abstractions are leaky and incomplete. Most of the time things work okay-ish, but when they inevitably don’t, a large number of people are left stranded and won’t know how to fix things.
There are tons of ways to break multipolygon relations.
Creating multipolygons might be fairly easy (still harder than creating a normal polygon), but working with them or modifying them afterwards in ways that involve more than some tag fiddling is hard and sucks. (A big reason for that is the comparative lack of editor support. See below.)
From a software point of view:
Simple polygons are much easier to process for any data user or editor. There are far fewer corner cases and potential errors to check and algorithms to work with them are a lot easier to implement.
As a result, many editing tools and algorithms that are available for simple polygons are simply not implemented at all for multipolygons or are not as feature complete. (I say this as someone who has implemented some of the tools for working with multipolygons in a major editor. It’s a PITA.)
Different data users have different software implementations for dealing with multipolygons with potentially different behavior. E.g. some may implement different error checks or be more or less lenient with what they can work with. As a result, interpretation of data might differ and be inconsistent.
Multipolygons are much more resource hungry than simple polygons. They require more processing power, memory and time. This might not be very noticeable at small scales, but becomes a problem when you scale things up.
To sum up: Multipolygons are harder to work with and there are lots of things that can go wrong with little benefit.
Yeah, I’ve learned by now to simply exclude any relation with a barrier tag, as well as place, boundary, natural=peninsula, natural=bay, leisure=nature_reserve and leisure=golf_course.
I wouldn’t be surprised if most instances of fences or hedges tagged on another (area) object are incorrect. Not just because it violates the one element principle, but also because it’s highly unlikely that there’s an unbroken fence or hedge around e.g. a field without any sort of entrance.
Yes, I made the mistake of looking once more at this ‘thing’, and the few I tested were right. MPs with mixed landuse and natural on outer like wood and scrub. Since the wider mapping area I do had just the one I forgot, it’s either all the mistakes I made are below Osmose’s skill set or… ;P)
indeed; more than 95% of mapped gates are on nodes (taginfo)
Usage on ways for barrier=gate is optional micromapping (which only a small percenatge of mappers does, and even then often the needed information on the precise dimenions is also missing).
usage on ways for barrier=cattle_grid is (for reasons I don’t follow) discouraged for ways in the wiki ( “should not be used on ways”) , the percentage of these mapped on ways is well below 1 %
without gate, there is a tag barrier=entrance, but I agree it seems simpler and nicer to just leave a gap with the right size in the barrier, especially if it is wide.
if you map a node with barrier=gate in the middle of a way with barrier=gate, how do you tell whether this is the same gate, or a gate in the gate? Are there additional tags for this?
Working on a note, where an entrance was claimed missing, I recently added the fence tag to a dog ground, with the missing entrance a node, its just so OSMish easy - the fence in every matter applicable outlines what is inside. Perhaps it would have been better to turn the outline into a tagless line-string and add two MPs - one for the dog ground (area) and one for the fence (line)? I dont know. While I know, that a mapping like this makes big problems for Netherlands users wanting to map hedges as areas, I just cannot see a violation of the one element principle there. That said, your work on one OSM-editor is highly appreciated!
Back on topic: Single member MPs might be justified where an anonymous line serves multiple purposes, and even if rare and not something beginners create. That makes it quite hard to prevent data-loss in a mechanical edit of some such
The “One feature, one OSM element” guideline on the Wiki recommends to only map a gate or any other object once to avoid this sort of situation. That said, this is getting off-topic.
the fence in every matter applicable outlines what is inside. Perhaps it would have been better to turn the outline into a tagless line-string and add two MPs - one for the dog ground (area) and one for the fence (line)? I dont know.
a multipolygon cannot represent a fence because a fence is a linear feature. You should add fence tags to a way, not to multi relations
