Re: [Talk-us] National Forest boundaries

[stevea]

Adam Franco  writes:
> 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.
> ...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 considered that possibility might or would arise even as I was writing what I 
wrote and after considering what you write here, I do agree.  I was attempting 
to take a shortcut to keep things simple, but this stuff is anything but simple!

> 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).

That is an admirable goal, seems correct (to me) and I almost hungrily await a 
data model than can capture it.

> Here's an example:
>   - Parent relation:
> - name=Xxxx National Forest
> - operator=United States Department of Agriculture, Forest Service
> - ownership=national

Ah, OK, If you really DO mean "parent" relation and we move into using 
super-relations, got it; that's OK if it is what you mean to express, please 
use the word "super-relation" (a relation of relations).  In a super-relation, 
the term "parent" can apply to "the" (root) of the super-relation, and "a child 
relationship" happens between the "parent super-relation" and each of the 
member relations (which are its "children").  Thank you for making that 
explicit.  I fully anticipated that a "more correct" method to do this (complex 
NF data relationships in OSM) might necessarily "move up" to super-relations, 
so here we go!

For these readers not familiar with super-relations, buckle up and study about 
them, they are both complex and powerful, so understanding the data 
relationships can be difficult.  But, sometimes (as I suspect here), there 
isn't any other good method to do what needs doing.  I've been using 
super-relations in very large bicycle route relations (e.g. ECG) for many 
years, and while complex, they both break things apart into sensible chunks and 
logically put things together in a way which (to those practiced familiar with 
how super-relations work), can and do nicely express complexities both 
understandably (more-or-less!) and which are topologically (geometrically, 
mathematically / logically, route-sensibly...) correct.

> *(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.

Dang, that seems quite workable!  At least at the "human builds complex 
super-relation structure" level, it makes sense to me.  Whether renderers make 
sense of it highly depends on the renderer:  some parse super-relations, some 
don't.  I invite Mr. Joseph Eisenberg to say what Carto might do.  (Or even 
intends to do?)  I'm literally nodding my head and smiling that ANYbody posted 
this here:  very cool!  I like!  Adam, I feel like ringing a bell and saying 
"we have a winner," but let's vet this more widely.  I'm excited, but let's 
pick it apart some more.

> 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.

Hm, some examples would help me wrap my head around this better.  I agree for 
"single," but I'd like to see what you mean by "more complex situations."

> The big challenge with this scheme is that I
> think that the parent relation may need to be a boundary relation
>  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
> .

Yes, that would break JOSM's Validator plug-in, for sure (not potentially, I've 
seen this and done this and the only way to upload the MP is "in Error" or 
after it is corrected so that there are no shared outer ways).

> That said, I'm not quite 

Re: [Talk-us] National Forest boundaries

[Adam Franco]

>
> > 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
 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
.
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  wrote:

> Adam Franco  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 

Re: [Talk-us] National Forest boundaries

[stevea]

Adam Franco  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

Re: [Talk-us] National Forest boundaries

[stevea]

On Jun 26, 2020, at 7:31 AM, Bradley White  wrote:
> In most county assessor records, the name on the "title" of USFS owned
> land is "United States of America", "United States Forest Service", or
> some variant. The federal government owns the land, and manages the
> land resource as well as US citizens' legal right to access the land
> (barring conservation necessities that limit access to certain users
> or any public at all).

We can chalk up "owned by USFS" is really "operated by USFS and owned by the 
People" as a minor quibble, we're saying the same thing.  Yes, sometimes 
"conservation necessities" means on certain polygons, protect_class=6 and / or 
access=* might be changed to other values.  Makes sense.

>> A USFS NF is a "virtual" multipolygon (not one in OSM, we get to that later) 
>> of three kinds of things:
>> 
>> 1) An "outer" (but not the largest one) which is "the enclosing land which 
>> USFS manages, except for inholdings, below,"
>> 2) Zero to many "inner" polygons, representing inholdings (and with the 
>> usual "hole" semantic of exclusion from 1), above and
>> 3) An even LARGER and ENCLOSING of 1) "outer" which Congress declares is the 
>> geographic extent to which USFS may or might "have influence to someday 
>> manage."
> 
> Sort of. Administratively, the USFS operates 9 regions containing 154
> "national forests", with each forest being subdivided by a number of
> ranger districts. The federal government also owns large swaths of
> land across the country. These parcels are then managed by whichever
> national forest (and ranger district) they happen to be located in.
> There isn't necessarily an "outer" way enclosing the land that the
> USFS manages, there is just a sum of US-owned parcels that fall within
> a certain NF boundary that represents the actual land managed by the
> USFS. In OSM practice, this is often a very complicated multipolygon
> with multiple 'outer' members, which is usually required in order to
> avoid self-intersecting rings.

One clear take-away from this is self-intersecting rings are not OK.  OSM's 
rules for a proper multipolygon say that already, so no harm, but OK, at least 
Congress and OSM's rules for "don't self-intersect in multipolygons" agree with 
each other.  (Good).  A more significant result I get is that the "big outer" 
isn't "enclosing" but rather a "sum."  That makes sense, too:  these shouldn't 
necessarily be contiguous and I'm sure in many cases they are not.  So I now 
understand that was a minor fault in my 1) 2) 3) posit (1, specifically).  
However, where I fail to "tame the tiger I've grabbed by the tail" is how that 
sum (of outers) "falls within a certain NF boundary that represents the actual 
land managed by the USFS."  I read those words over and over again and still am 
confused between what they say and how I've posited 1) (a bit better now) and 
3).  Why do we need both?  Do we?  I guess I'm still fuzzy on that pesky 
"Congressionally-defined" boundary separate from the logical "sum" of the 
outers which are USFS-managed.  Does an OSM multipolygon need to delineate this 
("falls within..."), or is it sufficient that "the sum of US-owned parcels" (as 
outers, with inners logically subtracted) already fully describes the 
multipolygon?  Please help me understand why Congress declares something that 
"the logical geometry" (of a proper multipolygon) already describes!

I appreciate Paul's interjection of "here is some mind-blowing mess," as I 
think most of us who look at such geo data / landuse / land ownership / 
management and have seen such "checkerboards" understand this sort of 
micro-level of complexity as "merely" a pattern of more-or-less regularized 
(square mile at-a-time) application of these macro-level rules we're hammering 
out.  I'm fine with properly tagging BLM, USFS, BLM, USFS, BLM, USFS on miles 
inside of township-sized grids inside of a federally-managed area.  I'm not 
(quite, yet) fine with the higher-level "whole thing" tagging which includes 
that pesky Congressionally-declared entity.  I and we get closer, I think, as 
Bradley's "Sort of" exposition gets ME closer, but (and I don't want to seem 
like I'm simply drubbing this horribly) I don't think we (readers of this list) 
are fully there yet.

It DOES seem that OSM can well-construct USFS NF multipolygons with one-to-many 
outers, one-to-many inners (inholdings) and both tags on the multipolygon 
itself (protect_class=6, operator=USFS, protection_title=National Forest...) 
AND tags on the individual inner members which are different (operator=BLM, for 
example).  I've understood this and tagged like this for many years (and 
thought I've done a decent job of building NFs, at least in California, where I 
primarily map).  But then this topic of Congressionally-defined reared its 
head, and it still spins mine around.  Can anyone continue to offer more 
clarity about this?  Bradley, thank you so much for all you've said so far, I 
do get closer 

Re: [Talk-us] National Forest boundaries

[Paul Johnson]

On Fri, Jun 26, 2020 at 9:31 AM Bradley White 
wrote:

> > We were doing great there, then I think my (admonishment?  might be too
> strong) way of expressing "owned and operated by the USFS" is technically,
> accurately stated as "owned by the People, managed / operated specifically
> by the USFS."  If you can agree with me there, I think we can get even
> closer.
>
> In most county assessor records, the name on the "title" of USFS owned
> land is "United States of America", "United States Forest Service", or
> some variant. The federal government owns the land, and manages the
> land resource as well as US citizens' legal right to access the land
> (barring conservation necessities that limit access to certain users
> or any public at all).
>
> > A USFS NF is a "virtual" multipolygon (not one in OSM, we can get to
> that later) of three kinds of things:
> >
> > 1) An "outer" (but not the biggest one) which is "the enclosing land
> which USFS manages, except for inholdings, below,"
> > 2) Zero to many "inner" polygons, representing inholdings (and with the
> usual "hole" semantic of exclusion from 1), above and
> > 3) An even LARGER and ENCLOSING of 1) "outer" which Congress declares is
> the geographic extent to which USFS may or might "have influence to someday
> manage."
>
> Sort of. Administratively, the USFS operates 9 regions containing 154
> "national forests", with each forest being subdivided by a number of
> ranger districts. The federal government also owns large swaths of
> land across the country. These parcels are then managed by whichever
> national forest (and ranger district) they happen to be located in.
> There isn't necessarily an "outer" way enclosing the land that the
> USFS manages, there is just a sum of US-owned parcels that fall within
> a certain NF boundary that represents the actual land managed by the
> USFS. In OSM practice, this is often a very complicated multipolygon
> with multiple 'outer' members, which is usually required in order to
> avoid self-intersecting rings.


If you really want to up the difficulty, the east slope of the Cascades
extending east quite some distance has checkerboards of alternating
sections that are National Forest and BLM range with the occasional private
property thrown in for maximum confusion.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest boundaries

[Bradley White]

> We were doing great there, then I think my (admonishment?  might be too 
> strong) way of expressing "owned and operated by the USFS" is technically, 
> accurately stated as "owned by the People, managed / operated specifically by 
> the USFS."  If you can agree with me there, I think we can get even closer.

In most county assessor records, the name on the "title" of USFS owned
land is "United States of America", "United States Forest Service", or
some variant. The federal government owns the land, and manages the
land resource as well as US citizens' legal right to access the land
(barring conservation necessities that limit access to certain users
or any public at all).

> A USFS NF is a "virtual" multipolygon (not one in OSM, we can get to that 
> later) of three kinds of things:
>
> 1) An "outer" (but not the biggest one) which is "the enclosing land which 
> USFS manages, except for inholdings, below,"
> 2) Zero to many "inner" polygons, representing inholdings (and with the usual 
> "hole" semantic of exclusion from 1), above and
> 3) An even LARGER and ENCLOSING of 1) "outer" which Congress declares is the 
> geographic extent to which USFS may or might "have influence to someday 
> manage."

Sort of. Administratively, the USFS operates 9 regions containing 154
"national forests", with each forest being subdivided by a number of
ranger districts. The federal government also owns large swaths of
land across the country. These parcels are then managed by whichever
national forest (and ranger district) they happen to be located in.
There isn't necessarily an "outer" way enclosing the land that the
USFS manages, there is just a sum of US-owned parcels that fall within
a certain NF boundary that represents the actual land managed by the
USFS. In OSM practice, this is often a very complicated multipolygon
with multiple 'outer' members, which is usually required in order to
avoid self-intersecting rings.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us