How can a multipolygon with only one member have more than one outer? This seems logically impossible to me.
2 Likes
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 ?
https://osmose.openstreetmap.fr/en/map/#item=1170&zoom=7&lat=48.683&lon=7.602&level=2&tags=&fixable=
Global mayhem, it’s a wonder there’s colour showing on Carto Standard,.
1 Like
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.
You’re looking at Osmose, which is wrong most of the time. 
3 Likes
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.
8 Likes
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.
1 Like
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)
we usually don’t map gates or entrances on ways, the normal way is to add a node to the barrier-way.
1 Like
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 %
When there’s a small path with a gate through the fence, sure. Less appropriate for hedges or when there’s a wider road/track with no gate.
(You can map gates as a linear way in addition to the node.)
All of this is just another argument against it though. The one element principle is reason enough not to tag it on the same object.
Sure, a barrier node on a way is always necessary. A linear barrier way in addition is optional/more detailed.
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
1 Like
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
3 Likes
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.
1 Like
How are you filtering the data? If Overpass please post the routine.