[OSM-talk] area_with_holes as alternative to multipolygon relation

[Jon Burgess]

On Tue, 2008-03-04 at 08:42 +0100, Robert Vollmert wrote:
> On Mar 3, 2008, at 22:45, Sven Grüner wrote:
> > Robert Vollmert schrieb:
> >> I think not. I'm pretty sure for osmarender, but may not have had
> >> enough patience to test out the various combinations with mapnik.
> >
> 
> I was wrong about osmarender: What I remembered is actually code from  
> mapnik (or rather, osm2pgsql):
> 
> static int pgsql_out_way
> [...]
>      const char *multipolygon = getItem(tags, "multipolygon");
> 
>      // If the way has been part of a multipolygon then skip
>      if (multipolygon)
>          return 0;
> 
> The "multipolygon" tag is set in pgsql_out_relation for ways with  
> role=inner. Furthermore, pgsql_out_relation appears to aggregate tags  
> of all ways involved, so you should end up with  
> landuse=forest,natural=water on the multipolygon. I wonder what  
> happens when both have differing natural= tags?
> 
> Or am I reading this all wrong? I haven't really been able to test  
> because so far, my mapnik install doesn't appear to render any areas...

That is right. Looking from the outside these features may seem odd but
both were essential for the initial 0.5 multipolygon support.

The multipolygons created with the 0.5 API had no defined roles so there
was no way to know which was the outer ring during the initial XML
processing. Hence the solution to aggregate the tags of all the
constituent ways. Since the rules defined the holes had to
counter-clockwise they could not be used for other areas to the tags
should never clashed. 

The suppression of ways with 'multipolygon' actually applies to both the
outer ring and all the holes. Without this, all the individual ways
would also appear into the rendering database and each would be rendered
as a filled ring regardless of the multipolygon that they are also part
of. This would completely destroy the usefulness of multipolygons since
the holes would all appear as filled areas in their own right. 

We could only remove this suppression if we removed the tags from all of
the ways. This would require all the multipolygon tags to be moved to
the relation instead of the ways. 

I'd be happy to make the required changes to osm2pgsql but I'm very
nervous about what will happen to all the existing multipolygons during
the transition to the new scheme.

How about we define this as a new relation type and depreciate the
multipolygon type. That way we can introduce the rendering of this new
relation type and over time convert the existing multipolygons without
effecting the existing rendering. Once the renderers and other tools
have full support for this new relation type we can easily identify the
relations which still need to be migrated and can easily turn off the
rendering of the old type.

	Jon