Author: jburgess[at]uklinux.net
[Added to the original trac issue at 7.54pm, Tuesday, 4th March 2008]

The changes to osm2pgsql are mostly straight forward.

Do you have a plan on how the 5000+ existing multipolygons will get fixed?
I believe most of these still have tags on the holes which will cause them to be incorrectly rendered if it follows your rules.

It should be possible to special-case the situation where the tags on the inner and outer match but that may cause some confusion.

Author: robx
[Added to the original trac issue at 10.33am, Saturday, 26th July 2008]

Hi,

sorry for not replying to this earlier -- I didn't realise I wasn't getting updates by mail.

I'm not sure if this is worth pursuing: I had the impression I'm about the only one who thinks the current behaviour is stupid.

If we do, I have scripts that can
A. set role=inner and role=outer automatically
B. strip tags from inner ways that also occur on outer ways
I can share these, just don't have a place to put them right now.

Then we could:

1. run A. on all multipolygon relations
2. change osm2pgsql to disregard tags on inner ways entirely
3. run B. on all multipolygon relations
4. change osm2pgsql to treat inner ways like normal ways (in addition to saving them for drawing the multipolygon)

I think I mostly did step 1 earlier, but there's sure to be a lot of new multipolygons now.

Open questions would be how other renderers would deal with it. or/p should be able to handle this also, but the xslt-based osmarender might not.

Author: jburgess[at]uklinux.net
[Added to the original trac issue at 11.09am, Saturday, 26th July 2008]

In the past week I made some changes to osm2pgsql which attempts to implement what you originally asked for. The change was made live after the last planet dump so not all the tiles visible on the map this week have this fixed. On example which is partially visible is the island in the lake at http://www.openstreetmap.org/?lat=54.59126&lon=-3.14333&zoom=16&layers=B00FTF
On the lower zooms the tiles are from before fix. The whole lake is invisible due to a confusion between natural=land on the island hole vs natural=water on the outer way. It should all appear properly after the tiles expire and are rendered again next Weds Aug 2nd.

The new algorithm is:

When rendering the multipolygon only take into consideration tags on the relation and on any members that are not marked role=inner. We can't reliably assume that all outer rings are correctly tagged with role=outer but instead assume that if someone wants to tag an inner way differently then he can add role=inner to avoid it getting used by mistake.

The code builds up a list of representative polygon tags from the multipolygon, i.e. things like landuse=, building= etc. It then compares the tags on all the member ways to these. If they don't match, e.g. outer has landuse=forest and inner has landuse=residential, or building=yes then the non-matching way will be added to be rendered on its own. If the inner way tags match the outer way then they will be excluded. This avoids problems with a lot of the existing data which does duplicate the tags between all the members. The checking is loose enough though that if the outer way has name=foo and this is missing on the inner ways then this is not a difference which will cause them to mis-match.

Feel free to email me the scripts if you want and I'll take a look at them and/or add to SVN. The algorithms above are not ideal and are bound to be difficult/impossible to implement in some renderers. It would be much better if the data was more consistent and/or easier to identify which revision of the multipolygon tagging recommendations a particular one is conforming to.

Author: jburgess777[at]googlemail.com
[Added to the original trac issue at 1.45pm, Sunday, 10th May 2009]

I just applied a fix to osm2pgsql in r14997 to make it fix up the direction of the inner/outer rings during the processing. I believe this fixes the remaining orienatation issue mentioned in this ticket but I'll leave it open until things begin re-rendering with the fix in place next Wednesday.

Author: iandees
[Added to the original trac issue at 10.39pm, Monday, 9th September 2013]

Pretty sure osm2pgsql is doing well on multipolygon relations now.