Redacted.

Oh, there's plenty of "by hand" around here!

(Not to mention that CPAD 2018a has plenty of problems, and will continue to revise to not only update, but correct errors, according to Maiana Voge, Associate Director at GreenInfo).

Steve

Ah, looks like we crossed messages.

OK, CPAD (not CDPA) is well-established around here, we're now on 2018a (or what we're calling v2 — see our county wiki) and I just spoke with GreenInfo (CPAD's publisher) a few weeks ago. Again, please see our wiki, there is a LOT there because there is a LOT going in this county, and there has been for at least 12 years.

I think it's possible why you think the Preserve's boundaries were missing is that it wasn't rendering in Carto. That's because it was (and is) tagged leisure=nature_reserve and boundary=protected_area (first doesn't really render and second only draws a green edge).

I'm about to "pull the big switch" (go to bed) after a very long day and we have a scheduled power outage around here tomorrow morning and most of the workday, so I won't be able to get to redacting / correcting until Friday.

Please leave the CPAD v2 conflation in Santa Cruz County to locals familiar with merging it with the SCCGIS (county GIS department) v5 update, also simultaneously going on (see the wiki!) It's complicated, nuanced and while I'm not saying you can't do it, there are cooler heads prevailing getting it done.

Thanks,
Steve

CDPA = California Desert Protection Act? Please don't abbreviate (without a pointer or wiki doc which expands it) as I don't know what your source is. Do you mean CPAD?

And you say "Strava Heatmap." Only a low resolution version works now, you now must use a complicated workaround otherwise. And if you are using the hi-res version, are you using the API (which requires a Strava license/login) or JOSM's imagery prefs? Please know that Strava Slide is broken now, maybe that's what's wrong.

Steve (speaker at multiple OSM conferences and largely, the most prolific author of osm.wiki/Santa_Cruz_County, though there are plenty of contributors around here who do good work.)

Mr. Schneider: What is it, exactly, you attempt to accomplish in this changeset? I visit your edits and find well-established local polygons (virtually all that you touched) shifted by two to ten meters in no predictable direction, leaving gaps in rendering and really, a fair-sized mess.

You are using the most recent version of JOSM (which recently updated), so I assume you are a conscientious and skilled editor who heeds updates. However, your results lead me to conclude otherwise.

Unless I better understand what it is you are attempting to accomplish, I am inclined to redact the entire changeset. I mean, look at way/40896591, a residential polygon minding its own business. Its southeastern corner has been deleted and it has been shifted by at least two meters southeasterly. WTF? BD Eco Reserve itself (relation/9363262) is shifted at least a meter westerly in some places, has corner nodes at wonky, non-square angles and is SE shifted six or eight meters in other places. Huh?

Candidly, I have spent quite a bit of time cleaning up the results of your edits (in Felton and Live Oak, especially) and I honestly can't figure out 1) what it is you attempt to do by editing in this area and 2) how you manage to shift so many polygons while editing. Are you aware you do this?

I'm a polite and patient person, but I have my limits when I see this sort of damage continuing in the map around here.

The driveway into the Moon Rocks area does look more accurate, yes. I'm OK with editing data where it improves things while not causing damage to other existing data. But while you might make improvements in minor ways, the greater damage to existing polygons is real.

I haven't said anything to you since our last exchange of missives around New Year's, but these most recent BD Eco Reserve edits are simply beyond the pale. I don't think it is deliberate vandalism, yet even if it is inadvertent, your edits are worse than unhelpful.

Please, at least say what it is you are trying to accomplish here. And maybe my sharp tone can be explained by a JOSM bug (if you're lucky). Otherwise, I believe a redaction of this changeset is in order, although the single positive contribution I can determine you made — better detailing the driveway near Moon Rocks — I'll leave in.

Have you read our county wiki? There is an ongoing landuse update going on and you really are throwing a large monkywrench of mess into it. I'd like to be able to edit and work in OSM with you in a collaborative way, but not like this. It's simply too much mess for too little benefit.

Thanks, Steve (Santa Cruz, California, decade-long OSMer, Mapper of the Month, January 2017, local guy in this part of the map)

If you give me a specific "way link," like way/42472884, I'll take a look. You might read our County wiki at osm.wiki/Santa_Cruz_County,_California#Local_Conventions which says that the campus Natural Reserves are specifically tagged "natural=wood," but even "all wooded" areas of campus are "assumed to be wooded, unless they are tagged otherwise."

Thanks for reaching out / the good dialog.

-Steve

The MNG_AGENCY_TYP should have (and has) become governance_type (thank you). The boundary and protect_class keys were wrongly omitted and have been added (thank you).

So, in short, "thank you!" for helping to correct at least a couple of minor mistakes. As I say in my Mapper of the Month interview, "no mapping task that positively contributes to OSM is too small."

-Steve

By the way, it doesn't always happen this way (the Land Trust might simply continue to protect the land "in perpetuity," but it happens enough to mention that this is how (state, county) parks, open space preserves and similar kinds of lands around here grow, piece by piece. In other words, this might very well someday become part of nearby Portola Redwoods State Park or Long Ridge Open Space Preserve, but "not yet."

Jan: These ALL_CAPS tags are from the CPAD shapefile and I agree with you should be better logically-mapped to OSM tags where possible. See osm.wiki/Santa_Cruz_County,_California#Parks for at least some information about CPAD. The ACRES tag is a vestige, you or I can delete it without harm.

The roads are public access, but are only an "easement" through the property, which remains protected by the local Land Trust (you can also visit their web site at https://www.landtrustsantacruz.org/). I'm not sure you have similar organizations in your country. If you are interested, visit the site and click the What We Do / How We Do It tab.

I wouldn't know how to better tag an "easement" road like this: a public road through a land trust private, protected area any better than it is. I hope my explanation is satisfactory, though you are welcome to edit and improve tagging to something better now that you know (or better understand) what the ownership and access are.

-Steve

Fixed with better tagging, including a source tag (which I thought I put on the changeset, but I didn't, as this "snuck in").

It is about 16 hectares of Land Trust-protected land and now is tagged boundary=protected_area + protect_class=7.

So that I might better find any others like this that might exist, may I ask: how did you discover it?

-Steve

Sure, Chris: cleaning up OSM messes is one of my long-time undertakings in the project, especially when the mess is MINE!

I deleted those two nodes (thanks for your specificity), though I couldn't find any others. Perhaps if you tell me your method for discovering these, I can delete them all. (I loaded into JOSM the PA boundary, then used Validator plug-in to check for "unconnected node with no tag"). I don't see others, but that doesn't mean I might have missed a few!

PA is a weirdly-shaped city: it has that "strip" through the Stanford Dish area to connect the southern park areas to the urbanized area (similar to how San Diego connects San Ysidro's Mexico border area to the rest of the city, Chula Vista and National City are conveniently avoided with a clever "strip" through the bay). In the earlier version before I did this cleanup over last weekend, these were totally disconnected in PA, and it truly needed fixing. I think it is largely OK now. (Though, true to OSM fashion, "the map is never done").

Thanks again for pointing out these node glitches and again, should you find any more, I'll clean them up, or if they are minor, I might ask you to do so.

Regards,
Steve

OK, I think I got them all, but if you find more, please let me know. -Steve

Yes, there a whole bunch of unconnected nodes not "tied together" by a way along San Francisquito Creek. I have no idea why this happened, though I suspect a bug in the JOSM editor: version 14824 which I am using and is current has had several problems I've notice (but not yet reported as defects via bug report).

I'm working on cleaning these up, though it may take me several changesets as I discover them.

Ah, I see what you mean about the ONE node you specify, but I'm now in a better process of discovering any others that exist and clean them up. It's a tricky "changeset inclusion" algorithm I'm applying. Stay tuned, I'm working on it now. This channel is fine for communication. -Steve

First, thank you for calling what appears wrong to me so politely. I reloaded relation/1544955 into my JOSM browser and I found that there is a single point in that relation which had the role "label" instead of the more proper "admin_centre." I have changed this to admin_centre.

While the editor before me placed this "in the general downtown Palo Alto area" (I've been there many times), in a city (like this relation), it emerges as an OSM convention that this be placed at City Hall (rather than the relatively random nearby location of University Avenue and Centennial Walk) — a very minor fix.

However, I can't find what you mean by "a huge chunk of unattached points with no tags along a portion of the...boundary." The members of the City relation do "make a nice loop" with the members, indicating that it is a closed polygon, which for City Limits, is correct and proper.

This was a difficult edit and I was managing multiple data sources, so I am the first to agree with you that I MIGHT have left such a segment, but without some further lat/long coordinates or specific /way or /node specifications, I don't know where you mean. If you help me discover these (where you mean by continuing OSM errors), I'll do my very best to clean them up or apply whatever remedy is correct.

This channel is fine, or you could missive me at user:stevea. Thanks again! -Steve

Hi Benny: Whew, this was five months ago and I barely remember doing so, however, obviously I did. It looks like my changeset comment became a source tag (I didn't know that happened, now I do), so it isn't helpful in the usual regard that I can "simply re-check my source."

As I look at the history of the remaining way so named (way/295951390) I see it was edited prior to me by user:YamaOfParadise who I have found to be sometimes an excellent rail mapper and sometimes a problematic one. No matter how many times I have sent a friendly missive or changeset comment, I never, ever receive an answer. That's point one.

Point two is that that as I examine the changeset (pre-reversion), I see that there was only a single element in it (not really a useful relation, many consider this an OSM error, as the way can contain any tags needed and the relation is superfluous).

Point three is that it was a route=tracks relation, which are essentially never used in the USA or even any of the Americas (North, Central or South): please take a look at our WikiProject_United_States_railways page.

An obsolete/only-used-in-Europe relation type and a relation with only one member both seem like good reasons to delete this, so that's my best attempt at reconstructing my "why" from five months ago.

If you believe that there are additional elements, you could add them back into the map (I have no evidence of this and know how to revert a changeset and search database history in OSM). However, if you do so, I believe it would be correct to use a relation tagged route=railway rather than route=tracks. This relation type can contain members of either active or abandoned rail (as this is).

Gleb, I have fixed to the best of my ability Comstock Mill Road and Robinwood Lane.

Additionally, I'm trying to do the right thing by using the absolutely latest data from SCCGIS (see out County wiki page): the "version 5" data I use are dated 2/9/2019. Those don't seem like they are "outdated" to me.

However, the CPAD v2 data (also see County wiki) DO differ for SDF: the SCCGIS data say SDF is larger, the CPAD data seem to say it is smaller. As you say SDF as entered (with SCCGIS v5 data) are "too big" as they include numerous private property, it is very likely that the CPAD data are more correct than the SCCGIS data (as are true in the West Waddell Wilderness areas of Big Basin State park, especially around the San Mateo County line and Whitehouse Canyon.

I continue to endeavor to correct SDF so that it is correct and if you have additional data of CPAD being "more correct" or "better" (more accurate data) for SDF's boundaries, I am happy to incorporate them.

In short, SDF is in the process of being improved. Give it some time (a week or two).

Fixed. The name_direction tag is a mangled version of a tag from the USA's (problem-ridden) TIGER import of roads and rail. There are some left in Southern California. It is estimated that USA OSM volunteers will clean up TIGER by about 2045. (Sigh).

Hi Jan:

This was a pretty large edit (geographically) and had many elements edited. Which specific datum had that name:direction tag? (Node, way or relation number?) I agree this is a non-standard tag (I didn't add it) and will remove it once I know which element it is on. Thanks.

Now completed/documented in the wiki link noted above. Again, thank you, mueschel.

I can certainly update our local wiki to better document these tags and capture the spirit of this conversation. I agree that would help avoid future confusion. I appreciate that you DID write a comment (here)! Sometimes it takes changeset comments to spark the dialog, a good attitude by mature mappers, an explanation of (local) history, somebody reading a wiki page, somebody UPDATING a wiki page, and the positive intentions of "this is what's best for the map" to all blend together to have the best outcome. I think that's what happened here and I thank you for the good dialog.