Nope: this is a highway=residential, not tertiary, despite the designation as "State Route 35." I've driven it many times, and while the 35 designation does correctly characterize it as a through route (to Hwy 17 and Santa Cruz County, for example), it is exceedingly sinuous, likely very greatly driven by those who live on it only (or scenic-interested tourists, or when other roads are closed as a detour) and has an effective speed limit of maybe 10 to 15 MPH. (California's Basic Speed Law says a road may only be driven "as fast as is safe"). It serves only residences and the aforementioned (quite rare) through traffic.

Changing this from tertiary to residential.

The CORRECT and PREFERRED work to do here would NOT have been to WHOLLY change lots of highway=trunk to highway=primary. There are many places along here which ARE highway=trunk (three- or four-lane, divided higher-speed > 50 MPH / 80 km/h.

Are you going to take the time and effort to tag which are which? You should! If you don't, somebody else is going to have to come in and fine tune your very large edit (it is also blithely inaccurate, ignoring true nuances in the local roadway).

MAP! Please don't make massive changes like this when going too far in another direction is also a poor or even downright bad edit, like this one. If you are going to take the time to correct something, do the detail work required, don't "hit and run" the whole thing in a single ribbon, as it isn't.

It is landuse in the sense of "use" rather than "actual cover," in other words "zoning" as farmland, not necessarily farmland. (From Kern and other County GIS imports).

The balance between landuse and landcover is difficult in OSM. I had to make a choice that the landcover was so vast and incorrect that it was deleted. In some cases, a "mildly correct" landuse=farmland was much better than a ridiculously incorrect natural=heath (as it zoned farmland, even if not being actively farmed).

I think it possible that even this is "too incorrect" and that the landuse and landcover tagging in the area of the Mojave desert and Kern County's landuse farmlands might have to also be essentially completely deleted.

Starting from scratch, with no imports and with much smaller polygons, sometimes is the best way forward.

Following up with more, note the area SE of Uvas Canyon County Park SE to about Mount Madonna County Park / Hecker Pass Highway. Nathan left that in a "crude, sloppy, spilled paint bucket" kind of roughness and it still hasn't (yet) been cleaned up by either Doug or me. We're working on getting there, it might take another year or two, we agree.

That's similar to what you've done in SB / LA / Kern and it was wrong 11 years ago and it's wrong today. Think acres (hectares) and maybe even a square kilometer or two (a square mile at most) in any given edit session. Done right, done well, that can take an hour or more. Hundreds or even tens of thousands of square kilometers of landcover or landuse: those are simply going to be wrong no matter what, even in vast expanses of (heath? scrub? you tell me) the Mojave Desert. Take care to be fine-toothed and accurate, not large-scale and sloppy, just for the sake of seeing some color on a rendering.

I don't mean to sound or be harsh, but I deeply care about growing this map well and I have for my twelfth year now. Please "tend the garden" well if you expect it to grow and bloom well, eventually inspiring others to continue the work (and joy, really) that is mapping in OSM.

A certain amount of "work in progress" is to be expected for such major undertakings. Doug (user:doug_sfba) and I do this around the southeasterly end of the Santa Cruz Mountains, but we do it "one grove at a time" (if not grove, orchard, or greenhouse_horticulture, farmland...) because in these regards, THE SMALLER and MORE ACCURATE, THE BETTER!

It is actually quite helpful to add a FIXME tag saying "Work in progress; I've only done this up to the edge of the Air Force Base" (for example) so that others know what you are up to.

Go ahead and take your time, even as you realize that to do this right (all over Kern and San Bernardino Counties) is going to take maybe four, six, eight years — Doug and I are in it for the "decade long haul." Realize that landuse and landcover are two different semantics (e.g. landuse=military and natural=heath or natural=scrub, which results in an unfortunately nauseating pink-and-olive mixed together - ick!) Just do it in small increments, don't "clobber" over other landuses or landcover as you do (i.e. exclude housing subdivisions, rivers, exceptional landscapes like mountain slopes...) and follow the rules of good polygon construction, please! One of the most important things to do is use JOSM if editing multipolygons (it is the ONLY way to do it, imo) and always click the "sort relation" button (in the relation editor) before you close the relation and ALWAYS clean up any Validator plug-in Errors (and Warnings, too) regarding any multipolygons.

Because the polygon was so gigantic, you have mixed in all sorts of other entities which do not belong in a polygon tagged natural. I'm OK with the occasional "house in the woods" when it makes up 0.01% of a large natural=wood polygon, but in this case there were ALL sorts of exceptions to what should have been contained in a SINGLE natural=scrub polygon.

Two things: do not "double tag" a polygon whereby, say, an entire military reservation is seen as "all heath" (it most absolutely is not – there are industrial, residential, even commercial areas like a PX) and so on the same polygon that is tagged landuse=military, you also tag natural=heath. MUCH better is to break apart the landuse and natural tags to SEPARATE polygons, this allows a much finer gradation of accuracy. It also avoids the very ugly and obviously-wrong "all the scrub stops at the fence" kinds of effects. We used to do this in Santa Cruz County (and some multipolygons are still tagged both with a landuse and, say, natural=wood), but we now know that the much more correct method is with two separate polygons. Landuse is not landcover and they should not be mixed.

Second, please see how doug_sfba and I have shared doing the difficult mix of landuse and landcover in and around the Santa Cruz Mountains, especially along the "spine" of the mountains, the Santa Clara County - Santa Cruz County boundary. While there is still plenty of work to do (especially southeasterly towards San Benito County, where user:nmixter lives and mapped (/maps?) — he is a notoriously bad landuse / landcover mapper who you resemble and was roundly criticized by dozens of OSM volunteers all over California for his "spilling buckets of paint), it does get better and better. This sort of work takes years, not a few days of tens-of-thousands-of-square-kilometers gigantic spilled buckets of landuse or landcover paint.

Be small. Be fine. Don't (generally) import, although I tried to guide Nathan (nmixter) with the Monterey County FMMP import many years ago (read our wiki about it) and the lessons didn't "stick" with him.

In short (too late), just don't make things so big, and especially, don't share boundaries with other polygons: nature doesn't do that, so natural=* polygons should "go as far as they go" when / as they are entered.

relation/6575987 is not all wooded and is far, far too large (and inaccurate) to represent such a natural landcover. I have deleted it.

If you wish to map such things, start smaller, be more accurate and don't stop the boundary of a natural at a park or forest boundary: nature doesn't do that, though sloppy (and wrong) mappers might.

A 600 square kilometer natural=scrub? I don't think so. If you continue to add such gigantic nonsense to the map (like relation/11498462) I will continue to delete them. Please stop with the enormous landuse and natural (multi)polygons: they are obvious and foolish additions to the map. Especially when they aren't even properly-constructed multipolygons!

What are you DOING making a grassland this large?! This is ridiculous without a GREAT deal more detail, especially leaving out as many "inners" as would be reasonably required to make this anything near accurate.

For example, what about the small settlement of twenty or so buildings at the end of Hunewill Ranch Road? Might this area contain some landuse=residential instead of natural=grassland? (Answer: yes).

Grasslands of tens or even hundreds of hectares, OK, if done carefully: I've entered many of these myself. But tens or hundreds (or, like other natural=heath areas you've entered) tens of hundreds of square kilometers?! No, no and no again.

I have asked you kindly before and I do so again, but my patience wears thin: please do not enter enormous areas such as this without a great deal more care, quality and required detail. It seems clear to me you simply want to see gigantic areas of the map blossom with your name on them, and that's not OK with me as it's not OK in OSM.

I ask you to remove this, or I or another OSM Contributor will, wasting everybody's time.

(Whoops, double-entry of the same info; sorry).

What I suggest you do (as it is correct) is to restore the trail, adding access=private. THEN, when the trail actually IS "removed from the real world" (you say "soon," so it hasn't happened yet), it may be removed from OSM.

In my experience, though, a trail being removed in the real world means that it is cordoned off on both ends, allowing nature to reclaim the land. Depending on many factors, this usually takes many years, the trail slowly disappearing until it actually does. During this occurrence of nature reclaiming the trail, I would say it should remain in OSM (with access=private, of course and perhaps a trail_visibility tag that gets progressively worse) until it truly vanishes, THEN it can be removed from OSM. Any other process has a whiff of heavy-handed censorship of OSM, which I discourage: we map what is real, not what we wish to be.

What I suggest (as it is correct) is that you restore the trail, add tag access=private and when it actually IS "removed from the real world" (perhaps by being cordoned off on both ends) THEN remove it from OSM.

Although, in my experience, "trails being removed from the real world" means that they are cordoned off on both ends, then nature reclaims them, with this process often taking many years.

Both of your two sentences are confusing, rather than enlightening, to me. Let me elaborate:

1) You say "this is not public land," which I understand completely. However, "trails are not allowed" isn't something I've ever seen on public land — even wilderness has trails. Trails also exist on private land. So, exactly "who?" is "not allowing" trails? If this is private land, it would be the owner, and that's fine. Please explain.

2) You say "the FS will destroy this trail if they discover it on a map." Do you mean the FS will delete the trail from a map like OSM? Or will the FS delete the trail from the real world? I've never seen the FS removing trails of either sort and #1, removing map data isn't in the FS's mission, and #2, why would the FS have anything to say about this trail, as it is on private land?

So, you see, everything you say doesn't make sense (to me). It might make sense to you, so please better explain it as I am thoroughly confused by why the FS has anything to say about a trail on private land. Thank you for identifying that this is private land, that is new information to me. However, if this trail exists in the real world (as user:SikeMo asserted by entering it into OSM), the data should remain in OSM, but have an additional tag applied to it of access=private, that would be correct in the OSM spirit of tagging real-world objects with proper OSM tags that reflect their characteristics, including access.

Thank you in advance for your answers.

Are you sure this is non-existent. I've seen SikeMo add many absolutely real-world trails. Before deleting this, please contact user:SikeMo.

Thank you for making this fix. I tire of correcting Fluffy89502's bold assertions, too.

Please stop this madness! Adding natural=grassland like relation/11341032 is ridiculous!

Deleted.

I find the absolutely gigantic natural=heath represented by relation/11337591 to be ridiculously oversized: I estimate it at over 15000 square kilometers. Please remove this, or replace it with more accurate and much smaller polygons.

Truly, sweet, nice work here at building up the PTv2 efforts!

I appreciate, too, your education of me on this topic, as it was a fuzzy edge in my understanding of where PTv1 "becomes" PTv2 and now I better understand it. I recognize you are "monitoring" how the map is used and doing some extrapolation (more-or-less) of your observations which feed into "quality enough for routing," though I might caution you that while this might be true for some (robust, well-written) routers, it probably isn't for ALL routers. Especially those which expect "fully" complete PTv2 routes (which I still consider to be "contain all platforms" even though I recognize that "0+" technically makes them "PTv2 good enough."

We're teetering on an edge here, thank you for opening my eyes to this. I hope you can also appreciate my position that more platforms be added, something I have written MapRoulette tasks for and been working on in OSM for many years. Building platforms (my "Map Your Train Ride" initiative I started in 2016) can jump-start OSM community and technical development, and in fact, in many communities in the USA, has done exactly that.

Eventually, we'll get good platforms on PT routes, it can't happen enough for me. I believe we should do all we can to encourage this data growth in OSM. Thanks again for your contributions to the map.