Let's stick to this single issue / place for now. When you ask "where else" or "which others" my answer is "all of them" (if that applies). But, one at a time. There are also "front-country/back-country" aspects to this where you start drawing into the map what you do know, even a rough sketch around a picnic area or a directional infosign could suffice.

I saw that you added that, and thank you, it is relevant and does clarify that these are closed areas. That's where I have the disconnect: a closed area really isn't a "leisure" anything, which is why the leisure=nature_reserve tag seems inaccurate to me. When I use that tag, it implies that there is public access (though limited to staying on trails and/or the "wildlife viewing area" which is often fenced, has interpretive signage and suggests binoculars).

These (closed) areas really are not that. The other tags, withOUT leisure=nature_reserve, are sufficient to express these. Although the protect_class=5 that causes rendering in Carto is often "over-applied" (and not strictly an IUCN denotation).

I've been active for almost 15 years in trying to improve the tagging on these in OSM, and it's been a struggle, with a lot of misunderstanding of existing tagging, and more difficult, tagging which evolves. For example, Brian Sperlongano (Zelonewolf) and Kevin Kenny (ke9tv) and I have been working to reduce the protect_class numbering (which is a mess) and introduce "plain English tagging" with protection_class. I realize it can be difficult to follow our wikis, newer proposals, the "drift" in semantics over time as tagging conventions change and evolve, but please take a look at as much wiki as you can on these topics: it's complex, but it does sink in after seeing the historical trajectories OSM has taken in the last decade or so.

There is a leisure=nature_reserve in Santa Cruz (Pogonip Open Space Reserve) which I believe is accurately tagged (that), especially as it is an "open" area, not closed to the public. These (MROSD, others around the Bay Area) which have closed areas shouldn't have leisure=nature_reserve applied. Thanks, I'm happy to further dialog, offer perspective and answer any questions, although I certainly don't know everything!

Nobody said anything about landuse=natural_reserve which is a strongly discouraged tag. I am asserting that leisure=nature_reserve is for areas where "people go for leisure, to the nature reserve" (where they might hike, if they stick to the trail, or stay at the wildlife viewing area, with their binoculars, if they don't want to venture too far into the reserve.

While "special opportunities" do exist for people to visit the actual-wilderness or near-wilderness areas (like it appears this is) you must get a special permit, someone doing specific academic research can be seen to get clear to do botanical or biological or whatever studies, but the general public (who "leisure"), no.

leisure=nature_reserve is an older tag and newer tags (in the protect_class numbered or protection_class plain-English vein) are preferred, as they are much less ambiguous. I really do think this might be a leisure=nature_reserve for some purposes, but both of us don't seem to know that (yet).

Try a site visit and see how difficult that is. That should tell you if this is a (casual) "leisure" area. I think the tagging is otherwise correct without this tag.

I believe so, too!

I'd ask that you remove the leisure=nature_reserve tag from both of these closed polygons, as they are more distinctly "the remaining tagging" which would be correct if "leisure" tagging were removed. There isn't anything leisure about this polygon (in the sense that OSM defines leisure=*). Thanks in advance for seeing this and removing that tag.

Nice work: boundary sharpening from CPAD, as CPAD "had something to offer."

They are mazes indeed. I'll call them "an advanced class in more-complex multipolygons," especially with all the history associated with them.

Still, we seem to make them sturdier, more accurate (punching out inners in correct ways) better tagged and up-to-date with changing tagging tastes. For anybody who keeps track of this (mentally and internally with OSM's history and changeset archives) it is both complex and explainable, but more of the former!

👍

BTW, if you are working on these, might I ask you to also do your best to keep that wiki page synced with your efforts? It's really nice when the wiki chasing the map chasing the wiki chasing the map chasing the wiki finally "settle down" and more-or-less reflect one another.

Yeah, seeing this is barely a kilometer long, it doesn't seem like a "route," although it may certainly be a km or so of bicycle infrastructure. So the way should remain in OSM, but yeah, the relation should be deleted. (It's a mess, as it's both network=lcn, "l" meaning "local," yet the cycle_network=US:NJ tag means a "statewide" / regional route).

I'm comfortable you deleting relation/8780168 and thanks for contacting me!

Taking a look at certain things...stand by.

Ah, it was added over 5 years ago by Valustaides via Changeset #63245538.

See our wiki: osm.wiki/New_Jersey/Cycle_Route_Relations .

Although, I don't recall adding RRA. It might have been that I "touched" this (RRA) relation as I was working on a USBR, 9-11 Trail or the ECG through here. "RRA" seems like something somebody else added.

Can you dig more into the History of the relation you refer to?

Looking nicer and nicer; thanks for your improvements.

That last part I agree with you 100%: 2D, high-altitude (satellite) imagery, unless you're doing something sophisticated and stereoptic — think 3D movie glasses with red and blue lenses — can be the very definition of bland.

Having "cliffs, canyons and crevices" pretty much "jump out at you" is one of the more fun aspects of mapping I've discovered. With these data, that happens way more often that with satellite data; they can certainly be "richer" that way.

It's like having two clocks (or watches): unless they exactly agree, you're not really sure exactly what time it is. USGS can be out-of-date for trails (closed, overgrown... (though, stream data stays pretty consistent). 3DEP can be high-quality, but it may not be better than local data (or, it might be, hard to say).

With OSM, "on the ground" data (a GPS survey, best with a "deep woods" receiver that has 16 channels or better of satellite reception) is usually accepted as definitive or authoritative, though official sources (federal, state, local) can be excellent. As long as it is moving from good to better and better to "essentially perfect," OSM moves in the right direction!

Nice work with "visible trails in 3DEP;" good to see official trails match both Calif. State Parks and USGS data. I'm not sure where the stream / creek data came from, but just across the border in Santa Cruz County, stream data came from SCCGIS.

Thank you!

Thank you for your additional comments. I am glad we found some common ground, that the incorrect data have been removed, and that this sort of error will not happen again (by you adding rail data which OSM agrees should not be in our map).

There are some kinds of rail data we do add to our map and some kinds of rail data (like the kind you entered) which we do not add to our map. Thank you for observing and respecting that distinction.

You would be incorrect that I checked your profile to determine your age; I did not. I simply guessed (by your behavior, the "but I don't want to do it by myself" sounded childish, so I guessed correctly).

Let's tone down what shouldn't be aggressive nor angry. I am not trying to create tensions, either. I most certainly have not threatened you, nor do I mean to do so.

If you find it "difficult to remove what you have added to the map," that is a problem. It actually does mean that you should not be adding things to the map in the first place (if you are unable or unwilling to remove them, especially if they are in error, and very especially if they are the same type of error data which you have entered before as an error, then you did it again).

Your error data have been removed by another OSM volunteer (IIVQ). Please: do not add more "rail data" to OSM.