Mike Thompson <miketh...@gmail.com> wrote: > One polygon for the administrative boundary of the NF which was established > by Congress. > Zero or more polygons describing limitations on access (no need for polygons > to for access=yes, we can assume that in a NF generally), whether they be due > to private ownership, or other reasons. > The above are two separate concepts, so it is ok to have two separate OSM > elements, in my opinion. > A relation for all would be ok too, as long as the private inholdings are not > removed from the NF (which I think has been done in some cases).
If I'm not mistaken, we already have the machinery to do that with how we build multipolygons. To wit, a single multipolygon (well tagged as to name of national forest, protect_class=6, ownership=national...representing the forest) has one or more polygons with role "outer" where all those tags apply and one or more polygons with role "inner" where there are inholdings and "something else, not national forest" are, and the tags on this multipolygon do NOT apply. (These appear as "holes" in the usual way inner members do in a multipolygon). There is nothing stopping us (and sometimes we do) from adding additional polygons that are "coincident with the holes" which represent "what that particular inholding is." It seems to me THOSE are the places where any access tagging (if necessary) might apply, should your fancy run to tagging those specificities. We've been tagging "large public areas with inholdings" like this (using multipolygons with inner members) for as long as OSM has had multipolygons. Why might we (re-)establish "two separate concepts" in two separate data structures when we already achieve this with one data structure (and possibly others, by that I mean "one multipolygon representing the forest, which might have inner members," while noting that ADDITIONAL polygons can describe what the inholdings ARE and superimpose on top of the holes represented by the inner members? Am I missing something? SteveA _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
