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.

These tags on these polygons derive from tags on the government data. If you follow the instructions on the wiki page to access the data (where it says "scroll to Zoning") you can further scroll to "Attributes" where there are some clickable web buttons for each tag. (Some of these, like the SHAPE* data, appear to be broken, this appears to be a bug with the county's GIS web site).

I believe what you are saying (please correct me if I am wrong) is that "because I can't find a wiki page for these tags, they shouldn't be in OSM." As I say above, it is true that a discussion usually ensues about which tags from "official" data are or are not appropriate (some are useful, some are not) when a new version is released (as v5 recently was). However, you haven't made that case.

For the record, I'll say that I find it useful to know, for example in the polygon you quote above, that I find the BASEDTL tag a useful description of how the landuse is actually specifically designated (legally) in this case, the BASENM tag useful similarly, the BASEZN, FULLZN and Zoning tags useful abbreviations of zoning using a countywide standard protocol, the OBJECTID tag helpful for comparison of data between upload_versions, and (as mentioned before) SHAPESTAre and
SHAPESTLen useful geometric devices to accurately capture area and length data of the polygon.

Does that explanation satisfy you? Would you prefer that this be in our wiki? (The reason I hesitated to do so before, is, as I have said, these tags do drift slightly between upload_versions, changing slightly as time goes by, and these data are now in their fifth incarnation as upload_version=5). I really am trying to do the right things here, avoid confusion, document fully and explain this when/where/as required.

Your assumption is mistaken; there is nothing wrong with my latest edits. They are quite intentional and what you call "very strange" are explainable if/as you read our local wiki which has documented the entry of several versions of these polygons for almost ten years. There is a long and storied history of these polygons being introduced into OSM. Please read about it at osm.wiki/Santa_Cruz_County,_California#Landuse .

The "license" is that any data (GIS data included) produced by the state of California (as these are, since the County of Santa Cruz is a division of the state) are in the public domain. Numerous state Supreme Court decisions have expressly declared this to be true, making the data harmonious with OSM's ODbL. OSM mappers in California know this, now you do, too.

Wide agreement locally (around here in the OSM community) actually encourages entry of later versions (newer data which update and correct) of these landuse polygons, that is precisely what was done here. They are part of "official" (government-produced) landuse/zoning data and accurately map to what OSM's landuse definitions are (with values of residential, commercial/retail, industrial).

The SHAPE* tags give highly accurate area and length data, and other tags, some of which some do consider superfluous, are usually in a state of flux as the local community decides for any given upload_version which tags are appropriate to keep or discard during upload, as tags do change from version to version.

Were I to start editing in your home town in Germany, before I started doing so I would perform the courtesy of researching local wiki and seeing if there were any local conventions I should know about. Should I find them, I would not immediately assume that "something went wrong" with editing there, I would better understand that these are simply local conventions, documented in wiki and acknowledge by the local OSM community as "this is how we do things here."

By the way, many years ago, Santa Cruz won a Gold Star Award at bestofosm.org, one of only a few places in North America to receive such an accolade. The site notes that Santa Cruz has "nearly perfect landuse!"

I totally forgot about this drinking_fountain. Thanks for adding it!

Right, I know you didn't want to change forest, but you said "forest as a whole" (in your text above). It is crucial that we understand that in OSM, "forest" means "logged land." The campus and parks are not that.

However, they are wooded and then we begin the endless confusion in OSM regarding landuse vs. landcover. It is confusing, people tend to tag for the renderer when they shouldn't, et cetera.

The reason the campus boundary is not wooded is that that really IS tagging for the renderer. It is better, as we say in Local Conventions, "assume it is wooded except where it is tagged otherwise." This allows its primary purpose of "university" to render.

If we go down your path of tagging natural=wood, now many will want to do that to leisure=park, leisure=nature_reserve and so on. It gets horribly complex when you bump up against other polygons such as landuse=forest and even landuse=residential, which are often, too, also heavily wooded around here, even with houses and people living there. Do we really want landuse=residential + natural=wooded? Simply because "it might look better" on the renderer? I don't.

As this is PRIMARILY a university campus, and your tag proposal is largely to tag for the renderer, both OSM tenets of not doing that and local consensus has found that not adding natural=wood to the university (keeping its rendering as is, a university) is best. Yet, to further emphasize that the natural reserve areas are protected and almost exclusively wooded areas, (yes, parts of Lower Moore Creek Natural Reserve are part meadow) we do additionally tag them natural=wood.

I've worked with many university staff, officers, faculty, architect, land steward, transportation officers, etc. as well as developing local consensus over nearly a decade, while still remaining "true" to how OSM does things. Yes, it's complicated around here. Yet it's also "as simple as we an make it so most everybody is happy with the results."

Not a forest, that's where there is logging activity and the natural reserves are certainly not that. There are no tagged forests at UCSC.

The polygons which ARE tagged forest in this county are "Zoning=TP" (timber production), which matches the OSM defenition.

"More accurately than a shapefile originating from the designation of the protected area?" How can you get more accurate than that?

The answer is how it is done: "assume it is wooded except where it is tagged otherwise." This is one of the most heavily wooded university campuses on Earth. It is surrounded by state parks and open space preserves which are also heavily wooded.

It is not "considered a forest as a whole" (there is no logging activity) it is considered wooded. Laws have nothing to do with it.

Please read osm.wiki/Santa_Cruz_County,_California#Local_Conventions

Why are you editing wheelchair accessibility relations? These are from official university data and are correct by definition.

Why are you changing Natural Reserve boundaries? These are official university shapefile polygons and are correct by definition (or at least they were when they were originally uploaded).

The net result of your edit is to have turned nearly ten years of university editing (of its boundary) into a "version 1" of the UCSC campus edge. That is not only immature, it is destructive to the history of edit improvements by many people over a long timeframe. Please stop the name calling.

If you can, it would be mature of you (and technically, professionally and project-consensus-ally) to restore the previous boundary, with all its existing history, rather than submit a brand new (v1) boundary with absolutely no attribution or source tag. If you don't know how to revert a changeset and/or retrieve history-full polygons like this, ask.

Better still would be to not destroy existing map data in the first place, whether inadvertently or as a vandal. As you are a newer mapper and I'm not sure of which of those two intents of yours you mean to effect (I do tend to give people the benefit of doubt), I'll ask you to explain what you meant to do to the campus boundary here.

Additionally, relation/9331155 only includes the eastern "Mainland," not the west coast and full Canadian boundary.

As a US citizen, I'm slightly uncomfortable with the addition of relation/9331155 (Mainland) to relation/148838 (United States).

At the very least, the naming seems wrong, as I seldom if ever say "Mainland" (though I think that you may believe that Pacific Islanders, Alaskans, Puerto Ricans, Virgin Islanders, etc.) say this).

Also, while your alt_name values of "Contiguous United States;Conterminus United States" are sometimes used, they are awkward. I MUCH more often hear (and use myself), "Lower 48" (sometimes preceded by "the") and MUCH more often hear "Continental United States" to refer to the lower 48 states. Also, the Department of Defense / US Military often use the abbreviation CONUS for this.

In short, please reconsider this, or better, delete it, as it is far from consensus actually in existence, and there could be much more discussion about name and/or alt_name values.