[OSM-talk] area_with_holes as alternative to multipolygon relation

[Dave Stubbs]

On Tue, Mar 4, 2008 at 9:21 AM, Martijn van Oosterhout
<kleptog at gmail.com> wrote:
> On Tue, Mar 4, 2008 at 7:37 AM, Igor Brejc <igor.brejc at gmail.com> wrote:
>  >  That's fine if you look at OSM data from the presentation viewpoint
>  >  only. But what if sometime in the future somebody wanted to calculate
>  >  its surface area? ;)
>
>  Are you saying that if someone asks you to calculate the area of a
>  national park, that they're expecting you to subtract the areas of any
>  lakes, ponds, rivers within it? Different example, but you get the
>  idea.
>
>  The area of a housing estate includes the area of the buildings on it.
>
>  If there is a forest with a lake in it and I get on a boat, have I
>  left the forest? I'd say no (you are simultaneously in the forest and
>  on the lake), but I can imagine people disagreeing with that. My point
>  is that the question "What is the area of feature X" is too weakly
>  defined to be basing our structure on the answer.
>

It's feature X that's too weakly defined. The question you're really
asking here is what is meant by forest? I think most people are
interpreting it as an area of land covered by trees, in which case a
lake is certainly not forest.

It doesn't change the fact that if you're creating a forest and then
feel you have to add natural=land over the top to add a clearing,
you're doing something wrong.

This is mainly the difference between logical areas, and actual
physical features. So maybe forest is just a really bad tag at the
moment and being constantly "misused". Perhaps the rendering needs
fixing to properly represent forests as logical areas and we have
natural=wood or whatever that you can cut bits out of to represent the
trees. Either way natural=land is evil and should die :-)