Changeset: 65966961
Changed west coast National Forests to type=multipolygon instead of boundary
Closed by Adam Schneider
Tags
created_by | JOSM/1.5 (14620 en) |
---|
Discussion
-
Comment from stevea
Adam, national forests (part of the US Department of Agriculture) are not National Parks (part of the US Department of Interior). These should not be tagged boundary=multipolygon (period — that is reserved for the "type" key), they should be tagged boundary=protected_area + protect_class=6 and the boundary:type=protected_area key-value pair should be removed.
Please set tags on all 26 of these National Forests back to what they are supposed to be.
-
Comment from stevea
Update: IF (and ONLY if) they are multipolygons (some are, some are not) set to type=multipolygon. Otherwise, correct tags are boundary=protected_area and protect_class=6 and removing boundary:type=protected_area.
-
Comment from Adam Schneider
I personally didn't set them as boundary=national_park; I just changed them to multipolygons, which they definitely should be.
As to what value should be assigned to the "boundary" tag, that seems to be up for debate. (See: https://wiki.openstreetmap.org/wiki/WikiProject_United_States_Public_Lands.) "National Forests" in the U.S. have the same legal status as "National Parks" in some other countries. I don't have a strong opinion either way.
-
Comment from stevea
And this: https://wiki.openstreetmap.org/wiki/US_Forest_Service_Data#Wilderness_Boundaries says to tag the way I tag, so I understand the confusion.
OK, I found your assertion of type=multipolygon to be true (all 26 in this changeset are, but not all protected_areas across the country are), so I left that tag there, because it is true for these. I also conflated relation 70010 into 70986, because they are the same entity.
However, rather than changing all of the entities in this changeset (and indeed all of the USA) from boundary=national_park to boundary=protected_area (and assuring there is also the correct "paired tag" with that of protect_class=6), I'll wait for the Carto folks to better render boundary=protected_area. (There is a move to get the recently "vote approved" boundary=aboriginal_lands rendered in Carto, for example, so render work for these keys does slowly improve). I would like to see deleted on all 26 relations here the boundary:type key, as it is nonsensical and being deprecated, even though your source documents it (as a "red" key, meaning it has no wiki entry).
Summary: longer-term, national parks should be tagged boundary=national_park (as many/most are today) but other protected lands (like these national forests) should be tagged with boundary=protected_area + protect_class=6 as well as having their nonsensical and being-deprecated boundary:type tag removed.
Thanks for your quick reply.
-
Comment from Adam Schneider
Ah yes, now I remember: we've been using "boundary=national_park" because boundary=protected_area doesn't get rendered at all! (Which is the same reason I tag Wildernesses as leisure=nature_reserve.)
As we speak, I'm working on standardizing all the tags on the western NFs.
-
Comment from Adam Schneider
Next task: making sure all the Wilderness areas are included in the NF areas. (I'm not sure why someone decided that they should be separate!) I've already done it for Oregon and Washington.
-
Comment from stevea
Yes, a somewhat-strong tenet of OSM is "don't tag for the renderer" (https://wiki.osm.org/wiki/Tagging_for_the_renderer) but since these are vast areas (30% of the USA land mass, by one estimate), a bit of a wink and a nod seems to be acceptable (I think it rather stinks and hold my nose, wishing this sort of tagging didn't happen) and these sorts of gyrations are done.
For example, I sincerely believe that adding a leisure=nature_reserve to a Wilderness is technically incorrect, yet I know many do exactly that. WHen you say "standardizing" there really is no such thing, simply this opinion vs. that opinion.
Honestly, the sooner (the better) for Carto to start to render boundary=protected_area (though the myriad protect_class values make this difficult: look how much wrangling goes on to simply render boundary=aboriginal_lands in a single color).
-
Comment from stevea
Wilderness are ABSOLUTELY different and therefore must be separate. For example, in Los Padres National Forest (LPNF), I can collect downed wood (it is a forest, I am its owner) and build a campfire (provided there are no burn restrictions in effect). I am not allowed to do any such thing in Ventana Wilderness, a significant part of LPNF. These are distinctly different landuses and this must be accounted for in the tags, this is why they have different names (NF vs. Wilderness, protect_class=6 vs. protect_class=1b).
-
Comment from Adam Schneider
By "standardizing", I mean setting all the National Forests to the same set of tags, so they'll all render consistently with each other, at least. Then, when the carto people finally figure out a better solution, it'll be easy to set them to where they should be.
(I also don't think leisure=nature_reserve is necessarily "incorrect" for wildernesses. The wiki page says it should be used on "a protected area of importance for wildlife, flora, fauna or features of geological or other special interest, which is reserved and managed for conservation and to provide special opportunities for study or research.")
-
Comment from Adam Schneider
Wildernesses are generally inside National Forests; when you're in Ventana Wilderness, you're ALSO inside Los Padres NF. When you're in Mount Jefferson Wilderness, you might be in any one of three different National Forests. By making them separate entities, we'd have to erase the inter-NF boundaries inside the forest, and that isn't right.
-
Comment from Adam Schneider
If you're looking for guidance from a protect_class, I suppose the thing to do would be to see which polygons you're inside and go with the lowest number that applies to that location.
-
Comment from stevea
I know, I've tagged this way before MYSELF on wilderness areas. There is a lot of history going on here (I've been repeating myself on these issues for almost ten years in OSM) and the main reason is that leisure=nature_reserve renders and boundary=protected_area doesn't render (yet). I'm glad you have an eye towards the future when boundary=protected_area WILL render, as I do, too. However, do know that while leisure=nature_reserve on a Wilderness boundary isn't "sloppy-bad wrong" it has been effectively superseded by protected_area and 1b. But those don't render, yada-yada. I get it, I hope you do, too, it appears you largely do as you say "when the carto people finally figure out a better solution...". This stuff is messy and has a whole lot of history and a future that still has yet to unfold. So, we have a bit of a mess on our hands. Thanks for keeping it civil.
-
Comment from stevea
Mmmm, "lower number" (of protect_class) doesn't automatically always mean "more protection." It might appear that way, but I don't think it should be applied as a rule.
-
Comment from stevea
Right, Ventana is inside of LPNF, AND it has stronger protections (1b vs. 6).
-
Comment from Adam Schneider
No, I'm not suggesting that it should be a "rule" that's programmed into OSM somewhere. After all, it's not OSM's job to communicate the laws that apply to a wilderness. But I do think it's important that a National Forest's boundaries should include ALL of the land managed/owned by that NF; it's misleading if the wilderness makes a "hole" in the forest. After all, when you're in Ventana and you meet a ranger, it's a Los Padres ranger, not a Ventana ranger!
Meanwhile, I need to start over on my cleanup task, because those Shasta-Trinity changes are wreaking havoc with my conflict resolution panel. :)
-
Comment from phidauex
Hi, I'm interested in this discussion because I've done some repairs to CO and WY national forests. I agree with the end result here, but I question the "type=multipolygon" part of the relation. I thought "type=boundary" was actually the newer standard, with "type=multipolygon" being deprecated for boundaries? https://wiki.openstreetmap.org/wiki/Relation:boundary
-
Comment from stevea
Again, we agree: wilderness which is truly part of a NF shouldn't be a "hole" in a NF, it should be "part of it" but with protect_class=1b instead of the "enclosing" protect_class=6.
Regarding your Shasta conflicts, I suppose I could say "I'm sorry," yet I don't believe did anything wrong, rather simply conflated two entities into one when that was the correct thing to do. I have struggled through some unbelievably painful JOSM conflicts, so I do feel your pain. There is a single node there (one of those funny "corner boundaries") which threw Validator for a minor warning, but otherwise relation/70986 seems pretty "clean." (Although any multipolygon relation with almost 200 elements is certainly "complex.")
-
Comment from Adam Schneider
stevea: No worries. It happens.
phidauex: It's a good question. I thought that type=boundary was more for political entities (states, counties) that might end at a coastline and so might not be "closed," whereas a National Forest is always a defined area. It seems unresolved on the "boundary" talk page: https://wiki.openstreetmap.org/wiki/Talk:Relation:boundary
-
Comment from stevea
phidauex, for those "simple polygons" which don't need the extra topological complexity of why "multipolygon" exists (e.g. "holes" and the need for "inner" and "outer" roles on elements), there is absolutely no need to tag type=multipolygon. (By omitting this, you do end up needing to put a key of type with SOME value into the relation, so use type=boundary in the case of simple polygons).
However, most of the time, these really are complex enough to warrant type=multipolygon (with outer and inner role set on elements as appropriate) and so in those cases, tag with key boundary. That key can have many values, among them national_park but more recently (and it is attempted to be more accurately) with the boundary key's "paired tag" of the protect_class key, which has dozens of numerical values).
It's not really correct to say that type=multipolygon is deprecated as #1, that's not true, and #2, if the "lands" you are describing really NEED multipolygon topological "richness" to describe them (with inner and outer roles), then nothing else will do. Please don't confuse multipolygon (a way of describing complex topology) with the sort of boundary the relation intends to convey (it might be a national_park, aboriginal_lands, something which protected_area + protect_class=xy better describes, etc.)
-
Comment from phidauex
I think I understand now, in that case, the Medicine Bow relation should indeed be "type=multipolygon" (I see Adam just changed it!). Clearly it worked both ways, but I suppose this is the better long-term path.
To the issue of "holes" for wilderness areas, I'd be interested in the consensus on that (and maybe an update to the wiki?). Medicine Bow has a few of those as well, in both "forms" of a complete "hole", as well as a "notch" cut out of the side.
-
Comment from stevea
phidauex: the topic is richly documented at https://wiki.osm.org/wiki/Relation:multipolygon . Should you continue to have questions, you might missive me or Adam directly, or use the Talk page on that wiki.
-
Comment from Adam Schneider
As for the issue of wilderness "holes," Steve and I are debating it via direct message!
-
Comment from stevea
Well, discussing, perhaps "debating" is a bit strong. It's a long-time discussion in OSM, at least nine years old, and I've been pushing and pulling at this saw for various reasons and in various directions for much of that time.
Simply put, is a Wilderness "in" (enclosed by) a National Forest? Or is it "a thing unto itself." Historically a W might have been "carved out" of a NF, but as the landuses are now different, a strong argument (not debate) can be made for saying "thing unto itself." Round and round we go.
-
Comment from phidauex
Thanks, I think I understand the technical implications in the data model now. I think the issue is really just one of semantic representation of the real world (which requires us to figure out what is going on there).
I don't think anyone would argue that if I was standing in Medicine Bow National Forest that I would be simultaneously "inside of" Medicine Bow, the State of Wyoming, and the United States of America, all at the same time. Likewise (insofar as US law is concerned), if you are standing in the Navajo Nation you are inside of the Navajo Nation, the state of Arizona, and the United States.
I suppose a quick way to find out would be to break a law in the Encampment River Wilderness Area and see how many organizations ticket you. ;)
I'll follow the discussions from the sidelines, and then can help with any required modifications in the mountain west.
-
Comment from phidauex
From the Dept. of the Interior: "Wilderness areas can be part of national parks, national wildlife refuges, national forests or public lands managed by the Bureau of Land Management." https://www.doi.gov/blog/americas-public-lands-explained
Unfortunately, that results in just an "it depends" answer - some wildernesses are part of and managed by a national park or forest, and others are not.
-
Comment from Adam Schneider
Well, I just think Steve is wrong. :D If I download the USFS boundary shapefiles from their Web site, I get complete shapes that include the wilderness areas. Seems to me that would be gospel. (Dramatic animated example: https://i.imgur.com/o6ftnOF.gif )
-
Comment from Adam Schneider
Oh, and by the way, add this layer to JOSM if you know how; it's super-duper useful: wms:https://apps.fs.usda.gov/arcx/services/EDW/EDW_BasicOwnership_01/MapServer/WmsServer?FORMAT=image/jpeg&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=0&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}
-
Comment from stevea
Look, I've been trying to sort this out amidst misunderstandings, changes between Standard and Carto, updated (and updated and updated...) official USDA GIS data, whether or not Silver Peak Wilderness is or isn't part of LPNF, people misunderstanding "shared polygon boundaries" (and misusing the "reltoolbox" JOSM plugin...) and on and on for almost a decade in this project.
If you really believe you know what you are doing, go nuts. Edit National Forests and Wilderness boundaries to your heart's content. The "rules" or "OSM conventions" (of that day in the future when some upstart who knows better) comes along and challenges what you do today, and then it'll be your turn. I'm done here.
-
Comment from phidauex
Apologies for frustrating you. I agree that consistency is important, especially over time. I'm just watching and learning so I can best maintain the resources in my area.
-
Comment from Adam Schneider
phidauex, I think the most important thing is to (1) be consistent, and (2) create well-constructed relations. The individual tags can always be adjusted later.
-
Comment from stevea
Both of you/everybody: overlapping vs. "glommed together" (multi)polygons w.r.t. national forest lands and wilderness areas is at least a decade-old dialog in OSM. The bottom line is "these topic are complex" and "often, it depends."
There are various ways to enter these data into OSM (simple polygons, multipolygons, overlapping, shared edges, distinct...) and while it may be more true in some cases and less so in others that "these DO overlap!" (vs. "no, they don't") the important thing is to enter the data in as straightforward and clearly correct method that you can. In short, "map your best" remains true.
(As does, "stay civil in dialog," and "dialog with your fellow mappers civilly"). We're doing fine here, complex as these (old, somewhat difficult, often bifurcating/dividing) topics can be.
Let's not be frustrated, let's be good mappers. Sometimes that takes hashing things out with civil dialog, sometimes that takes a fair bit of time and effort. So it goes.
Ways (2)
Relations (1-20 of 26)
- 1
- 2
- Shasta-Trinity National Forest (70010), v17
- Shasta-Trinity National Forest (70986), v30
- Klamath National Forest (971999), v28
- Modoc National Forest (972003), v14
- Tahoe National Forest (972004), v33
- Eldorado National Forest (972006), v35
- Lassen National Forest (972007), v20
- Stanislaus National Forest (972008), v38
- Plumas National Forest (972010), v18
- Sierra National Forest (972011), v25
- Sequoia National Forest (972017), v20
- Mendocino National Forest (2067891), v16
- Inyo National Forest (2300949), v45
- Six Rivers National Forest (2658152), v21
- Los Padres National Forest (2784140), v43
- Angeles National Forest (2786724), v24
- San Bernardino National Forest (2788312), v15
- Cleveland National Forest (2788396), v15
- Lolo National Forest (4459884), v20
- Nez Perce National Forest (5171354), v9
Nodes (1)
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |