Opened 9 years ago

Last modified 5 years ago

#2853 new defect

osm2pgsql multipolygon handling necessarily broken on outer tagging change

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


When you have a multipolygon with tags (say landuse=forest) on the outer way, and the same tags (landuse=forest) on the inner ways, osm2pgsql rightly drops the tags from the inner ways and just creates a single polygon object with holes. This renders as a forest with unfilled holes. So far so good.

If you now change the tagging on the outer way (say, to natural=heath), osm2pgsql updates that polygon's tagging. Since it never created separate polygons for the inner ways, those inner ways still won't render, and the natural=heath polygon will have unfilled holes. The only trick to get them to appear, is to modify the inner ways (change geom, change tagging), wait for the mapnik db to update, and then change the inner ways back to what they're supposed to be. This creates separate objects for the inner ways, so these finally render.

Change History (4)

comment:1 Changed 8 years ago by ipofanes

I don't know if a multipolygon with same outer and inner tags should interpret the inner polygon as an absence of the properties.

If the outer polygon has the additional tag wood=mixed and the inner has wood=coniferous, how do I map this? The way in is rendered as desired in Osmarender, but not in Mapnik.

comment:2 Changed 7 years ago by amm

  • Component changed from mapnik to osm2pgsql

comment:3 Changed 6 years ago by amm

This sounds like a duplicate of #4525

On relation changes in diff processing, all of the member ways need to be reprocessed to catch these kind of issues.

comment:4 Changed 5 years ago by amm

It looks like this wasn't fixed with the fix to #4525.

For this to work, one would have to "expire" all relations for which any changed way is a member, which then in return would have to set all ways of all of those relations to pending.

This will probably introduce a huge overhead in diff processing.

Note: See TracTickets for help on using tickets.