>
> > I would imagine that the parent NF object that has the name
> > "Green Mountain National Forest" would contain members that had
> > protect_class=6 (resource extraction), protect_class=1b (wilderness),
> > protect_class=5 (recreation areas, Appalation Trail corridor), etc.
>
> Again, yes. To clarify, the NF object itself (the multipolygon's tags,
> I'd discourage calling this "parent" as it means something else in the
> context of relations and super-relations and we shouldn't confuse those)
> would have the name=Green Mountain National Forest + protect_class=6 tags
> (plus others, like operator=USFS). AND the additional members "associated
> with the NF" (like wilderness areas which are "within the NF") would be
> separate polygons with* role inner as members of this NF relation, but
> ALSO with their OWN tags (like protect_class=1b and name=Breadloaf
> Wilderness). Yes, this makes "holes" of wilderness inside of the NF, but
> think about it: if the "whole thing less inholdings and stuff that's
> different" (outer minus inners) really deserves protect_class=6 AND the
> "inners that are wilderness"* are tagged with protect_class=1b, well,
> we've got it! Sure, doing it like that makes it logically appear (and
> maybe actually be) that wildernesses are excluded from the NF, but in the
> sense by which we tag them, they ARE excluded, even as they are surrounded
> by something with a "lesser" protect_class. Plus, it is the same agency
> tagged both on the multipolygon (for the outer) and its member inners.
> They are logically excluded by being inners, but because the MP is tagged
> operator=USFS (and so should be the inner wildernesses), we "add them back
> in," at least for their operator, by virtue of that tag being on the inners
> (But being differently tagged with protect_class=1b, as they should be).
> Whew!
>
(emphasis added)
Steve, I think that cutting wilderness/etc areas out of the NF polygon is
logically problematic as these *are* part of the NF, just with extra
restrictions. You don't leave the NF when you enter the wilderness area.
This is kind of like cutting out a section of a highway from its parent
route relation just because a portion of it doesn't allow heavy loads and
has additional restrictions. One significant issue with this is that
"adding them back in by operator" would have to be handled by data
consumers to understand the model, a new and extra burden.
I'd rather see a tagging structure that was logically consistent, where a
query of "is this point in the NF?" always returns the correct answer for
any point. This might be more complex than just a multipolygon and use
parent/child relations (that was intentional language choice on my part).
Here's an example:
- Parent relation:
- name=Xxxx National Forest
- operator=United States Department of Agriculture, Forest Service
- ownership=national
-
*(NOT protect_class=6 as that will not be true for all members) *
- One (or more) child multipolygons for all of the "normal" areas:
- boundary=protected_area
- protect_class=6
- protection_title=National Forest
- Child multipolygons for each wilderness area (if any):
- boundary=protected_area
- protect_class=1b
- protection_title=Wilderness
- name=*
- Child multipolygons for each recreation area (if any):
- boundary=protected_area
- protect_class=5
- protection_title=Recreation/Landscape
- name=*
- Additional child multipolygons for otherwise designated parts of the
NF not included above.
Such a structure could have only a single object for those NFs that have a
single uniform protection class, but expands gracefully to more complex
situations where those exist. The big challenge with this scheme is that I
think that the parent relation may need to be a boundary relation
<https://wiki.openstreetmap.org/wiki/Relation:boundary> instead of a
multipolygon relation because ways may be shared between children, eg the
border between a protect_class=6 and a protect_class=1b area would be a
role=outer of both, potentially resulting in an invalid multipolygon
<https://wiki.openstreetmap.org/wiki/Relation:multipolygon#Overlapping.2C_unclosed_member_ways_belonging_to_the_same_role>.
That said, I'm not quite sure of the nuances of valid/invalid multipolygons
that are children of a parent relation and I'd be happy to be wrong on this
point.
On Fri, Jun 26, 2020 at 1:58 PM stevea <stevea...@softworkers.com> wrote:
> Adam Franco <adamfra...@gmail.com> writes (about my 1, 2, 3 post
> potentially defining NF MPs, now clarified that 1 isn't "all enclosing")
> > I think this is correct:.
>
>
> He continues:
> > If there is consensus on dropping (3), then a system for mapping NFs as
> > (1-2) should be possible to figure out. That said, how that OSM object is
> > assembled and tagged may be tricky. In the Green Mountain National forest
> > the (1-2) area contains a large mix of areas with different
> protections...
> > Some of these child boundaries would have their own names and additional
> > tags, others not.
>
> Exactly! I'm not yet ready to say 3) should be dropped, though I strongly
> lean in that direction, as I think it's unnecessary / superfluous given how
> we map "actual" data, not necessarily "Congressional" data, whatever that
> means. Let's allow this list to concur and / or wider consensus to emerge
> about whether 3) can be clearly articulated enough as "here's how we should
> implement these data in the context of a well-crafted NF multipolygon," or
> whether it's not logically / geometrically necessary for OSM to denote and
> should be "dropped." We'll eventually get there; we do inch closer.
> Especially as it seems to be emerging that OSM can (and does)
> well-represent NFs with completely OSM-conforming multipolygons of the sort
> that I describe with 1) and 2), even while I/we look for additional
> guidance on 3). Here's something I'll throw against the wall and see if it
> sticks: maybe 3) (Congressionally-defined boundary) is a sort of crutch, a
> "nice to have," but not strictly logically / geometrically necessary except
> as a rough outline sketch of this NF (for Congress-critters, for low-zoom
> maps). It seems we're there, but again, I solicit clarity on 3) here and
> now.
>
> > I would imagine that the parent NF object that has the name
> > "Green Mountain National Forest" would contain members that had
> > protect_class=6 (resource extraction), protect_class=1b (wilderness),
> > protect_class=5 (recreation areas, Appalation Trail corridor), etc.
>
> Again, yes. To clarify, the NF object itself (the multipolygon's tags,
> I'd discourage calling this "parent" as it means something else in the
> context of relations and super-relations and we shouldn't confuse those)
> would have the name=Green Mountain National Forest + protect_class=6 tags
> (plus others, like operator=USFS). AND the additional members "associated
> with the NF" (like wilderness areas which are "within the NF") would be
> separate polygons with role inner as members of this NF relation, but ALSO
> with their OWN tags (like protect_class=1b and name=Breadloaf Wilderness).
> Yes, this makes "holes" of wilderness inside of the NF, but think about
> it: if the "whole thing less inholdings and stuff that's different" (outer
> minus inners) really deserves protect_class=6 AND the "inners that are
> wilderness" are tagged with protect_class=1b, well, we've got it! Sure,
> doing it like that makes it logically appear (and maybe actually be) that
> wildernesses are excluded from the NF, but in the sense by which we tag
> them, they ARE excluded, even as they are surrounded by something with a
> "lesser" protect_class. Plus, it is the same agency tagged both on the
> multipolygon (for the outer) and its member inners. They are logically
> excluded by being inners, but because the MP is tagged operator=USFS (and
> so should be the inner wildernesses), we "add them back in," at least for
> their operator, by virtue of that tag being on the inners (But being
> differently tagged with protect_class=1b, as they should be). Whew!
>
> > I'm not sure what tagging would be appropriate for the NF object itself
> > maybe these as a starting point?
> > - name=*
> > - boundary=national_park
> > - operator=US Forest Service
>
> That IS a good starting point, for an exposition I recommend our wiki on
> this topic:
>
> https://wiki.openstreetmap.org/wiki/United_States/Public_lands#Agriculture_Department_.28USDA.29_National_Forests_.28USFS.29.2C_National_Grasslands.2C_Special_Biological_Areas
> (Full disclosure, I'm a significant author of this wiki, even as I and
> other authors earnestly seek wider contributions to it). There, we say:
>
> • boundary=protected_area
> • protect_class=6
> • protection_title=National Forest
> • ownership=national
> • operator=United States Department of Agriculture, Forest Service
>
> Regarding the subtopic (in this context) of "Ranger Districts," I think
> that can be accommodated with polygons of the particular areas that make up
> the MP of the NF and naming them accordingly. It might take some work on
> the part of an intrepid OSM mapper to do this, as I'm not sure the way the
> USFS publishes the geo data of the NFs these are quite delineated "by
> Ranger District," but it could be done. And maybe it should be, I think it
> would be a nice thing to map.
>
> Hey, it's a TALK page. We're TALKING. It sometimes takes quite a few
> words to do that.
>
> SteveA
_______________________________________________
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
