My turn for corrections to my previous:

The sign says "Pedestrians, bicycles an motor-driven cycles prohibited." This is a common sign in California at freeway entrances.

I should have said you"think" I "SHOULDN'T" copy from a County Bike Map, however I happen to know it is perfectly legal to do so.

It's all good.

stevea

I have lived and ridden my bike) in the area for decades, and always found this a "tricky" bicycle area. I have driven this overpass thousands of times and only two days ago noted that from Farimount for the entirety of the "trumpet interchange" (so-called by Caltrans engineers because of its shape) — even if you are a cyclist (or pedestrian) "exiting" at Rooney, as I often do to get to my house) now has a "Pedestrians, bicycles and motor-driven cycles" sign RIGHT THERE (for the overpass), just as you also find at the beginning of any freeway (like the Morrissey Blvd. entrance to Hwy 1 South next to it).

Accordingly, I have removed from this "trumpet" overpass its bicycle tags and the lcn/ref 45 from OSM.

I also appreciate that you "think" I should copy from a County Bike Map, however I happen to "know" that it is: the SCCRTC (I have attended literally dozens of Bicycle Committee Meetings there, and I live in the area under jurisdiction, so as a citizen I'm actually a ranking member there). There are multiple court cases upholding that data published by the state (and the county is a branch of state government) ESPECIALLY GIS data, are in the public domain. Plus, I am the author of the CycleNet numbering protocol proposal, for which we wait for the SCCRTC, its Bicycle Committee and the city jurisdictions affected (four, total) for final approvals.

Thank you for your comments, it really was two days ago I saw the new sign, and I was going to make this edit sometimes this week: your comment prompted me to do so!

stevea

You are welcome for clarification. Tubes needs to be seriously educated that OSM is not his personal rail playground (he is very coy about why he insists on entering rail with his often-metamorphosing odd/wrong methodologies) and if that doesn't "take" or "stick," I believe he should be shown the door.

Nope, @prefix is a Twitter thing I believe. When somebody isn't on Twitter (or social media completely), it doesn't do anything.

Call me old-fashioned (no, I'm not so old fashioned I insist on a hand-written letter sent by pony express with a postage stamp or even a fax), but I'll speak to you by phone (home office or cell), email you, missive you or a variety of other more secure (but not proprietary) methods. Those seem adequate, and we've had a nice back-and-forth here. Again, thanks.

Let's keep a close eye on Tanner.

Steve

Bryan, with this slippery character who uses at least three accounts (maybe more: ethylisocyanate, US Woods and now, Tubes), is disingenuous when I missive him, says one thing and does another, I would call this nice. This is my fourth or fifth attempt to contact him, after he broke off with me earlier this week, we've gone around and around for the better part of a year, he is vandalizing 95% to 98% correct data (hey, I know we'll get it to100% eventually, but I'll take a "solid A" while we do) for some odd pet project or obsession he has to "make USA rail in his own image." He seems to have technical skills, but lacks in OSM social skills of consensus while his actions appear to me to become more furtive, underhanded and actually destructive to valid OSM data, curated by many people here who "do it right," except for him.

As I quite deliberately don't use social media, addressing me as @stevea seems odd. You are welcome to call me Steve, refer to me as user:stevea, and in our wiki I am Stevea.

Thanks for your concern, but I am one step away from Reporting this person (his first name is Tanner, or so he tells me), something I have never done in nearly a decade of OSM volunteering. (As I really do my very best to be civil, and I am and have been civil, though my patience does wear thin after so many attempts).

If this is too shrill for a Discusson Comment, please missive me at user:stevea and I'll answer any questions you may have there. Again, thanks.

What are you DOING?! A route=railway is NOT a single set of rail infrastructure which must be contiguous! It can be multiple tracks which are not, and if such railways ARE what makes up a Subdivision, then THOSE railway=rail segments are what must be in the route=railway relation, even if they are not contiguous!

Can you point to any documentation, discussion or established convention which allows or encourages you to do this? No? I didn't think so. So, the only conclusion that may be drawn (as you use a THIRD user account to obfuscate your actions), is that you have a "pet project" you are trying to complete "behind the scenes," using OSM as your private rail data repository. That is not OK.

Stop breaking apart perfectly valid route=railway for a pet project of "contiguous" rail subdivisions multiplying like rabbits all over the USA! It is vandalism, pure and simple.

These are now being aggressively repaired to their "complete" route=railway relations, rather than your total preference of "pieces of these which are wholly contiguous." It's wrong!

I have asked you politely (and more than once) to explain why you insist on creating route=railway relations which seem they must be contiguous (even as the actual data, as multiple parallel elements, are not). You do not answer. Moreover, you obfuscate your identity by creating multiple OSM accounts (ethylisocyanate and US Woods, at least) apparently for the express purpose of making your activities more furtive.

Years ago, we established that route=tracks relations were not used in North American rail, this has been talked about in our wikis, talk-us and Discussion pages and between us personally.

Yet you insist upon creating abominations like Ottumwa Route Master (relation/8821512), a super-relation tagged route=railway made up of relations tagged route=tracks. This is a form of vandalism, not documented anywhere as it destroys valid route=railway data. (Ottumwa Subdivision 1, there is no such "1" relation/2222667 was chopped up, Ottumwa Subdivision 2, there is no such "2" relation/8821510 was created, and the route=railway tags were changed to route=tracks). Please stop doing this.

We well- and fully document how we create route=railway out of rail elements in the USA out of TIGER-originated data. ORM documents this as well, the only difference being that we do not (or only exceedingly rarely, and isolated to a single island) use route=tracks relations in all of North America. You fail to follow these tagging conventions, simply making up new rules to tag rail. This is unacceptable.

Creating this super-relation tagged route=railway made up of relations tagged route=tracks as you have is simply wrong. Please restore these data to well-documented route=railway data structures that are widely used and understood in the USA/North America as we document them in our wikis.

Or I and others will. Thank you.

The relation/7193738 is incorrect. A local bicycle route is a SINGLE route, not "all bicycle infrastructure elements in a local area aggregated together." For example, look north a few miles, at the corner of West Magnolia Avenue and 6th Avenue, there are two correct local bicycle route relations (8411679 and 8411680).

These are much more reasonable, they are linear, and are only a kilometer to a few km in length.

The way you correct this is to "break out" from this gigantic relation containing 269 elements each linear route into a single relation that represents a single, numbered route. Also, put the route number, if signed or if from a local authority map, like a "County Bike Map" with route numbers, into the ref tag.

Please see those other relations as better examples, and/or osm.wiki/United_States/Bicycle_Networks . Thank you.

SteveA

Nobody is vandalizing relations. Relations which are superfluous (but which supplant existing relations which are correct) SHOULD be deleted, as their data can be found in other, proper relations. And if those relations are not proper, they should be corrected so they ARE proper, rather than having a wholly redundant (but incomplete) relation created in their stead.

OK, you asked help for the names, I've deleted "Dallas Sub" as erroneous and superfluous, superseded (as it was original) with a more correct Dallas Subdivision (from which I removed your FIXME comment "sort out tracks in Fort Worth," because I did).

This work is ongoing and will continue to improve.

Terribly sorry, that was a JOSM error on my part. After 13,000+ edits, I'm likely to make a mistake here or there, but I don't think I make many. Thank you very much for noticing this and bringing it to my attention! I have fixed the error by deleting the erroneous tags.

Happy mapping, Steve

Hello. It was about six months ago I was working on "consolidating multiple sources" of map data (maybe Strava heat map, maybe others' GPS tracks, maybe others...) and so I can't remember exactly. I do remember thinking that 579705809 seemed like "the best compromise for my estimate of the combined data." In other words, a "best fit" from multiple sources.

It may very well be that 579705809 does not exist, and as you seem to have better "boots on the ground" way out there, feel free to delete it. The last time I was there (near Fern Gulch) was at least ten years ago and your data seem newer and better.

Regarding 475700792, once again, feel free to adjust it to either your original data, or better (newer) data. If it doesn't connect to Hihn SS Road, then it doesn't, and so, of course, shouldn't connect in OSM.

Thanks for the discussion!

Steve

Sorry, weird reboot caused this to be sent twice.

OK, what I've done is to make the "missing 15 km" as "part of the KC Terminal RR is now added to the eastern end of the Emporia Sub." An "official" (bts.gov) map says that Emporia ends just after crossing into Missouri from Kansas. But the west end of Marceline Sub ends at Congo Jct. How to connect Southern Transcon so it goes west from Congo Jct. to Emporia? I have chosen to add what "official" maps call "Main Tracks" (they appear to be KCT) onto the eastern end of Emporia, east to Congo Jct. where it joins the Marceline Sub.

If that is wholly wrong, please correct things, but rail is seriously complex around here.

OK, what I've done is to make the "missing 15 km" as "part of the KC Terminal RR is now added to the eastern end of the Emporia Sub." An "official" (bts.gov) map says that Emporia ends just after crossing into Missouri from Kansas. But the west end of Marceline Sub ends at Congo Jct. How to connect Southern Transcon so it goes west from Congo Jct. to Emporia? I have chosen to add what "official" maps call "Main Tracks" (they appear to be KCT) onto the eastern end of Emporia, east to Congo Jct. where it joins the Marceline Sub.

If that is wholly wrong, please correct things, but rail is seriously complex around here.

I endeavored to correct the Marceline, Kansas City District and operator tags between W.B. Jct. and C.A. Jct. However, the 15 km of Southern Transcon is still "missing." Doing my best! KitonZenobia, can you take a look and see if it is getting better or can you help?

No problem; take your time, and let's take it to the Talk page rather than here, as it is the "more public/wider community" forum that encourages more people to see the discussion and participate if they want to do so.

As suggested, this discussion is "moved" to osm.wiki/Talk:Santa_Cruz_County,_California so that we may better engage a wider OSM community.

Gleb, there are two imports we are talking about here. One was OSM-US' TIGER import of roads and rail in 2007-8, which many agree was of poor quality, but we are more-or-less "stuck" with it, and the solution is to improve it with better-and-better developing strategies. Some people estimate it might take thirty years to clean up TIGER in the USA. OK, maybe it will.

The other import was the SCCGIS landuse import that nmixter (a friend of mine who I and many others have reviled and even ridiculed at his poor and wide-ranging imports all over California). If you read our County wiki page, you'll see HE "made the mess of the initial import" and I am the one (with some others) who has spent many years, thousands of edits and countless hours improving these data to a state of "decency." (You have every right to disagree with that word). I have also said that when the present v3 discovers that SCCGIS offers newer data (2020? 2021?) and might become v4, I endeavor to enter the data with shared multipolygon boundaries where/as it makes sense to do so. This is highly ambitious, shows my continuing dedication to improving the map in ways that it naturally evolves, keeps me and others engaged in how best to improve our County data and opens the gigantic discussion of the difficulties about how best to conflate.

When you say "the exported data are of very bad quality" I don't know if you are talking about TIGER, SCCGIS or both. I think "both." I agree that TIGER's rural roads in the mountains are atrocious, closer to "an hallucination" rather than reality. Please, as you know better reality, fix these. I believe you are doing fine so far; I and the map greatly appreciate your good, solid work.

I, too, would like others to join this discussion. I, too, would like OSM to become "the best damn map in the world." I was NOT the person who imported TIGER, nor did I import the SCCGIS data, rather, I painstakingly improved the SCCGIS data from the hideous mess that arose from nmixter's "trigger happy import finger" as best I could, and this untangling took years of my best efforts. People like you who seem "closer to the action" (you live here, too, as you say) DO improve the map, and rightly so; I am very glad of that. It isn't that you and/or others are being asked to be "hands off" the imported data, I and others WANT you and others to improve the imported data, and you are. (You complain about it, I hear you loud and clear). What we asked you to be "hands off" about was the "reltoolbox" automation of polygon edge conflation that you were doing, which made bad data that were getting better MUCH more confusing, especially for novice editors (and we need all the new mappers we can get).

I agree with you that decades-old data like TIGER and SCCGIS imports were an early "first draft" to get SOME data into the map so it wasn't such a blank canvas. We are beyond doing such things today in areas as richly data-populated as our County (though I'd honestly call it "medium data populated" rather than "richly"). There are no new imports proposed — except the possible improvements a v4 SCCGIS landuse import MIGHT offer; we haven't had that discussion yet as newer data won't be available for a couple/few years. Simultaneously, we can and should improve these data, with, yes, I agree with you 100%, "truth on the ground" approach. Even our wiki says that the landuse import (again, not my idea, not my doing, though my passion to clean up, yes) was "a first step to getting some landuse data into the map" and that more details and better data would follow. That is exactly what you are doing, and correctly so.

Regarding "A wood where in reality there is a meadow - multiple examples. Vice versa - multiple examples." Here is my (partial) answer: there continues to be misunderstanding/debate about landuse vs. landcover. The SCCGIS data did tag as landuse=forest areas which were imported as TP (Timber Production, that is clearly "forest" as OSM means it). Sometimes, a clearing (meadow) could be seen upon this land (trees were felled in a timber forest, nothing strange about that) and so we would superimpose a landuse=meadow on top of that. Amazingly, mapnik/Standard (now Carto) rendered that quite pleasingly. Likewise, many areas which the County zones (remember, zoning is only a "first step" at accurate landuse mapping, and landcover is not landuse) as "farmland" may largely be covered with trees. Many of these areas are orchards, vineyards or simply "still trees" but the land COULD be used for agricultural cultivation, which technically makes the "landuse=farmland" 100% accurate, even as a visual/aerial/satellite/on-the-ground observation might say "hey, there's nothing but TREES here, why is this tagged FARMland?!" Because that's what its landuse actually is, that's why. Let's not (between simply the two of us) debate landuse vs. landcover, we are not going to solve it without the help of the much larger OSM community.

I suggest we take this to the Discussion page of Santa Cruz County's wiki: osm.wiki/Talk:Santa_Cruz_County,_California . That page hasn't been touched in 8-1/2 years and it is time to take it there so it is more public than in a Changeset Comment like here.

Honestly, I believe our goals are much more inline with each other than they are at odds with each other. We have some "chunks of junk" that need improvement/clean-up (just like TIGER, but simultaneously with much grumbling/complaining but also some good strategies — and we are cleaning that up, too). You are doing good work at cleaning up the imported data around here (both TIGER roads and SCCGIS landuse polygons). Yes, it is slow going, it will take years. (It took me about five years to clean up Nathan/nmixter's SCCGIS v1 data through v2 cleanup and v3 re-import). The map is a big place, the world is a big place. Our county is a finite amount of data in OSM. It is a substantial amount of data, but it isn't so large that a project like ours, with cooperation and consensus among its participants (like us) can't get it done — we CAN get it done and we ARE getting it done.

Best regards,
Steve

Gleb, I'm disappointed that after all of our good communication you continue to characterize the three versions of imported SCCGIS data which were carefully-curated over several years as "exported polygon mess."

We agree they are not "perfect," as very few things in OSM are. We agree they are (maybe about 98% or 99%) correct, as polygons and multipolygons are perfectly valid OSM data structures, and the data provided by the County are/were perfectly valid based on cadestral/parcel data. We agree that you "prefer" to use your JOSM tool reltoolbox to assist you in conflating edges, and Frederik Ramm, mailing lists and I agree that "to take perfectly valid data and convert it to another format as this tool does" is essentially a senseless waste of time.

I understand that "you live here" (and for many decades, I have lived here, too) and want to see data improve in our County. However, it remains true that there ARE existing data surrounding us in OSM. If/as/when data are "just plain wrong," of course, I encourage you to correct them. But to disparage the existing, correct data with mean comments like "mess" is not in the spirit of OSM.

Thank you for your improvements.

You are absolutely right. I have changed it to a much-more accurate ele=419 value. Thank you for catching my error!

Steve