[OSM-dev] Looking for guidance on interpreting multipolygon relations
Frederik Ramm
frederik at remote.org
Sat Nov 3 20:25:39 GMT 2007
Hi,
> > 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
Yes, I think it *should* not be necessary but it might be necessary
for a transition period, depending on how renderers deal with it. As I
said, ideally the way would not carry any tags because they'd be in a
relation. Ideally if you have a cascading situation with a hole in a
hole in hole... with n concentric rings, then you'd have n-1
relations, with every relation having outer=way#n and inner=way#n-1.
It all depends on what degree of ideal world you're talking about ;-)
> > 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?
Please re-read: I was not talking about two relations, only one. If
the lake is part of the park, then it does not make sense to exclude
it from the park by way of a hole-in-area relation. Ask yourself the
question: If someone gives you a lat/lon describing a point on the
water and wants to know "is this in Battersea park, yes or no" - if
you'd say "yes" then you must not make the lake a hole!
As for rendering: The renderer is smart enough to draw filled areas
first, and then the roads that lead through them; I'd expect the
renderer to be smart enough to find out that one area completely
encompasses another area and draw the larger area first.
Anything else would be a nightmare for a large "landuse=residential"
area with a lot of "building=yes" areas. I am not going to create one
relation per building!
Bye
Frederik
--
Frederik Ramm ## eMail frederik at remote.org ## N49°00.09' E008°23.33'
More information about the dev
mailing list