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

bvh bvh-osm at irule.be
Sat Nov 3 16:49:49 GMT 2007


On Sat, Nov 03, 2007 at 04:45:29PM +0000, Jon Burgess wrote:
> 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.

So you'd be OK with the proposal I made at the start of this thread?

> 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.

I agree the relation would be the logical place but since most of them
currently are on the rings themselves, the easiest option for renderers
might be to accept them on both the outer ring and the relation?

> > 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.

Certainly, caching the area is not much of a problem. 
For static data, sure, but I need to invalidate
the cached area as soon as a node is moved by the user and to do that
in a practical way I need to keep a list for each node to which ways/
relations it belongs and it was that what I was hoping to avoid.

But I guess I'll have to bite the bullet then...

PS. Am I mistaken in thinking that you must certainly _not_ substract
the holes area because otherwise you could easily make an 'outer'
relation that has a smaller area than a 'inner' relation and thus
have the inner relation rendered before the outer one?

cu bart




More information about the dev mailing list