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

A couple simple reminders: owner=* and operator=* tags can show proper rail ownership. An operator tag can show multiple operators, example, operator=BNSF;UP

Also, please don't prefix subdivision names with the operator, this is simply wrong. So the correct name is "Emporia Subdivision" not "BNSF Emporia Subdivision."

OSM's "Southern Transcon" relation (4673773) is correct in that it contains the correct 11 subdivisions. However, OSM data are "broken" in Kansas City between the eastern end of Emporia Subdivision at Santa Fe Junction and Congo Jct. at the west end of Marceline Subdivision. It appears that "Kansas City Terminal RR" (including the "Sheffield Flyover" and "Argentine Connection 2") are part of the missing gap (about 15 km). Rail is quite complicated in Kansas City. Please help fix this!

Great; thanks for the "ferry fix" (es).

I literally just finished a lengthy email to Kerry Irons (ACA) about how the 5-mile "USBR 10 SPUR" (intended to serve as a multi-modal bike/rail connection) was in WSDOT's 2014 USBR 10 AASHTO application (and it was approved, of course), yet that "spur" now seems superfluous with a significant of 2017's USBR 95 essentially superseding it. Kerry says he'll "dig into it" with WSDOT, as it may be as simple as an oversight on their part that they didn't delete the 5 miles of USBR 10 (even route number, so N-S, doesn't make sense) when they now have USBR 95 (odd-numbered, so perfectly sensible as N-S). Trouble is, the alignments don't perfectly match up, so some minor realignments will likely happen inside of WSDOT.

I think we'll get there: Washington state has been a pioneer with the USBRS and they do put erasers on the ends of pencils for very good reason: there is no shame in scrubbing away a little goof and improving things. It might take a year or two, but I think the right wheels are in motion and ears are being whispered into that "Mt. Vernon bicycle routing with USBR 10, USBR 95 and BR 14 at the state/regional level need a bit of tender loving care to make a bit more routing sense."

As always, thanks for the good mapping and good communication.

Minor changes edited.

Bill: Many watch what you do northerly along the coast.

Please make these changes (though by no means is this list exhaustive):

On relation/7530067 there is path 8531834 with wrong tags. Better tags on this object:

cycle:network=US:DOD:MCBC Pendleton
network=lcn

This is not part of the USBRS, though someday it might be, who knows.

On relation/8531834, this also is not part of the USBRS, but it's cycle:network tags make it look that way. I suggest the same tags on this object:

cycle:network=US:DOD:MCBC Pendleton
network=lcn

Please also remove the ref= tag as it is most certainly not USBR 95 (yet, who knows, perhaps parts of it will be, someday...).

So, I think you've done some good work entering interesting bicycle route elements here, let's get their tags correct (as of now). Tomorrow if they get pulled into a larger route, we have the tags to tag for those.

Please see our national bike wikis.

Thanks,
Steve A
California

Not to mention we are pretty long in the tooth (months, not weeks or days) for Andy to update OCM in North America. I've done my usual polite cajoling, it shouldn't be too long before we get some fresh tile updates. If you're reading, Andy, thanks in advance! Have fun exploring, Clifford. -SteveA

Thanks; I had a funky edit buffer with an error. It appears that USBR 10 and USBR 95 were conflated, as if 10 had a N-S spur to/through Mount Vernon, but I don't think it does, that segment is actually 95.

So, now, 10 is "pretty much E-W" (without a N-S Mt. Vernon 'spur') and 95 is "pretty much N-S" as it should be.

It couldn't hurt to verify the relations, though I have and all seems OK. But a second set of eyes is appreciated!

Just all wrong, check what's there, first!

I don't understand what these ways are, I don't understand how they are tagged.

Yes, these ways have no tag which will cause them to render (for example, highway=path, chosen because you include a surface= tag, which is insufficient to render). Please take a look at our wiki and how to tag, as suggested above.

Nice job cleaning up this area!