Author: R2D2_C3PO
[Added to the original trac issue at 2.45am, Tuesday, 6th January 2009]

WARNING: Do not apply this patch in it's current form! While it worked well for my testcases is fails on many real-world files. I'll upload a fixed version when it's ready.

Author: openstreetmap[at]dstoecker.de
[Added to the original trac issue at 4.01pm, Wednesday, 21st January 2009]

Also note the JOSM test file at http://josm.openstreetmap.de/svn/trunk/data/multipolygon.osm

Supply more test cases for this file when you spot problems, which should be included.

Author: openstreetmap[at]dstoecker.de
[Added to the original trac issue at 4.07pm, Wednesday, 21st January 2009]

Regarding your example: To get that working you need a second multipolygon, which has the included "outer" part as inner. The current advanced multipolygon description does not have automatic detection of that case and I'm not really convinced we should add that.

Author: osm[at]petschge.de
[Added to the original trac issue at 12.29pm, Monday, 2nd February 2009]

What's the current status here?

Author: R2D2_C3PO
[Added to the original trac issue at 12.35am, Thursday, 5th February 2009]

Sorry for not updating my patch, but I had some exams and therefore little time to work on OSM. I hope that I'll be able to provide a working patch next week.

Author: R2D2_C3PO
[Added to the original trac issue at 10.46pm, Thursday, 5th February 2009]

I now have a patch, that correctly handles multiple outer ways. However the tags still have to be on the ways and not in the relation.

I'm also trying to implementing Bob Kare's polygon-center algorithm with support for multipolygons and the code gets quite complicated when multipolygon handling is done in many places. So I came to the conclusion that my complete design is flawed and I'm going to add a preprocessing step, that first creates new objects for multipolgons and then uses these objects for further processing. I'm currently working on this...

Author: R2D2_C3PO
[Added to the original trac issue at 3.40am, Saturday, 7th February 2009]

Completely changed the patch. It now correctly processes the JOSM testfile. Only a few tests in the "errors" section are rendered differently, but as the tagging for these tests is invalid anyways there's reason to render them the same.

However this patch is not complete at the moment. It does not support circles, text, etc. and needs some cleanup. I expect the final patch to be ready in one or two days.

Using the current patch to find bugs in my algorithm or providing comments is encouraged.

Author: R2D2_C3PO
[Added to the original trac issue at 7.18pm, Saturday, 7th February 2009]

Now the patch should be ready for general use. It works on the josm testfile and my own testfiles and I was not able to find regressions on realworld data (with old multipolygon style).

This version now also handles multipolygons where the "inner" ways are at the same time "outer" ways for another multipolygon.

Author: osm[at]petschge.de
[Added to the original trac issue at 1.50pm, Sunday, 8th February 2009]

Frederik, could you please review this patch?

Author: R2D2_C3PO
[Added to the original trac issue at 12.06am, Wednesday, 18th February 2009]

In IRC bobkare requested a plain text description of what this patch does:

This patch preprocesses each multipolygon relation:

• Create a list of all inner and a list of all outer ways
• Tag each way with $way->{'multipolygon'} = 1, so all multipolgyon aware functions ignore it
• Form closed ways for all inner and outer polygons. These new ways have the sum of all tags of the ways they are built from.
• Add all inner ways to $way_storage, so they are processed to fill the inner polygons.
• The outer ways are NOT added to $way_storage, but a new "multipolygon" object is created, with these properties
• outer: All outer ways
• inner: All inner ways
• tags: All tags of the outer ways combined
• This multipolygon object is added to $way_storage and returned for all rules that select "way" or "way|node". Functions that don't support multipolygons skip over these objects.
• To draw a multipolygon for each combined (i.e. closed) outer and inner way a SVG path is created and the fill rule set to "fill-rule:evenodd".
• Other functions only use multipolygons to find area-centers and just pass then on to the area_center functions.

Author: osm[at]deelkar.net
[Added to the original trac issue at 12.46pm, Wednesday, 18th February 2009]

What happens if the multipolygon is not downloaded completely, e.g. the outer and some of the inner ways cannot be combined into closed ways, because ways outside the bbox are missing?

Author: Daeron
[Added to the original trac issue at 6.39pm, Saturday, 21st February 2009]

Replying to [comment:11 osm[at]deelkar.net]:

What happens if the multipolygon is not downloaded completely, e.g. the outer and some of the inner ways cannot be combined into closed ways, because ways outside the bbox are missing?

Could the areas be closed with the same method as the coastlines are?

Author: R2D2_C3PO
[Added to the original trac issue at 10.52am, Sunday, 24th May 2009]

This patch is commited for some time now and it did not show any problems I'm aware of, so I close this ticket.

If a polygon not completely downloaded it can't be rendered correctly. This is a real problem, but I don't know how to solve it. For example consider this situation: A polygon enclosed a Z12 tile, but does not intersect with it. Osmarender will have no chance of knowing that it should color the whole tile, because neither any node of the polygon nor the multipolygon relation are present in the data. In my opinion this can only be avoided when OSM gets a real area data type and the api makes sure all areas are correctly downloaded for a given bbox.