Hey, come on, it's just a stub of the old Anaheim to Santa Ana branch from the 1870s-1880s. A lot of the rest has been "subsumed" by I-5 and I'm trying to get California rail to be more complete. You're kidding, right?! (Choo!)

I do respect OSM, and am a respected OSM bicycle mapper since 2009, even speaking about national bicycle routing in the USA at SOTM-US in 2014 (see http://vimeo.com/91897324) AND I extensively consulted with Richard Fairhurst on his cycle.travel router, for which he publicly and profusely thanked me. The mail you refer to is in answer to me (you are welcome to check). But this is not a measuring contest, is it?

Please see our wikis on United States/Bicycle Networks and WikiProject U.S. Bicycle Route System for the vast amount of work we do on bicycle routes here in the USA to achieve good OSM harmony.

I would be happy to see deleted on GDMBR the network=icn tag, agreeing with your assertion that this is a route=mtb. It seems like "both" but only because it is international. But seeing as network=icn captures the international semantic AND ALSO (incorrectly) implies a paved route, network=icn can and should be deleted, imo.

Let's end this by tagging GDMBR route=mtb and NOT tagged network=icn or network=ncn. Considering the cycle_network=ACA (and I am familiar with many staff and officers of Adventure Cycling Association, the USA's premier national biking organization), this route could/should even be properly deleted from OSM altogether, as since ACA routes are copyrighted, entering them violates ODBL.

You are NOT "fixing" this route by changing its tags from network=icn to network=ncn. This is under no circumstances a network=ncn route. It is an international mountain bike route and that is NOT an ncn by any definition. If you are making this change so that you can see the route render in a particular renderer, you are misusing OSM.

Please read our wiki(s), please follow the rules.

About your comment "changed tags for proper rendering." This is just plain wrong, and is blatant "coding for the renderer." We have been down this road before, and many times. I tire of this edit war, and it must stop.

We need to establish a truce with GDMBR. GDMBR is NOT an ncn, as it crosses an international boundary. I have changed it to icn because it does, and this was even agreed to by a current or former member of OSM's Data Working Group (for lack of a better analogy, we can think of the DWG as OSM's "data police").

I also saw that you cloned (duplicated) the relation and tagged it route=mtb, which I believe and hereby assert is the ultimately correct solution. I have also heard from others (more international OSM volunteers outside of the USA) that they find the solution of calling ANY mountain bike route either an ncn or an icn as completely wrong: that is not done anywhere else in the world, and so we should not do it here in the USA (and/or Canada).

So, I propose we delete relation/3161159 (GDMBR tagged with network=ncn) and we keep relation/6073693 (GDMBR tagged with route=mtb).

I will not tolerate a GDMBR relation with either network=icn or especially network=ncn simply because you find it convenient that it renderers where-ever you like to see it rendered. That is not how OSM works.

About your comment "changed tags for proper rendering." This is just plain wrong, and is blatant "coding for the renderer." We have been down this road before, and many times. I tire of this edit war, and it must stop.

We need to establish a truce with GDMBR. GDMBR is NOT an ncn, as it crosses an international boundary. I have changed it to icn because it does, and this was even agreed to by a current or former member of OSM's Data Working Group (for lack of a better analogy, we can think of the DWG as OSM's "data police").

I also saw that you cloned (duplicated) the relation and tagged it route=mtb, which I believe and hereby assert is the ultimately correct solution. I have also heard from others (more international OSM volunteers outside of the USA) that they find the solution of calling ANY mountain bike route either an ncn or an icn as completely wrong: that is not done anywhere else in the world, and so we should not do it here in the USA (and/or Canada).

So, I propose we delete relation/3161159 (GDMBR tagged with network=ncn) and we keep relation/6073693 (GDMBR tagged with route=mtb).

I will not tolerate a GDMBR relation with either network=icn or especially network=ncn simply because you find it convenient that it renderers where-ever you like to see it rendered. That is not how OSM works.

Very nice work. The map appreciates your efforts here!

Please read the wiki I suggest. There is a long history (not OSM history, actual real-life history) that is highly relevant here. I spoke on these topics at SOTM-US in 2014 and am in frequent contact with Kerry Irons and upper management of ACA on a weekly basis. If you refer to Cycle Map layer as not rendering, it is Andy Allan who is responsible, he and I are also in frequent communication. Leave this icn, please. I can ask Andy to render icn if you want to see it, but no guarantees he will do so.

You need to read our wiki pages at osm.wiki/United_States/Bicycle_Networks . There, you will see that this IS an icn as well as understand how the historical context of why it was rcn AND how ACA routes shouldn't even be in OSM. Don't tag for the renderer, and this DOES render at waymarkedtrails.

And how is it you have permission to enter these data? ACA routes are copyrighted and unless you have specific permission to enter these into OSM (I strongly suspect you don't), they are a violation of OSM's Contributor Terms and our ODBL.

Max, I don't know how I can help. It might have been g246020 who did this, and much less likely, it might have been me. I am seriously busy on other tasks this week. Perhaps I could take a look at the relation and tracks this weekend (January 9-10, 2016). I'll try to leave another comment here, but I don't believe I have much more to offer here, except for perhaps deleting duplicate tracks. The thing is, I'm not sure which ones are "more correct," so it seems better of me to simply not edit this area at all (any further).

g246020?

To which someone do you refer?

It seems to be an accident. I welcome any corrections you or anybody else more familiar than I am with the Jefferson City Subdivision can offer.

OK, I believe I have changed all bicycle=shoulder tags to cycleway=shoulder.

This was an old-fashioned way of tagging way back when (circa 2009 when the CASIL and Santa Cruz County GIS imports happened). I agree with you (now, 2015) that it is incorrect to put admin_level=4 on a State Park and so I have removed that tag.

Of course, Minh: thank you for your corrections and especially for documenting here the correct way to tag this so I know how to do this if/as I find such construction in the future.

OpenRailwayMap's Infrastructure and Maxspeed styles now render these changes accurately. I consider this resolved.

Not a problem, took me just a couple of minutes. Thanks for your cooperation and good attitude. Go OSM!

In changeset/30077144, I have deprecated the highspeed=yes tags from all NEC segments. However, previous changesets have set maxspeed= tags. As a net result, on segments where maxspeed>=160, highspeed=yes is "back" to being set. These segments include the great majority of the NEC, absent primarily around Newark, New York City and New London and between New Rochelle/New Haven.

It isn't too far a stretch to say NEC is "somewhere between orange and red." Subtle, huh, yeah, I know. As we best know how to tag.