# Multipolygons as members of multipolygons

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.

1 Like

Is that not covered by Island within a hole

If you have a situation as this you could have two “normal relations”:

• First one would map Way #1 as outer and Way #2 as inner
• Second one would map Way#2 as outer and Way #3 as inner

I think this is the better approach.

then multipolygon A is invalid and broken and not a proper multipolygon and should be fixed

note that maybe it should not be a multipolygon at all, feel free to ask for help with specific cases

or as linked, single multipolygon (especially when it is for example a single object, like park):

way #1 and #3 as `outer`, #2 as `inner`

two separate objects may be better for cases where this areas are not actually a single object

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.

1 Like

Are these objects reported as errors by JOSM validator? If not then maybe creating notes for them would be a good idea?

Or ask JOSM to start detecting this error? Though this seems fairly rare one.

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.

1 Like

It uses osm2pgsql to convert polygons and multipolygons into a database table `planet_osm_polygon`

Can you link to the London examples?

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?

1 Like

These are the Greater London examples (from a database extract from 8 July, so things may have changed):

``````    id    |                 name                  |    id    | role
----------+---------------------------------------+----------+-------
13008062 |                                       |  1026363 | outer
13008062 |                                       |  1026363 | outer
13572857 | Television Centre                     |  2848056 | outer
1738759 |                                       |  3326153 | inner
1738759 |                                       |  3326154 | inner
8469252 | Terminal 2                            |  3914858 |
15982409 | Westminster School                    |  8244923 | outer
13572857 | Television Centre                     | 12581563 | outer
12617993 | Ruislip Woods National Nature Reserve | 12613534 | outer
1738759 |                                       | 15812493 | inner
1738759 |                                       | 15822867 | outer
(11 rows)

``````

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.

Got any evidence for that claim?

On my side of the argument are the myriad of QA tools that detect "things that might be wrong in OSM. On yours?

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.

&

Lots of ‘eclectic’ cleaning to do.

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.

6 Likes

It seems to be something where areas have pattern, same issue with e.g. scrub.