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.

Looks like you cracked open (disconnected) a (rather admittedly complex, I will concur) landuse=conservation multipolygon while editing around Camp Ben Lomond and Empire Grade a couple of weeks ago. As one of the original authors of this, I have fixed it.

Yes, as Nakaner (and ORM tagging) document, ORM truly IS unable to "make the link between" (render) the relation, UNLESS the track is so tagged.

AGAIN, (I repeat) AS IT IS DOCUMENTED, the "highspeed=yes" tag literally means: "Is this line a high-speed line?" Emphasis on the LINE to which that track segment belongs.

An analogous situation we seem to be touching upon (with our motorway example having a maxspeed=65 mph tag) would be if an Interstate highway had segments within it which were not quite up to Interstate highway standards. For example, perhaps a few km were highway=trunk instead of highway=motorway. In that case, AASHTO would not grant full Interstate status to that highway (or specifically exclude that segment, as is I-210 and CA-210 in southern California). But the difference is that Amtrak regarding conferring "high speed status" is not as strict as AASHTO is at conferring "Interstate status." In the latter case, the higher-class tag should not be applied, as the official designation has not been granted. But in the former case (Amtrak saying Acela on NEC is high-speed), the official designation HAS been granted. Ipso facto, the tracks can be (and should be) tagged with highspeed=yes, as each track segment meets the documented definition: "Is this line a high-speed line?"

The route (Acela Express, route=train) already is marked high speed, with the service=high_speed tag. This is precisely how ORM tagging instructions say it should be done. The tag is not applied (again, exactly as instructed) to the route=railway (NEC) relation. This is because ORM's tagging sections of Railway Route and Train Route do not document to put a high_speed tag on the former, but to one should put a high_speed tag on the latter. So, that has been true for some time.

I hear you when you say you object to each element of track being labelled highspeed=yes. Again, the world over already does this on several (dozens?) of high speed train rail infrastructure segments to indicate that these segments are part of a high-speed line. I am merely following their lead. Do you object to those as well?

As 1) this is already done the world over, 2) the author of the primary renderer for this tag says (effectively) "no clear consensus yet" and 3) Tagging_for_the_renderer wiki's Clarification section supports me, my determination to leave these tags in place seems OK.

Finally, a road (highway) with a maxspeed tag (let's say it is 65 mph, because of posted signs that say so) doesn't mean that cars will always travel over it at 65 mph. They might travel over it at 75 mph (and violate the Vehicle Code) or they might travel over it at 5 mph in heavy traffic (as was the point of my earlier effort to point this out). However, the maxspeed tag of 65 mph remains correct on that road, doesn't it? Yes, it does.

And there you have it from one of the authors (and a true rail expert from an OSM tagging perspective): "there has not been reached any consensus." What this says to me is that we have a bit of a tempest in a teapot here. Especially as other lines (in Europe, Asia) are tagged as I have tagged NEC (highspeed=yes along the length of the infrastructure), signifying that track segment is part of a high speed line.

To show my continuing good faith and hopefully to assuage the situation somewhat, I have applied a few maxspeed= tags on those sections of NEC track where its Wikipedia article (footnote 64) allows me to determine these. These are displayed using ORM's Maxspeed style (radio button). They begin to yield a more comprehensive OSM visualization of the changing speeds that Serge experienced while riding the Acela. These are early data, but they are all I am easily able to determine now, and I encourage more maxspeed= tagging where it is known.

To Paul's comment: Amtrak's "upgrades" are intended to make an already-exists high speed line into an EVEN HIGHER speed line.

To Frederick's comments: a "more correct" way to capture that certain segments of rail have a limiting speed is with a maxspeed tag. I welcome these, as then ORM's Maxspeed style would show what Serge both wants to see and experienced on the train in person.

I am in email contact (today, actually) with Michael Reichert (one of the authors of ORM) awaiting answers to several questions, among them whether tagging a route=train with highspeed=yes will render. If it will, I will happily change tagging to do that, removing them from the infrastructure. However, it may be that because of CSS limitations on relation rendering, it will not work. I may also experiment with this without waiting for an answer from Michael.

If this (tagging the route=train relation) does not work, I stand by what "Tagging_for_the_renderer" states: "If a specialist map renders a particular specialist tag...then using the tags the renderer understands is a perfectly reasonable thing to do."

Frederick, as I look at high speed rail in UK, it is as I suspect: the highspeed=yes tag is on the rail element, not the relation. However, there is a "service=highspeed" tag which may render in ORM (though I doubt it). I can experiment with this service=highspeed tag on the Acela route=train as well. But if it doesn't work, nor if putting highspeed=yes on the route=train relation works, then I really must do what the whole rest of the world does in OSM to tag high speed rail that renders in ORM: tag each element of the railway to which it belongs (NEC in this case for Acela) as highspeed=yes. Just as ORM documents, just as other highspeed lines in the world are tagged.

Serge, individual tracks are tagged this way because that is how the tag is documented: it means the LINE of which this rail segment is a member is capable of supporting high speed route=train service. So, it is correct. (I repeat myself here, not a good sign).

Are there individual track segments which do not always see a particular train (even an Acela), traveling at high speed? You say yes. However, that does NOT contradict that the tag is being used properly as it is documented, which it is: as a MEMBER of a LINE which SUPPORTS high speed route=train service. There are numerous examples of these in OSM. But only one in the USA: this one. And it is tagged as are other high-speed rail lines, because IT IS ONE.

If you wish to see "more accurate" tagging on this rail line, please enter maxspeed= values where you know them. I greatly encourage that task.