[OSM-dev] Looking for guidance on interpreting multipolygon relations

[Jon Burgess]

On Sat, 2007-11-03 at 09:55 +0100, bvh wrote:
> On Sat, Nov 03, 2007 at 10:10:55AM +0100, Frederik Ramm wrote:
> > > Way A = outside of the park
> > > Way B = inside of the park/outside of the lake
> > > Way C/D = inside of the lake/outside of the island
> > If you want to express that the water is a "hole" in the park, that
> > would make two multipoly relations, one with outer=A inner=B, one with
> > outer=B inner=C inner=D. Ideally the first relation would be tagged
> > leisure=park and the second would be natural=water but currently you
> > would be expected to tag the ways themselves (leading to double
> > tagging for B).
> 
> I disagree violently with the double tag
> - double work
> - impossible when conflicting tags for example leisure=garden inside
> a leisure=park.
> - does not specify which tag is for the inside and which tag for the outside
> - does not add anything. my proposal to tag only the outside role gives
> more information in a non-ambigious way.

Most of the existing multipolygon relations are from polygons with
holes. For each of these the tags only exist on the ways and not in the
relation. 

When I wrote the Mapnik/osm2pgsql code to handle this I think decided to
use an aggregate on all the tags on all the ways in the multipolygon. At
the time it first wants to know what tags to use the code unfortunately
has no idea which way is the outer one (since the information is not in
the relation). It works out which ring is the outer one by sorting them
by the enclosed area. I could probably make it re-evaluate the tags
after it has determined which way is the outer ring.

Another implicit rule I needed to implement was that only the complete
multi-polygon gets rendered. None of the constituent ways referenced by
the multi-polygon get rendered. Otherwise the holes would themselves
each get rendered too and be filled in, which is not what we want. If we
removed the tags on the inner ways then this rule could be removed. In
addition, if we allowed the tags on the holes to indicate the 'outer'
role as described above then I'd need to allow them to be rendered. We
would have to fix all the existing holes though since practically all of
them do have tags currently. 




> > > A: leisure=park
> > > B: natural=water?
> > > C/D: leisure=park?
> > If you are of the opinion that the *whole* forms a park - i.e. if you
> > would say the lake is part of the park rather than an area where the
> > park stops - then I would advise tagging way A as "leisure=park" (this
> > area does not have a hole then - do not use relations) and use one
> > relation with outer=B inner=C inner=D tagged natural=water for the
> > lake.
> 
> And how would a renderer know that it has to render the first relation
> before the second relation? Not with layers I hope because then we
> are back where we started.

The way the Mapnik layer currently determines this is by calculating the
area of each polygon. The polygons covering the largest area get
rendered first. 

	Jon