On Tue, Mar 4, 2008 at 9:21 AM, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > On Tue, Mar 4, 2008 at 7:37 AM, Igor Brejc <[EMAIL PROTECTED]> 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 :-) _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
