Opened 11 years ago

Closed 6 years ago

#721 closed defect (fixed)

osm2pgsql: improve handling of multipolygon relations

Reported by: robx Owned by: jburgess777@…
Priority: major Milestone:
Component: osm2pgsql Version:
Keywords: osm2pgsql relations multipolygon Cc:

Description

Following the mailing list discussion at http://lists.openstreetmap.org/pipermail/talk/2008-March/thread.html#23876 I've rewritten the definition at http://wiki.openstreetmap.org/index.php/Relations/Multipolygon.

In particular:

  • renderers shouldn't rely on the orientation of the ways involved
  • only the tags of the 'outer' polygon should be applied to the multipolygon
  • 'inner' polygons should be rendered as usual corresponding to their tags

I'll try to create a patch, but go ahead and fix it yourself if you want -- might take me a while.

Cheers Rob

Change History (8)

comment:1 Changed 11 years ago by robx

Keywords: osm2pgsql relations multipolygon added

comment:2 Changed 11 years ago by Tom Hughes

Owner: changed from Tom Hughes to jburgess777@…

comment:3 Changed 11 years ago by jburgess@…

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.

comment:4 Changed 11 years ago by robx

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

  1. set role=inner and role=outer automatically
  2. 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.

comment:5 Changed 11 years ago by jburgess@…

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.

comment:6 Changed 10 years ago by jburgess777@…

Owner: changed from jburgess777@… to jburgess777@…

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.

comment:7 Changed 8 years ago by Tom Hughes

Component: utilsosm2pgsql

comment:8 Changed 6 years ago by iandees

Resolution: fixed
Status: newclosed

Pretty sure osm2pgsql is doing well on multipolygon relations now.

Note: See TracTickets for help on using tickets.