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

[Jon Burgess]

On Sat, 2007-11-03 at 15:33 +0100, bvh wrote:
> On Sat, Nov 03, 2007 at 12:37:05PM +0000, Jon Burgess wrote:
> > 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.
> 
> What happens on conflicting tags in the aggregate?

That is undefined. At the time I was writing the code I was principally
concerned with making something work with multipolygons created by the
0.4->0.5 conversion process. These were created with consistent tags.

I was hoping that going forward the interpretation of the tags in this
scenario would be defined and I'd update the code to fit.

There was a mail on the talk list with mentioned that the bbox API may
return results which do not include all ways for a relation. Dropping
the tags on the holes might be a good idea. If someone just received the
inner holes then they would have no tags and thus not be rendered. 

I'd think the logical place for the tags would be on the relation but I
could work with them being on the outer ring only.


> > > > 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. 
> 
> Is this case described above there are two different relations
> (multipolygons). So mapnik will decide rendering order between
> those two relations with covered area? I was hoping to avoid any
> of those calculations because it is probably not going to be fast
> enough for what I want to do.

When the osm2pgsql program does the conversion to geometries in postgis
it stores the polygon area in the table (I think it actually stores the
area of the outer ring without subtracting the holes, but this is good
enough). When mapnik runs the bounding box query on the table it asks
the results to be ordered by the area column.

> cu bart
> 
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev