Talk:OpenRailwayMap/Tagging in North America

Naming of Timetable Locations

NA railroads use named locations to identify points along the route. Such points may not have anything else at the location (though oftent they have a siding). The curren tagging conventions has "route=service_station". But that does not fit most of the timteable locations.

I propose to use route=site, with both name=* and operator=* included. The location should be according to the milepost in the timetable (not at the center of the facility, as generally suggested).

One current caveat is that the search (API) does not include sites (only station, halt and junction). The old search included more types.

c44d9w (talk) 03:33, 23 February 2024 (UTC)

Main Track Naming

I (c44d9w) disagree with the current (Jan 2024) naming convention for main track. Using only the subdivision is confusing when one does not have local knowledge. For example, Ottumwa (Iowa) has a diamond, with both lines labeled "Ottumwa Subdivision". How does one know which is CPKC and which is BNSF?

I Propose the following:

1. For name=*, use the Railway abbreviation (eg. "CPKC") and the subdivision, instead of just the subdivision. For the Ottumwa example, it would be "CPKC Ottumwa Subdivision" and "BNSF Ottumwa Subdivision".

1. Always add tag ref=*, using the railway (eg. "CPCK") as the value. At large scale (zoomed out), the presentation uses the "ref" tag. That way we see the railway at large scale, and when zooming in it changes to the subdivision.

The presentation for track changes as one zooms in.

• zoomed out: tag ref=*.
• zoomed medium: tag name=*; also shows beside the track the name of any (?) route=railway relation.
• zoomed in: tag railway:track_ref=*; also shows beside the track the name of any (?) route=railway relation.

Edit 2024-02-12:

• It appears that the label beside the track is the tag name=*, and not the route relation representing the subdivision.
• It appears that at medium zoom levels tag ref=* is prefixed to tag name=*.

c44d9w (talk) 18:51, 22 January 2024 (UTC)

I was wondering if and when a suggestion like this would happen and here we are. There is a proposal to create a new layer in ORM called "Operators" (I think) which would allow toggles / checkboxes to turn on or off whether reporting_marks=* or operator:short=* are displayed. This is an idealized "solution" (for North American rail tastes), meaning it is likely a good, even a best, solution, but it is in the future and doesn't exist today. However, there is also a convention that USA rail (and it should be North American rail, in reality) uses in exactly these circumstances, where two Subdivisions are both named "Samething Subdivision" but they aren't the same thing, as they are owned and/or operated by a number of operators. In this case, the choice to tag with names as "CPKC Ottumwa Subdivision" and "BNSF Ottumwa Subdivision" is (mostly) correct, as this "disambiguation prefixing" is what our wiki has suggested for many years. However, using the ref=* tag with a value of the operator (e.g. CPCK) isn't correct, as the correct key for this is the operator=* tag (and, if known, owner=*). Your suggestion to "always add the ref tag using the railway as the value" is something I must disagree with, especially as it leans heavily upon ORM choosing to display different values at different zoom levels (name vs. ref). It is much better to use the operator=* tag for OSM to actually denote the operator, and let the renderer(s) "catch up" with better displaying (some might say "properly displaying") what the semantics are that you want to see. Please do recall that North American "tastes" vs. European "tastes" at how rail is displayed is the underlying issue here (ORM is made by people in Germany, for German rail style tagging, which really is different from the way the rest of the world tags rail in OSM), and a "likely more correct" solution is to encourage the development of ORM's Operators layer as the best way forward. Hacking the tags as you describe isn't the best way forward, in my opinion, although "prefixing a Subdivision name with reporting_marks to avoid a local ambiguity" has been a working solution we've documented for years. Is this "disambiguation prefixing" actually "correct"? Well, strictly speaking, no, but it works for now. Stevea (talk) 19:01, 22 January 2024 (UTC)

I agree that making changes to the presentation layer and making the presentation region-aware is the proper solution. I am just not sure when that would actually happen. So I suggested the above work-around. c44d9w (talk) 21:32, 23 January 2024‎ (UTC)

Thanks for agreement! Yeah, let's say "the (ORM) author who answered the phone about the new layer seems busy." While "aware of the issue." Sounds about right to me, actually. So, I wouldn't hold my breath, but I'd also be pleasantly surprised as it happens (in an imaginable future). I believe this layered approach is an excellent way to better or best-for-now resolve these tagging issues: keep geometry, geography, orthography apart from semantics (differences in meaning). So far, so good, as ORM has some nice, smart layering already. name=* on North America railway=rail have been fluid for some time, it can be hard to keep up with the hows behind newer (numerical) name tagging. Stevea (talk) 01:00, 24 January 2024 (UTC)

Signal images

I think the signal images should be vectorized. They are largely made up of lines and circular shapes, so SVG versions of them would make sense. -happy5214 00:25, 29 May 2017 (UTC)

I believe the author is User:YamaOfParadise. You may wish to make contact and suggest this as I'm not sure a Talk entry will get this person's attention. I've tried contact directly (OSM missive) but have yet to receive a response. You might also try to do the vectorizing yourself, as I agree that svg files are better for these sorts of data. Then again, it may be a not-especially-worthwhile endeavor, as the graphics work is already done, yet it isn't in the most appropriate format.

Should Class II rail in the USA be usage=main or usage=branch?

(From this talk-us thread).

I realize that distinctions between railway=rail + usage=* tags is subjective (even as OpenRailwayMap — ORM — renders main orange and branch yellow). Full disclosure: I have tried to sharpen focus in contributing to our ORM Tagging wiki and related wiki re OSM rail tagging. I am in a listening mode as I do so and don't wish to be too aggressive in positing anything too new or too controversial.

I have not done a comprehensive review of how many Class II railroads (a category of regional railroad in the USA which is not usually as "short line" as Class IIIs, but neither is it as large as the mighty Class Is) are tagged usage=main vs. usage=branch. I now toss out as a question in the USA (Overpass Turbo can query) a wider beginning of consensus regarding Class II railroads being tagged usage=main instead of usage=branch. In short, all discussion is welcome: calling all interested parties.

Starting with Central Oregon and Pacific (reporting mark CORP) now tagged usage=branch, might this better be tagged usage=main? Should other USA Class II railroads be tagged usage=main as a matter of course? I'm leaning in that direction, suggesting that CORP and other Class II railroads see usage=* tags become main (if not main, be changed from branch to main).

Comments? This includes soliciting Comments from overseas readers, like in Germany...those who wrote the ORM renderer and "watch" (and at least pay attention) to such things. (The concept of "Class II" railroad might literally be a foreign concept, but I believe European, Chinese, Japanese, Taiwanese, Korean, pan-Asian, African, Australian, South American...all worldwide OSM rail mapping watchers can understand Class II in the context of "USA Rail"): these are "medium/regional-sized" railroads, measured economically by revenue as "between large interstate carriers and short line/more-local carriers."

If you are a rail fan / rail buff or otherwise find OSM rail-useful, please consider chiming in here and now as a way to better establish a modicum of sub-community (OSM-US rail interest). I have heard from many over the years and consider hearing from others a polite nod in this direction. I also welcome all others and all "new comers" (from my limited perspective) — those with whom I have no idea you are "out there." Thank you. Stevea (talk) 16:22, 16 June 2018 (UTC)

Is the CORP a Class II railroad? The list on Wikipedia is a complete mess, and I couldn't find a list of Class II and III railroads on the STB website. When I found a local news source for the CORP line reopening, the article said the CORP was a Class III railroad. In either case, I don't believe it currently has the traffic needed to warrant usage=main. There are some Class II railroads whose mainlines should be tagged as such, like Alaska, Iowa Interstate, Long Island, and Florida East Coast. I think the tagging of Class II railroad mainlines should be done on a case-by-case basis. -happy5214 01:14, 17 June 2018 (UTC)

Nice to hear from you, old friend! I don't recall exactly from where I determined that CORP is Class II, though I do recall at least two different sources that said this. Yet I've also seen some California (Department of Transportation) documentation that calls it Class III. However, I agree with you on all points: that traffic likely doesn't warrant usage=main on CORP, that the Class II's you list are "significantly major rail" that DOES warrant usage=main and that these decisions should be made on a case-by-case basis. Thanks for your input here, especially as others might find this talking point and act accordingly in the future. Stevea (talk) 17:03, 17 June 2018 (UTC)

Wikipedia shows CORP as Class II, citing an STB decision from 2007. I no longer consider that reliable due to age. -happy5214 21:09, 17 June 2018 (UTC)

I did a little bit of cleanup and fleshing-out of the Class I, Class II, and Regional reference lists while I was in here, to help support our naming discussion yesterday. While I'm at it, I wanted to weigh in with my opinion on main vs. branch as it relates to Class, and see if it helps - maybe it'll give us another place we can clarify.

To me, the usage=* tag relates to the function of the route in relation to its surroundings, not directly to the operator. Here's my understanding:

A usage=main track serves a primary purpose as a long-haul through route; they almost all certainly also have industries and customers, but serving those industries and customers is secondary to the through traffic. A good example would be the CSXT James River subdivision, where I grew up and can give clear examples (from 20 years ago, admittedly). Through traffic per day was anywhere from 6-12 coal trains in each direction, one manifest freight in each direction. The manifest freights would stop at Lynchburg to drop off cuts for all local customers. There were two local crew shifts per day; the morning crew would put together a westbound local from the yard, and run out and back to serve all industries between Lynchburg and Natural Bridge. The evening shift then took over the locomotive, and assembled and operated an eastbound local to Gladstone and back. Hence, local customers, but they were clearly secondary to the through traffic.

A usage=branch route is usually (but not always) still longer, at least long enough to serve more than one town, but has little through traffic. Here, almost all traffic is generated by or destined for industries on the branch; in some cases, this may even be full unit trains of grain or coal, as the branch might have some pretty big customers. A key to the definition here for me is that the branch does have more than one individual customer. A branch might technically be a through route, but through traffic would be an exception or at least moderately uncommon (perhaps as a relief when a parallel main is overloaded, or a reroute around an accident), and a through branch often doesn't make a good modern mainline (even if it started as one originally) due to less favorable grades, speeds, or track condition. A good example here I can give would be Buckingham Branch in Virginia, which operates four discontiguous lines, two former CSXT, one former NS, and one former NS nee PRR. Two good example cases are, they run the Richmond & Alleghany division, which is the original C&O mainline between Richmond and Clifton Forge and is a through route (this is the route that the James River sub replaced); this was still an alternate route for CSXT before they leased it to BB in 2004, but has much less favorable grades than the current CSXT mainline. I believe CSXT still holds trackage rights if they have an emergency, but I don't believe they're running any through traffic. For the Buckingham division, that's an ex-C&O dead end branch (17 miles long) that serves a mix of forestry, mining, and agricultural businesses, mostly.

A usage=industrial route has in common with a branch that its primary traffic is locally generated, with little through traffic. However, it is smaller in scope, either serving only one locality, port, or industrial complex, or if it stretches between localities, only really serving one industry (such as a long mine lead for a single, large mine). To me, for inter-locality industrial lines, having a single customer is key - if it serves multiple customers, it's really more of a branch line.

Does that make enough sense to help contribute to the discussion? I really feel like the definitions in the NA wiki aren't very clear, so if we get some sort of consensus together, I'd be happy to help rearrange, clean up, and provide examples. Chuck (talk) 15:31, 4 June 2020 (UTC)

Based on my above text, I'm working up a proposal for clarification to send to the talk-us list for discussion and hopefully consensus. There's a lot of room for clarification on the NA wiki page here. Chuck (talk) 21:04, 4 June 2020 (UTC)

What an awesome and well-thought out and well-crafted response to years of main/branch/industrial "development" (or lack thereof / slow progress).

The vagueness of main/branch/industrial have always been. Few have dared to better flesh them out. I contributed by noting that industrial often got tagged on urban industrial-zoned customers (aircraft parts near an airport, light- to medium-industry that really ought to be served by rail...). Really, [main, branch, industrial] most vividly display with ORM, as orange, yellow and brown, respectively, but at different zoom levels.

There is so much I could say. We might discuss what goes on (both rail traffic and OSM tagging) around Dakota Jct. (near RCPE Black Hills Subdivision and Chadron Subdivision near the Nebrask / South Dakota / Wyoming border). To me, usage tagging will always be a little semantically fuzzy, but you make outstanding efforts at clarification here. I wish to get out of your way! Stevea (talk) 02:36, 5 June 2020 (UTC)

I went ahead and created a draft copy of the replacement section on my user page: User:Nathhad/TaggingNADraft. If we don't get any substantial feedback to change it, once I have it "done" I'll copy it straight into the real page as a 1:1 replacement. I'm working now to add a column for examples. Chuck (talk) 17:52, 5 June 2020 (UTC)

@Stevea I incorporated your input from the draft page, and haven't received any input or interest from anyone else ... so the new Route Importance section is live, along with the new examples page! Thanks for your help and support. I still want to flesh out the examples page, but it seemed built out enough to start using it ... and it's supposed to be pretty outdoors here tomorrow, so better to get it out there! Chuck (talk) 02:23, 7 June 2020 (UTC)

RCPE/DME

It's an interesting question if anybody is paying attention: what about the "mainline" (yes, these things can be subjective, hence this discussion) of Rapid City, Pierre & Eastern Railroad (RCPE), one of GNWR's four Class II railroads? (BTW, CORP is another). Its "mainline" goes from Tracy, Minnesota (where it interchanges with CP) to Huron, South Dakota (on RCPE's Huron Subdivision), then further west (on RCPE's Pierre Subdivision) to Pierre, South Dakota, then further west (on RCPE's PRC Subdivision) to Rapid City, South Dakota. Sure, RCPE has a couple/few additional minor spurs, but this certainly is its "mainline," something like 450 miles of solid east-to-west railroad. It "dead ends" northwesterly, forking from Rapid City northerly to Colony, Wyoming on RCPE's Black Hills Subdivision, though continues from Rapid City southerly (again on RCPE's Black Hills Sub) to Dakota Jct/Chadron, then Crawford, Nebraska (on RCPE's Crawford Subdivision, tagged usage=branch), where it interchanges with BNSF on Butte Subdivision, FINALLY connecting with agreed-upon "mainline" (tagged usage=main).

Take a look with ORM at South Dakota: it is a virtual desert of mainline rail, except for 61 miles in the nether SW and SE corners of the state. Again: RCPE is Class II and the three subdivisions stitched together on the same railroad in the previous paragraph (Huron, Pierre, RPC) are a fairly direct east-west route for 450 miles. Should these three subdivisions be changed from usage=branch to usage=main? I have read from happy that "the amount of traffic" is another helpful datum by which to judge whether a "line" is "main" vs. "branch" but I have no idea how much traffic is here. Still, for sheer connectivity (Tracy, Minnesota through all the width of South Dakota to BNSF mainline in Nebraska), as well as serious length, this seems like it may very well be mainline rail. On the other hand, much of it appears single tracked and it serves only freight; no Amtrak (and virtually no passenger service at all in South Dakota, except a couple of short heritage lines). Stevea (talk) 11:20, 7 October 2018 (UTC)

The RCPE was formed as a spin-off from the Dakota, Minnesota and Eastern Railroad (DME), which is a subsidiary of CP ultimately derived from former Chicago and North Western trackage.

Passenger service is irrelevant IMO. There are many undeniable mainlines that don't currently have Amtrak or other passenger service.

When I assess the connectivity arguments, I ask if the line ends at other usage=main lines (the combined RCPE/DME line does in Winona, and arguably at Crawford, NE, at a BNSF line), if the corridor is "significant" (I'd say this is), and if a busier line serves the same corridor (I don't see such a busier parallel line here; this is a huge knock for CORP). Since I can answer "yes" to the first two questions and "no" to the third, this satisfies the connectivity test.

According to a citation from Trains on the RCPE Wikipedia article, RCPE transported 64k carloads annually as of 2015. By comparison, this is almost 4 times more than the CORP, while the Iowa Interstate transported "over 100,000" in 2015. Traffic-wise, this is probably borderline.

Overall, I would advise to re-tag the line from Winona, MN, to Rapid City as usage=main, with an option to continue that tag along the Crawford Subdivision to the BNSF Butte Subdivision. -happy5214 12:12, 7 October 2018 (UTC)

Interesting. I can "get" (both "understand" and "go easterly from Tracy") to Mankato, Minnesota as this is where the RCPE has its easternmost interchange with UP. You're saying those segments, PLUS even further eastwards (via Dakota Minnesota & Eastern) to Winona all upgrade from branch to main? OK, that makes sense to me. Back on the westerly edge of South Dakota, what about that southerly segment of RCPE's Black Hills Subdivision, south of Rapid City? If that were mainline instead of branch, we go from the western edge of Wisconsin (just about) to the western edge of Nebraska. Yeah, the Crawford seems better left as branch, at least for now. Seems like a straight-line mainline shot west-to-east (or east-to-west) right through the middle of the lower 48. Thanks for your quick reply! I'll get around to tagging in the next few hours. Stevea (talk) 12:44, 7 October 2018 (UTC)

Now updated in OSM and at South_Dakota/Railroads. Thanks for the research, tips, pointers and encouragement, Alexander! Stevea (talk) 14:29, 7 October 2018 (UTC)

Railway (operator) naming, US specific

I see a lot of operator tags in my region of the us that give the operator name as initials, when I know for a fact the proper name of the railroad is still spelled out (e.g. NS for Norfolk Southern Railway). I'm under the impression from everywhere else in the wiki that this isn't the intent, but wanted to verify before I start mass renaming operators in my region!

In parallel, I see no tag that would hold the equivalent short name (reporting marks) for a US operator. Would there be any value to a tag like this for the US where mappers want to generate a map that does show by reporting marks instead of proper name, or is this something we'd rather leave up to map makers using this source data to translate using a table in their custom map? Asked by Chuck (talk) 12:05, 2 June 2020 (UTC)

Good questions! I myself have been guilty of taking the shortcut of adding operator=UP when I knew in my heart that it would be much better and more-correct to tag operator=Union Pacific. To be clear, "full name" operator tagging is very much preferred, similar to how OSM prefers "Saint Louis" to "St. Louis." In a small number of cases (sorry, I can't quote specific examples, I'm going by eleven years of memory of rail tagging) I have used the totally coined-by-me tag reporting_marks=* with the two-, three- or four-character value corresponding to the railroad's reporting marks. After I just checked taginfo, it looks like somebody (in Texas?) used reporting_mark=* (no s on the end) to tag (mostly) over 150 examples of "TXPF" (there are a few other values). I would say that the tag reporting_marks=* is "more correct" (as rail advocates use it and mean it in the USA) and that should be the preferred tag we use going forward. Yes, I find value in doing this, I strongly suspect others do, too.

So, these two things: let's strive to enter the FULL name in the operator=* tag, and let's strive to use reporting_marks=*, not reporting_mark=*. Regarding "mass renaming," like any "bot-oriented" OSM practice, only do so if you REALLY know what you are doing! (OSM is OK with powerful tools used skillfully, but not powerful tools used, um, sloppily). Thank you for good questions and dialog here! Stevea (talk) 16:23, 3 June 2020 (UTC)

That all makes a ton of sense to me. This being fairly US-specific, is there anywhere else the reporting marks question should be brought up before considering adding that tag to the page here? Chuck (talk) 01:04, 4 June 2020 (UTC)

It may be true that there are "reporting marks" (as we know them in the USA) also in Canada, but I'm not sure. However, I thought I'd mention that possibility as this is a "North America" wiki. Please, I encourage you to add this "to the page here," I'd be delighted as you do so! (Thank you!) I would say that posting to talk-us is a good place to "further" discuss this, with a link back here so we can follow the full thread of dialog. Stevea (talk) 01:56, 4 June 2020 (UTC)

That should actually work out great - the US, Canada, and Mexico share the AAR reporting mark system as a common system, since the three of us interchange so heavily. I'll definitely follow up on your suggestion to post this question on talk-us come morning, as soon as I'm off mobile. Thanks! Chuck (talk) 02:14, 4 June 2020 (UTC)

And thank you for teaching me that reporting_marks are all-three-countries. Great to be mapping with you. Stevea (talk) 02:16, 4 June 2020 (UTC)

Oh, it couldn't hurt to cross-post to talk-ca (Canada), which I am a member of (not many USA mappers are members of both, I happen to be). I don't know about Mexico or whether it has a talk maillist. Stevea (talk) 02:24, 4 June 2020 (UTC)

As I'm both a subscriber to talk-ca, as well as a nice guy (among other things), I just posted this to talk-ca. Stevea (talk) 02:32, 4 June 2020 (UTC)

Thanks! I like your wording so much I'm going to shamelessly swipe a little of it - getting a quick talk-us post together now. Chuck (talk) 12:19, 4 June 2020 (UTC)

You are welcome to swipe away. Stevea (talk) 16:03, 4 June 2020 (UTC)

Volker Schmidt on the Talk-US list made what I think is an excellent suggestion, that we use a less region-specific tag name like "operator_designation" that might be applicable to other parts of the world. I think that works equally well for us. Since that could be worldwide, I went ahead and forwarded to the OpenRailwayMap list for input, to see if anyone has any better suggestion for the tag name itself. Chuck (talk) 16:35, 5 June 2020 (UTC)

Volker and I have had many good interactions in OSM. However, with this one, while I do listen, I reserve judgement: I'm not leaning in this direction. Rather, I think reporting_marks=* is a perfectly adequate tag, as it exists in three (large) countries and, literally, "that is what it is called." If a better name emerges (I don't quite see how), I suppose I can go along, but I don't see a compelling to use a "less region specific tag" for a "region specific tag." OSM has plastic tagging, we've (successfully, though there is some "clean up / conflate the tags without the s on the end" work) gone ahead and done this, I think it's fine after we conflate and document. Stevea (talk) 16:46, 5 June 2020 (UTC)

Makes sense to me. I'm curious to see if I get any feedback from that OpenRailwayMap list post - I think if no one else comes back excited about it, it'd be pretty darn safe to assume that reporting_marks=* is the way to go. I don't mind going "universal" if someone else really has a use for it, but if not, I see no reason to make the tag needlessly broad either. Chuck (talk) 16:58, 5 June 2020 (UTC)

Out at the hairy edge of too many colons, I'll say that it might make sense for reporting_marks=* to someday be folded into Volker's idea of operator_designation=*. Today (mid-2020) let's say "we're using reporting_marks=* into the foreseeable future..." and there may come a time (in the 2020s?) where we "integrate into" a more-worldwide operator_designation=* way of tagging things. But, for now, in 2020 and the early 2020s, let's say, it's moving into a reporting_marks=* world in USA, Canada and Mexico. We can more-widely integrate later. Stevea (talk) 03:05, 6 June 2020 (UTC)

Y'know, if we got a motivated Mexico-based mapper who is familiar with "reporting marks and Mexican railway infrastructure" to light a spark, we'd have a nice fire burning in two or three countries before no time. Stevea (talk) 03:13, 6 June 2020 (UTC)

Steve, I haven't seen any other feedback on this after Volker's, even after your follow-up list emails yesterday - so I'm going to go ahead and implement on the Wiki, since I have an unexpected hour or two free this morning. Thanks for helping work out what to do here! Chuck (talk) 14:30, 7 June 2020 (UTC)

Done, and Key:reporting_marks has also been created to support the new key. Chuck (talk) 16:14, 7 June 2020 (UTC)

We really need to stop going deeper (with colon-indentations) here! Key:reporting_marks is beautiful. Really, a great deal of thoughtfulness, experience, heavy lifting, serious consideration, well-developed wiki skills and politeness have all happened here. What great teamwork we've seen in OSM in this endeavor. Stevea (talk) 07:20, 8 June 2020 (UTC)

After doing all the implementation of that nice reporting_marks=* key ... I may have found a better way! Oops, but if it's better, frankly I'm still happy to give up the key work. Plus, it potentially solves the problems of map usability and what labeling North American users expect that we were talking about over on my talk page.

I paid attention for once (which perhaps I should've done earlier) while editing in JOSM, with the OpenRailwayMap paint style on. Notice how if you have an unnamed line, it's labeled null null? And a line with a populated name=* field shows as null Whateverthenameis. Finally occurred to me to wonder what tag the missing null value represents.

I wandered over to a nicely completed section of German railroad on the map, figuring the fellows who worked out both the tagging scheme and the renderer probably did something smart, and I just wasn't smart enough before to notice what it was. Unsurprisingly, they did. Turns out, in Germany railroad routes have numbers, just like a road. I dug into the MapCSS files for the paint style and the ORM renderer, and that other null field is the route number stored in ref=*, and the label is ref=* name=* concatenated together with a space in between. I didn't realize that, in part because the description of the ref=* key on the OpenRailwayMap/Tagging page is so short, I didn't realize its significance in the rendering scheme. I'm sure if you read the page and are a German rail guy it's blindingly obvious what a "railway line number" is, but since we have absolutely nothing analogous to that here in NA, I just glossed over it without much thought.

If we were to use that ref=* key the way we're proposing to use reporting_marks=*, then with zero changes to the map rendering, we'd be getting exactly the map rendering output that US rail users expect to see. If you have the CSXT James River Subdivision, zoomed out you're going to see just CSXT, and zoomed in it becomes CSXT James River Subdivision. That is a normal, useful North American rail map, and I'm frankly excited by the idea this could be that easy to fix!

There's absolutely nothing analogous to that European line number anywhere in North America that I'm familiar with in probably 35 years of being around the rail industry here, so we wouldn't be "losing" some sort of valuable data in ref=* by making it the repository for reporting marks here. Meanwhile, so far, of the 398 times the reporting_marks=* tag's been used so far on a way, all but 9 of those times have been my work over the last few evenings implementing it on my edits. I can literally change that in about ten minutes for my whole area, and no one is out any work. Then it would just be a matter of me doing a pretty small amount of wiki rearranging to lead anyone who does look up the Key:reporting_marks page to the fact that the key is deprecated, and we're putting the marks in ref=*. And if you pull up the Key:ref page, we're even being consistent with the global (beyond rail) intent of the tag, which is to store alphanumeric refernce codes ... of any kind. In our case, it just so happens that the most useful alphanumeric code to store there would be the reporting marks.

Plus, it's even an answer that Volker might like, too - after all, we'd be doing exactly what he suggested, which is using a more general, international key for what we need. It just so happens to work out perfectly if we do.

Thoughts?

Chuck (talk) 20:56, 11 June 2020 (UTC)

I tested this yesterday on a hundred or so of my own lines with a single operator, and once the server had time to re-render the changes, it works beautifully on the ORM render. A line with ref=NS and name=South Branch renders perfectly as "NS South Branch" at zooms >= 15, and as just "NS" at zooms 12-14, and with no tag at zooms <12. This is exactly the labeling style expected on a standard North American rail map - finally! And no modifications to the renderer necessary to make it work perfectly. I've uploaded samples at Zoom 12 and at Zoom 15 for comparison.

I'll drop a follow-up email to talk-us since fewer people see this page, and if it makes sense to everyone else, I'll make the changes later this weeknend to the wiki.

It's awfully nice to see a piece of US rail map acually look like a standard format US rail map!

Chuck (talk) 22:46, 12 June 2020 (UTC)

After reading what research you've done, I'm (tentatively) OK with you "backing out" of reporting_marks. My guess (I speak from first-hand experience of doing it myself, though spottily) is that we in NA have thrown this against the OSM wall kind of randomly, hoping it will stick. It hasn't, then it did lightly with your brief wiki entry, but again, I'm OK backing it out. I would like you to run it by both the ORM mail-list and Volker, if I might ask you to do that and I'll think we'll get good feedback that you are (I think so) or aren't on the right track here. Stevea (talk) 05:41, 18 June 2020 (UTC)

Move Operating Rules section to its own page?

If no one has any objection, I'd like to move the entire section to its own separate page. It has a ton of good information, but most of it isn't likely to be immediately needed by most people who visit the main NA tagging page, and it's long enough to overwhelm the page and make it a little hard to find some of the most referenced information.

If everyone concurs, I'm happy to volunteer to do the work myself to make the move and make sure it's clean.

Thanks! Chuck (talk) 15:43, 4 June 2020 (UTC)

I'm OK with this. Thank you. I recently did this sort of split (and it was a MUCH larger job!) to California/Railroads. Stevea (talk) 16:04, 4 June 2020 (UTC)

I went ahead and made the move a few minutes ago. I do think it helps with navigation on the main tagging page. Did a tiny bit of header cleanup on the transition to the new page, too. Chuck (talk) 21:17, 4 June 2020 (UTC)

Tag:old_railway_operator

This tag is in widespread use across the US with over 135k applications. While working to clean up the NA tagging page here, we may want to formalize the tag a bit so that we are filling it with consistent information.

The info is valuable - the (personal estimate) second most common railway map labeling scheme in the US is to label routes XXXX (ex-YYYY), where XXXX are the reporting_marks=* of the current primary operator, and YYYY is the reporting marks of the best-known former operator. Not being able to generate this extremely common map style using the OSM/ORM data would definitely be a loss, especially if the data is known and already partly entered.

I suggest the following features:

• Label all usage=* ways (essentially on routes) with old_railway_operator=*.
• old_railway_operator=* should be reporting marks for that operator; this is consitent both with the normal use of the data, and the way most values in the tag are currently already entered, so less re-work.
• If in doutbt about which former operator, since some of these lines went through six or eight, name the operator as of 1945. This represents both the rough peak of railway mileage and traffic within the US, a point after most of the early set of mergers (pre-1915 or so, the business scene was pretty tumultuous), a point before the big post-war wave of mergers began as traffic dropped, and a point most likely to be the former operator with which a map user will be most familiar.

And, one caveat/exception: If a line was part of a key merger (especially just before the suggested time period, such as 30's-40's) where it's likely the line may be significantly recognizable under multiple old operators, it may be adviseable to list both. For example, the main C&O route from Newport News, VA to Cincinnati, OH would be old_railway_operator=C&O, as that's all it was known as since the 1880's. The Pere Marquette line in Michigan, which the C&O fully controlled in 1945, but didn't formally merge into C&O until 1947, is probably best labeled old_railway_operator=C&O (PM). The Hocking Valley line, which C&O also absorbed and which connected C&O and PM, was folded into C&O in 1930, but is arguably still worth representing as old_railway_operator=C&O (HV).

I think either way we should probably try to formalize this tag a little more somehow, especially since it's almost exclusively used in NA. Definitely open to suggestions and thoughts! I also don't mind writing up any associated wiki changes based on the results. The key wiki already exists, but it's fairly thin, and other than having the key description box added a couple years ago, it looks like no one has really worked on it since 2010.

Chuck (talk) 17:36, 10 June 2020 (UTC)

Discussion at lists:talk-us/2020-June/thread.html#20102. Arlo James Barnes (talk) 05:41, 13 June 2020 (UTC)