If I read the “Members” section of the multipolygon wiki page right, multipolygons should not have other multipolygons as members. However, there are about 65 of these in Sweden, and 11 in Greater London (which are the database extracts I happen to have within easy reach).
Should these be fixed?
If not, is there a definition of what it means? In particular, if a multipolygon A has another multipolygon B as an inner, and B has a hole, does the interior of the hole ( = the finite part of the exterior of B) belong to the interior of A (as would be the case if the interior of B was simply subtracted from the interior of A)?
How does whatever software that renders the standard “carto” map handle this? Is there a write-up somewhere? (Because, let’s face it, the de-facto rule for what is valid is “whatever renders on the main map”; anyone trying to use other rules is facing an uphill battle.)
They should be fixed because they are invalid, but this requires a lot of head scratching and patience, because no case is the same and usually you can see that someone intended to map something and you have to restore it somehow.
I do not see how to create such. [JOSM does not allow me to do that.] Multipolygon A will always only have ways as inner. That these are shared with Multipolygon B, how does that matter?
People even manage to create multipolygons that are recursive, like this one. I do not know how they do it.
I write this wearing a “data consumer” hat — I am not asking how to map things, I am asking which of the bizarre things that occur in the database that I need to try to make sense of, and which ones I can ignore as broken.
Text book example (almost) transparently MP generated in JOSM and completely transparent in ID. JOSM in practise requires the inner green ring (2) to first be made inner to (1). Then create the second MP with (2) as outer and (3) as inner to (2), thusly an MP in an MP. With the relation tool in JOSM select 2 and 3 and take the menu option ‘create multipolygon’. Essentially (2) is in 2 MP relations. Never a single whine from any QA checker, particularly OSM Inspector.
There has been a very slow, but somewhat steady, stream of recursive multipolygons in Sweden (currently ids 1418006, 9212789, 10283624, and 6894343), most of them seemingly caused by one user, using Potlatch. @Richard, are you reading this?
All of those are still in a rendering database as polygons, so the latest osm2pgsql can deal with them, but in some cases its quite surprising that it can - have a look at the components here for example.
Yes - but unfortunately it’s going to need a survey in some cases to try and figure out exactly what the original mapper was trying to say
Some “obviously wrong” examples (including the recursive ones!) can surely be fixed without survey of course. Where it’s not obvious, it’s better to leave something “wrong, but invalid” rather than something “differently wrong, but valid”, since no QA checker could detect the latter in the future.
I beg to differ, because “valid but wrong” things will be seen and repaired faster by mappers, especially local ones, while “invalid and wrong” things will remain blank, unseen and never properly edited in many cases.
Review by mappers without QA tools. For example, I can look for tiny unnamed lakes and review whether they are in reality mistagged ponds, or I can find streets named “Cycleway” and with a survey or Mapillary verify if they should be cycleways. This is harder when the objects are wrongly tagged and don’t show up anywhere except in the raw data and on the last page of a Taginfo section.
You absolutely can, but most people don’t. In the Hampstead Heath mixed woodland example, if that area of woodland suddenly showed up as blank people would be on to it like a shot. As it is, you can only see potential issues by starting to dig into the data, because osm2pgsql has no problems with it.
Sure, the various have their tolerances programmed in over time else half the planet would not be rendering. Question is, do we clean up what does not require an ‘on your knees with spade’ survey to fix issues. Case in point, Inspector flags many inner side touching areas and every day you look at the map you see that and have to evaluate again and again, nothing at a glance. Similar ways mapped along the edge of a pedestrian area. Too many on the map to be able to sift out which are of the ‘no action needed’ and actual way mapped top of way. A thorough waste of my time to even address so I only keep the map clean in my regular area. Up in the alps… only when I’m bored
(We have 2 who’s only occupation seems to be keeping Italy MPs clean and 1 venturing beyond doing German speaking areas too so you get this odd map where they’ve been at work.
Anecdote: When I started rendering maps, many years ago, I had problems with small lakes disappearing. This turned out to be because the lakes were overlapped by forests, which happened to get drawn later. This kind of mapping was, I think, considered wrong even at the time, but the standard rendering showed it correctly so nobody noticed it. Presumably it had some rule about water always going on top of forests, though when I tried that, I got issues with islands instead. Anyway, I had to deal with it somehow. Then the standard rendering changed to put little trees on forests and their overlapping lakes, and very quickly all those overlaps got solved by turning lots of forests into multipolygons with holes for the lakes.
