Thanks for the heads-up, doug, you've been doing great work here and I'm waiting (and waiting) for SCCGIS to get their act together and come out with newer (multi)polygons. Maybe in 2020 or 2021, I am told.

This polygons turned into a bit of a bone of contention between me and glebius, where he much prefers to use (much more highly-complex for novice mappers) "shared edge multipolygons" (what many call "higher math") geometry. Frederick Ramm convinced Gleb not to change "existing valid data" for "data which are just as valid, but of a different flavor, as it is a waste of time," but these older (version 3 as our county wiki describe them) are getting a bit "long in the tooth" so I don't have any major problem if you wish to update them with better data from MROSD. There are also some newer CPAD (statewide) polygons which I have begun to use to supercede the SCCGIS v3 polygons, though that got a bit messy around Whitehouse Canyon (still not quite right).

In short, go for it!

Steve

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.

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.

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.

phidauex: the topic is richly documented at osm.wiki/Relation:multipolygon . Should you continue to have questions, you might missive me or Adam directly, or use the Talk page on that wiki.

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

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

Right, Ventana is inside of LPNF, AND it has stronger protections (1b vs. 6).

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.

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.

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

Yes, a somewhat-strong tenet of OSM is "don't tag for the renderer" (osm.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).

And this: osm.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.

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.

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.

Thanks, I reverted these back to not being level crossings. This was an "automated" (all ten of them at once) Validator "Fix" that I rather blithely did at once without realizing they were down the middle of the street, but you're right.

Really? I'm OK with trees being named where they have a plaque and maybe a rememberance fund and maybe a bench. I entered a tree like that S of Stevenson Lower Quad about a km away. I don't think naming trees in East Field Parking Lot is that, though I'm willing to be enlightened. As fun as this might have been, please remove the names from these trees, unless they really, really have names.

The guy who entered the trees (unnamed, simply trees) in the first place.

Changed. Of course, you are welcome to make such changes, too; noted in our wiki (osm.wiki/Montana/Railroads) are both (about this rail spur) that "name is speculative" and in general, "improvements are welcome."

Actually, this sort of local knowledge is one of many things that makes OSM a GREAT map. Thank you for your improvements and again, you are welcome to make these yourself, though I appreciate the Changeset Comment as a polite way to call this to my attention.

Happy mapping / see you in the map,

Steve

Postscript: Gaia's topo web rendering of OSM data looks pretty nice!

I'm surprised you or I didn't get an edit conflict. That area is really "all kerb" (or curb as we Americans say) and there is no crossing there, whether on a node or a way, I deleted the way entirely!

As my comments used to say about this area/crossing before I deleted them and their parent ways/nodes, this really was a dangerous area for both cyclists AND pedestrians and the whole area being closed to nothing but automobile traffic is a much smarter and safer designation by the city/county/Caltrans.

I think between the two of us we now have it correct. Thanks again for your good communication.

stevea

Sensibly, the City of Santa Cruz has seen fit to put sharrows (cycleway=shared_lanes) on Fairmount Avenue, so this makes a reasonable connector to include in lcn 45 to get across the freeway at Branciforte Drive (which again, I've done thousands of times myself). It all makes sense now.

stevea