Thanks for deleting the wooded areas here and at Stevenson. As I mentioned before, doing this can be complicated and there are no "easy answers" (yet, anyway, regarding wooded/forested areas). Happy mapping!

Excellent. The wiki and forum are excellent resources and allow a self-guided way to learn about OSM at your own pace in the directions that specifically interest you.

Yes, the usual "specificity of confusion" about treed, wooded, forested areas has to do with the differences between "land USE" and "land COVER." OSM still has not fully resolved this and it remains an odd and difficult concept to explain the whole history of, especially to beginners.

As Santa Cruz (County) is 2/3 wooded, it makes things even more confusing, as many wish to explicitly show that something is wooded (or not, as with landuse=meadow) leading to some, uh, "interesting," (yet sometimes pretty, or "visually pleasing" areas, like Wilder Ranch State Park, where leisure=park is assumed to be wooded, except where a landuse=meadow means, "but not here"). The UCSC campus is much like that (the two of these do abut) where (except for Natural Reserves, which are also explicitly tagged as natural=wood) it seems to have "evolved around here" that "the UCSC campus is assumed to be natural=wood where the underlying "light yellow of university" shines through (unless there is landuse=meadow, like the Great Meadow or Mima Meadow).

As you can see, it's complicated, yet I believe your removal of these polygons (I have changed them from landuse=forest, clearly they are not, to natural=wood) is correct. Otherwise, as you note, you'd be "chasing tagging wood" all over campus, and the exceptions to exceptions to "loose rules" would likely make everybody's head spin.

I'd be delighted if you were to remove these two (the Crown-9/10 one and the Stevenson-Cowell one) polygons.

In the future, I'm also delighted that there is another enthusiastic OSM volunteer around Santa Cruz willing to read wiki and do his or her best to contribute great data to our wonderful map. Additionally, I offer you my firm commitment to do my best to answer any questions you might have, please simply "missive" me using OSM's built-in message system to stevea and I'll share with you the benefit of my knowledge, technical skills and sense of a decade of history in the project.

Happy mapping!

Steve

Changing this from landuse=forest to natural=wood, though it might be better to be deleted.

It may be that the best thing is to examine what is meant by OSM's tenet of "don't tag for the renderer" and to ask yourself/ourselves why we wish for "wooded areas" (maybe forest, maybe wood, maybe trees) to be so tagged and/or so rendered. It does seem to be part of the "more difficult, harder, chewier and maybe never-to-be-fully-answered" aspects of OSM. Or even mapping, or how the human race thinks about landuse/landcover in these days of global warming, trees dying of drought, examinations of "must we really be tree stewards, as well?" (the answer seems to often be "yes, if we are good humans") and so on. It is almost horribly complex, yet we find ourselves here simply as we attempt to be "good mappers." It seems like a conundrum, yet it isn't, it just makes me stroke my chin in the habit of any good philosopher and steward of Planet Earth, as a human, its presently-dominant species.

Or, something like that. And, 2/3 of Santa Cruz County is "covered with trees," so in a sense, "I know what you mean," as I imagine the UC Regents are not totally surprised to consider themselves/ourselves "foresters, as we must manage our trees." It's easy to want a map we participate in to express "yeah, by the way, this area is dense with trees!" and UCSC is a wonderfully unique place of two thousand acres containing MANY trees. Where the lines exactly are is a crazy-wonderful fuzzy edge. Often, I find it most useful for me to fully engage my "listening skills" and simply do that.

As you "agree with" a large segment of the East Field as natural=grassland, I think that tagging the "Stevenson wooded" area as natural=wood (rather than landuse=forest, as it sort of isn't more than it sort of is) I think we (me and many OSM volunteers included) might find ourselves in a kind of harmony.

It's a long, somewhat chewy, for-a-lot-of-different-reasons, complicated conversation.

I look forward to your further participation, response and good dialog.

As I've said about the Stevenson forest, maybe natural=wood, maybe landcover=trees. It's sort of ticklish. But I don't think it's landuse=forest.

Wilmaps (nice to "meet" you): This is not the best tag on any "treed" campus area that isn't zoned or has a specific landuse. The tag landuse=forest is "to mark areas of land managed for forestry." This isn't that.

If you haven't, please read how complex and directly conflicting (with natural=wood) the tagging schemes can get at our wiki, osm.wiki/Forest . Or, see a recent controversy (one that's been going on for many, many years; I recall one I participated in back in 2009, here: https://lists.openstreetmap.org/pipermail/tagging/2019-January/042338.html , where in just a few days, dozens or a hundred?) of conflicting posts still couldn't unravel the arguments of this/these vs. that/those tagging conventions regarding "wooded" areas.

In the meantime, especially because this is an incorrect tag (these trees are not being "grown" to be "harvested" as they are in real timber-production zones, what OSM means by the "forest" tag), I suggest you remove this polygon in OSM.

Yes, The Natural Reserves are largely wooded (and tagged so), yes, the landuse=meadow polygons do a nice job of showing where there are meadows on campus. The fact that "amenity=university" renders "light yellowish" where no other landuse=* or natural=* polygon superimposes upon it does NOT mean that we should start adding land COVER (quite distinct from land USE) to these areas. In short: #1, "don't tag for the renderer" and #2, "it is complicated." (And has been complicated for some time, and is still quite controversial, with no end to the debate about "best practices" in sight).

What is your source for the lcn=15 route? You might say "an on-the-ground sign" and I'd be OK with that. Here is a map which does not show route 15: https://www.marinbike.org/wp-content/uploads/2016/06/Marin-Bike-Map-full.jpg

You're welcome, thanks and a polite wave in your direction.

Hi Clay. I think OSM's data can express what I believe you're doing here with simple tags rather than Relation: 7453451. I think what you want to do is tag all elements in that relation with owner=UP;operator=BNSF and you're done. Relation: 7453451 can then be deleted.

Steve

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