User talk:Nathhad/TaggingNADraft

Draft of Route Importance

I am distinctly impressed with the NADraft initial draft Page. Quite minor, very much inteded as constructive criticism: "capture the nuance," please pluraize, "capture the nuances" feels right. On a more nuts-and-bolts level, I'd continue with the well-fleshed-out-now concept of how a named line (whether "as a named Subdivision" or "known to be Industrial, with a name...") further drives tagging. A serious, hard-core, correct trend in OSM is "well, what is it, really, in the world, well-tagged?" And so the usage tag is an awesome workhorse right now. The whole "Dakota Jct." discussion earlier begged the question of "Class II?" having something to do with usage between main and branch. We've now a much more comprehensive discussion of how better or best to tag these. It remain fuzzy, but compared (in my mind, at least) to previous years, only on the periphery now. We have much better/pretty darn good distinctions about how to (logically) map between usage tags (the OSM representation) and the "real world attributes" (as you describe them in this well-articulated draft). This is a very nicely and sensitively integrated production: very, very nice work. Stevea (talk) 02:36, 6 June 2020 (UTC)

Nuanced change made, and thanks a ton! I'm hoping I might have time to finish this little side project tonight or tomorrow - once I have enough examples put together on the example page, I'll publish that up, and then fix the links to it in this draft. If I haven't received any other feedback on it by then (and so far you're the only one who's been interested or responded back), I'll go ahead and push this out to the real page.

From the perspective of naming, I would very definitely make the argument that naming is one of the least important possible factors in usage determination. I think the overemphasis on the importance name for rail routes in North America is actually an accidental quirk of ORM in the US starting as a railroad map made by non-railroaders, and I don't mean that in a nasty critical way at all, more in that there are certain things about the way railroads are labeled and tagged in North America on this map that actually seem fundamentally weird and broken if you actually come into this fresh, and from a railroad background. I think as a result it's probably resulted in an absolute ton of confusion for North American rail taggers, because in most respects the whole system starts from the wrong end of the stick. The following might sound like a little bit of a rant, but it's more a matter of my having come into this from a different perspective, and I think maybe that's letting me see what's causing people so much confusion. (Since this is just safely on a talk page under my user page, and after working on this together for a week or so hopefully I seem like a fairly level-headed non-jerk, maybe the below will sound less like a rant and more like I intend it to be, which is pointing out a somewhat big issue I think maybe most people here don't have the background to see.)

Part of the problem is that what ORM tags use for the name of a track way is not the name of that track way, to the point where we might as well say "Name is the name only, except for North American railroads where it's never the name." We're using the name of the track's subdivision, which is very, very wrong, and that's why this is all so hard to figure out. Nearly every piece of track in the US, down to the shortest spur, has a name (because that's vital for safety and dispatching), and it's not the division name we're putting in name=*; in most cases you probably won't know that name unless you work for the railroad, have a ton of friends or family who do, or have access to the railroad's documentation, which is extensive on naming. The actual name of every track is one of the things we tell people in the wiki they can shoehorn into description=* (though we also tell them it can be a description of the route instead), and it's always going to be something like Track 3, West Yard Lead, Ladder Track, etc. Even for mainlines, the thing we put in the name=* field isn't the name of that track either. 99% of the time, for a single track main, the name of that track is just going to be "Main". That's it. For a two track main, it'll either be EB Main and WB Main (or similar, for north and south, etc), or Main 1, Main 2, Main 3...

So for example, if the dispatcher is giving you an order to pull out of the yard on CSX in Lynchburg (which isn't signaled, so orders required) westbound onto the nearest (normally Westbound) main track, the order will be "Proceed to exit west yard lead and occupy Track 1 to 146.1," which is the location of the next end of the block. You would never hear a direction to occupy the James River Sub, because that's not actually a track. If you want to see what the mainline tracks are named, there's an employee timetable here, you'd want PDF page 82 and the yard is between Tyree and Lynchburg. You'll see the mains are just named 1 and 2 through Lynchburg, where it's a double track main. You'll see some of the lesser but important track names on P. 87. The rest of the yard track names weren't mentioned in the ETT and would be on a track chart in the yard office for reference, since they're under the control of the yardmaster and not the dispatcher. As a different example, the next passing point to the East is actually named Joshua Siding, as that's a siding and not a two track main. Then, every control point otherwise is identified by either a name, or a milepost number.

And don't let me get started on the rendered map showing the Subdivision name of lines, but not the operator! It makes me almost pull my hair out. It probably works brilliantly in Europe, but produces a map that anyone associated with railroads in the US would consider fundamentally broken and impossible to use. That's its own whole topic... I can tilt at that windmill another day!

So, the real meaning of that long exposition, is that we really can't use our name or the presence of a name to even help figure out the right usage=*, because we aren't actually naming anything right, so it won't be any help.

Getting back to the RCPE/DME discussion, coming from a railroad perspective, that one would be easy, if I base it only on the information presented in the discussion - it'd be a branch, because the data given really only describes length and carloads, but doesn't really give us enough info to work out the details that help decide. However, I did a little more digging since I'm not directly familiar with the DME route, and I would concur its main route should be tagged usage=main based on the following deciding factors: the line connects multiple localities, and carries a high proportion of long distance traffic in large blocks (non-stop); hence, most traffic on the line is through traffic, even though it is from or destined for end points at or near the dead-end of the line. Essentially, when you look more directly at the nature of the actual line and traffic, this situation is almost identical to the example case we give of FEC, where you have a Class II regional that's really a usage=main. One of the characteristics of a branch is that most of your traffic is locals - smaller trains stopping to serve multiple customers. This line has a lot of big freight and long distance traffic, so if you sit at any point on the line (especially to the east where the ag products are heading), you're going to see a lot of assembled trains of grain or resources heading somewhere far away (basically through traffic), not a few locals passing you. That's the easiest way I can really break down the traffic difference. This is a good enough edge case once you get into it, I may add it into the examples too, with three of us having looked it over and come to a pretty similar conclusion.

One more good thing coming from this discussion - I've added two more paragraphs to the draft to help clarify, based on things we've mentioned above just now. One is a caveat that because of the odd way we name routes (the subdivision name), in actual practice a route may not have the same usage=* tag for its entire length. The second is a paragraph below the table, expanding just a little on the "predominant traffic" term I use in the table, based on the RCPE discussion above. Please take one more peek of you have a minute, and see if they make sense. I feel like the "predominant traffic" clarification really helps make cases like RCPE and the FEC example a lot more clear.

Hopefully that was mostly useful, and not too much of a rant! Chuck (talk) 23:45, 6 June 2020 (UTC)

A short follow up on the RCPE as I was browsing around after - the line has loading loops as far west as Harrold, SD, on the Pierre Sub, with several more to the east of it. It's not a big enough "guideline" to go in the table, but will definitely go in the example (and gives me yet another reason to use this one on the example page). Loading loops are handy for us, because ones that size almost exclusively mean unit trains, which point strongly toward through traffic and a main designation, and they are a feature you can see from maps at a pretty zoomed-out level of detail, too. Chuck (talk) 00:19, 7 June 2020 (UTC)

To be as clear as I can about names and surrounding the issues that you and I seem to be orbiting about them. 1) There is history: the TIGER import "mistakenly" (there was no operator=* at the time) put into the name=* tag the name of the operator (usually owner, let's call it operator for semantic ease). This sounds like something you (Chuck) might have actually preferred remain "as it was imported," as you mention windmill-tiltilng, but especially as ORM came online (circa 2013-4 as it was paid attention to in the USA), was seen to be a wrong aspect of the 2007-8 import, and so many name=* tags have been intentionally migrated to operator=* tags. (However, many still remain in the name=* tag, too; we simply haven't gotten around to "fixing" them). Of course, this heavily "drove" the quest to find the name of the line (Subdivision XYZ, Industrial Line ABC...), at least one reliable source is the bts.gov (links to arcgis.com, you've tried it) noted in United_States/Railroads. This "re-naming" work is ongoing and it is believed correct for it continue, even (perhaps even especially) considering your industry experience, perspective and notes above (though, your notes above might mean it needs a serious overhaul, I'm not quite sure yet). It isn't that name=* OR operator=* are considered to be "one more important than the other," rather "let's simply tag these with the proper key-value pairs as OSM documents them." It may very well be that the way we've been doing this in North America needs a serious overhaul, that's entirely possible and I am in listening mode with you about this. If it needs fixing, it may be a Herculaean effort, but we can do it. 2) The issue of some subdivision name containing a word like "Mainline" on what is clearly (as clear as it can be in this subjective realm) branch rail is already documented: I mentioned this many years ago in wiki and I believe it is correct. Simply because a minor / Class III rail with essentially nothing but branch and/or industrial rail naming their "connecting running track" as "XYZ Mainline" does NOT mean that OSM should tag this with usage=main when usage=branch is obviously correct. This appears to be good, sticky advice still: don't depend on the NAME of the rail line to "drive" the usage tag. 3) I agree with you that "name" is a "less important" aspect of rail in N.A. in OSM, (imo, "more important" is usage=*, given what ORM does with this tag), but it is still important from an identifying perspective. OSM does, likes to and SHOULD properly apply a name=* tag to a datum, where known. To underscore: what the name actually IS (and we've said this for a long time) should have absolutely nothing to do with setting a value on its usage=* tag. I believe we fully agree here. AND (thank you), you outline excellent "how to" on what SHOULD drive this tag.

All that said, I now read what you write above with both a sense of relief (that someone with industry perspective who can truly offer OSM the "right method" i.e. "how industry in N.A. does this" is chiming in) and a sense of dread (that we haven't been doing things correctly). The middle paragraph you write (with "very wrong" and "EB Main / WB Main") is absolutely news to me, although it makes sense. I have even bumped up against this when I was working on some rail yards in and around Commerce, Colorado and discovered that names like "Industrial Track 604" (maybe that's not exact, but it's close) could be discovered on specific segments in the stockyards there. So I've suspected it's messy, but not as extensively messy (how it should be vs. how OSM has done it) as you describe.

Thank you for your RCPE/DME discussion, it effectively makes your case on how we should (and did) determine usage=* on those (farily lengthy) segments. It looks like the approach that Alexander took (to answer my question, I'm a relative rail noob, but I know OSM pretty well) is quite similar to yours (look at length, look at amount of traffic and its "thru-ness..."), and hence you and he reached the same conclusion (it's main, not branch).

I've realized that "in actual practice, a (railway) route may not have the same usage=* tag for its entire length." For example, I both documented in wiki California/Railroads/Active and with usage=* tags in OSM that Sacramento Subdivision is usage=branch S of the Sacramento River to Stockton (41% of the route), primarily because it hasn't any passenger=national traffic on it (S past that point). That might be wrong, but I was working with the best semantics of how we "should" use usage=* in N.A. and nobody seemed to argue. We might want to revisit that, along with many others, based on your perspective.

Bottom line #1: it looks like we now have a MUCH better way to select a proper value for usage=*. That is awesome. Bottom line #2: it looks like we might need a wholesale re-examination (and re-do) of how we use the name=* tag on N.A. rail (perhaps it moves forward with some application of the description=* tag, I don't know) and that is a potential headache, but with enough discussion (and aspirin?) we can eventually solve, even as it appears to be a VERY large scale fix to apply. Stevea (talk) 18:59, 7 June 2020 (UTC)

You know, the good thing is, having had about 24 hours to ponder it (and start in on a draft for the other wiki project I wanted draft up to propose adding, which was cooking up a Useful Combination summary section for the OpenRailwayMap/Tagging in North America page similar to what's found on so many other pages), I'm pretty sure the best way to "fix" the naming and the usability of the generated map wouldn't involve any real re-work or re-do of the name=* or operator=* work that's already been done. You could get the important information added in, using a slight clarification to the existing North American tagging scheme, and adding one more slightly tweaked map style to the https://www.openrailwaymap.org/ page.

Step one would be to keep the existing name=*, operator=*, and reporting_marks=* tags as we've already worked them out, with a very slight clarification for North America that operator=* is always to be the train operator, which is backwards from the international tagging scheme, but what we've already been de facto tagging here for years.

Step two would be to use the description=* tag in North America exclusively for the actual railroad name of the track, where we can find that information. That's already an officially acceptable thing to put there according to the international naming scheme, we'd just be clarifying that in North America, the tag should be that name or nothing - no "Washington to New York" route description. That sort of route description would really only be appropriate for a route relation anyway.

Step three would actually be the main work - which would only have to be implemented centrally in the ORM renderer. The labels on all lines in the new "Infrastructure North America" style, rather than being the current name=* field, should be operator=* name=*, or better yet reporting_marks=* name=*. The traditional way to do this for ALL rail maps in the US is actually only operator=* or most often only reporting_marks=*, because almost no map consumer in the US - maybe 1% at most - actually cares about the data we've put in name=*; that's why I said before that the original TIGER name is correct, that's how rail mapping has been labeled in the US for 150 years. However, there's no reason to throw away the name=* data, which is perfectly valid data and is useful in some contexts, so to me displaying reporting_marks=* name=* would give you a rendering that comes as close as you can get to satisfying 100% of your map end users (while not losing work and keeping OSM users who have a very different idea of what a rail name should be comfortable, too).

For track with mutliple operators, the traditional map labeling is always (assuming owner/operator is always #1 in the list) "OPR1 (OPR2, OPR3)", where the owner/operator is always first, and trackage rights holders follow in parentheses, comma separated. That's another display standard that's at least 100 years old here, so will be easily understood by non-OSM-editor map viewers/consumers.

The one addendum to step three in the renderer is at zoom levels 18 and 19, you don't display the above combination - you display reporting_marks=* description=* for all tracks with a usage=* tag, and only description=* for tracks with a service=* tag.

That little bit of tweaking (very little with the tags themselves) results in generating a map that will actually show what most rail map users, even the general public, are actually expecting to see and looking for when they pull up a rail map. In a lot of cases, the current rendered display with only the name=* (Subdivision) rendered as a label is functionally equivalent here to naming each section of an interstate after the county it's presently in, and optionally tucking "I-95 North" into the description=* field but never showing it. Those subdivisions are an administrative division only, some railroads use them to reference routes, but most don't. That's the part that I was saying has me pulling my hair out now trying to actually use the map we're creating, I see lots of pretty color-coded lines, but nothing at all on the map tells me the owner/operator of any line there, and that's the main part rail users here expect to see. Fuctionally it's equivalent to looking at a map with no labels at all.

I think the reason the current naming scheme probably works great in Europe where it was developed is that an awful lot of their rail network now is partially privatized lines that were formerly nationalized, and in a lot of cases (Britain's a great example), the track ownership and maintenance, and the train operation, are always two different companies. Hence, the infrastructure companies, which are usually either government or quasi-private, really *do* have named routes, and then the train operators are a separate entity. It works like our interstate highway system, where the government owns the road, the road really is "I-95", and the operators are Swift Trucking and Greyhound Bus, who just use the road. In that context, the original tagging scheme on OpenRailwayMap/Tagging works perfectly, which is probably exactly why it came to be that way. And since it works exactly like highways that the majority of OSM editors are working on, it's the kind of scheme you'd expect to see and intuitively understand if you were a highway editor in the US who wanted to jump over and help out with the huge pile of ORM rail work.

In the North American system, all infrastructure routes are owned by operators, and they don't really have names in the way Europe uses them. The routes are known almost exclusively by the name of the owner/operator. There is no "I-95," your train shipment goes east on "Swift Trucking's Road" and hangs a left on "Schneider Trucking's Road". At most, because the Class I operators now all have so many mainlines, it would be "Left on Schneider's New York road" or "Left on Schneider's ex-Roadway road," because referring to the absorbed former operator gets you back to an operator label that's unique to one main line.

In a real railroad example, the CSXT main route from Newport News, VA to Huntington, WV isn't known as the "Peninsula, Rivanna, James River, Alleghany, New River, Kanawha Line", it's called the CSXT ex-C&O mainline, a name derived solely from the name of its current and former operator. That's common. Shoot, CSXT doesn't even put the subdivision name on their own maps, that's why it's so hard to get the information right and most of us are rooting through FRA databases. Their own maps identify their lines exclusively by "CSXT" or maybe division name if you get the right map, and ID all other railroad lines exclusively by reporting marks. Any map produced for or about the railroad industry by anyone who isn't a railroad themselves will label all the lines only by reporting marks, or at most (often for railfans) by reporting marks and former reporting marks, like the "CSXT (ex-C&O)" example.

With the track names, the railroad's existing extensive naming of individual track section comes about when you realize how they have to operate to not have collisions. As soon as they got the telegraph, they switched from schedules being primary to a system where the primary right to enter any block of track was based off of written train orders, passed to you by the telegraph operator at each station or tower. For that to work, you have to be able to uniquely identify every control block of every track. As time went on, they started to get automated signals to simplify control of through blocks, but even today those signals (at the end of the same original blocks as telegraph days mostly) are partly controlled by the same dispatcher, and are still secondary to verbal train orders from the dispatcher, given over the radio and copied down.

I'm glad the RCPE/DME discussion made sense to you, too. There's probably still a little figuring out to it, that westernmost through subdivision to Rapid City might actually be a branch, I dind't look deep enough to be sure but a quick scan of that part of the line and the one northwest branch off of it didn't show a lot of big customers. When I get a chance to add more examples later, I'm probably going to either pick one subdivision for the example (probably the center one with the loop loaders), or do a separate example for each division, I'm not sure yet.

It sounds like you arrive at what the same answer I would for the south end of the Sacramento Sub, too, though I think I might have added factors up sligtly differently to get there. Looking at your wiki info and a quick look at the map, and without any other info other than knowing the ex-WP and ex-SP routes are both now UP, I would assume through freight traffic south of Sac is getting routed on the ex-SP line, and for freight traffic, the ex-WP line is probably only seeing locals. In considering the shared passenger service on the line, I wouldn't necessarily be looking at the presence of national-level passenger traffic, I'd just be counting that into my freight count in one combined count. Communter rail counts the same as a freight local to me (short-haul, and stops at every station), and national level long-haul counts the same as through frieght by my proposed guidelines. So, a route that sees, say, two freight locals a day, eight commuters a day, and two long haul passenger per day, I'd probably actually be counting as a branch despite the two long haul passenger trains. And in fact, the Buckingham Branch Railroad, Richmond & Alleghany Division branch line example on the new OpenRailwayMap/Tagging in North America/Route Importance Examples page is strongly similar to that, but without the commuters - that line sees a major long haul DC-Chicago train on part of its route three days per week each way, but one train doesn't change the nature of the route, if that makes sense.

In particular, and this hits a little on a grey area that I'd have to think about a little more to explain more clearly, when you're talking about trying to make this distinction, the freight traffic "counts" more per train by a little bit when it's a track where the passenger service is a guest on the freight-owned line. To set up a theoretical scenario, and maybe use a little shorthand to make this easier to read (T vs L for through vs local, P vs F for passenger and freight), a line with an exact 50/50 split between L and T overall I'd probably say is main overall, assuming we're talking more than just 2-4 trains overall total. But to tweak that scenario ... I'd still say main if the local passenger trains outnumbered the through freight. For example, I'd say a line with 12LP,1LF,8TF is most likely still going to be a main line, despite only strictly being 38% through traffic. But this is sort of a fuzzy example I can't really clarify well in words yet, it's just from years being around it, sort of like the legal Stewart's test for obscenity, funny enough.

Getting to your bottom line ... if you have a moment, take a look at the draft I mentioned I started (as of right this moment I'm only done with ways), and see if those minor tweaks to the international tagging definitions still seem consistent overall with what we're already doing in NA. If they do ... who actually develops and controls the renderer on https://www.openrailwaymap.org/, and how likely is it we could volnteer to help work out a new map style for NA?

Edit, and please don't hesitate to start any general comments/suggestions on the new draft as a new topic in here, so we don't have to go quite so deep into the response colons .... since I seem to be in novel-writing mode for responses this weekend!

Chuck (talk) 23:02, 7 June 2020 (UTC)

Draft of Usage vs. service

Reading through the draft, I see that usage=* and service=* are considered mutually exclusive. According to key:usage, usage=main and usage=branch are indeed mutually exclusive with service=* but other values of usage=* may be combined with service=*. OpenRailwayMap distinguishes between "Industrial line" and "Industrial service track", the distinction being whether a way with usage=industrial does or doesn't also have service=*. I generally tag industrial and military tracks with this distinction, with a working example at the Ports of Los Angeles and Long Beach.

Are we getting rid of this distinction in North America? I'd rather not have to review and undo a lot of my own work here. clay_c (talk) 20:32, 16 June 2020 (UTC)

I lean towards Clay here, that service=* can be and importantly IS tagged on usage=industrial track (and also usage=military, though I think to a lesser degree, I'd have to taginfo or OT Query to see exactly how much). I can't remember exactly where (Chuck has created a LOT of text to digest in the last week or two), but he said (I paraphrase) "I kinda wish ORM didn't allow the exception of usage=industrial and service=* together." However, ORM is clear that it DOES allow this, and for precisely the reasons (well, it works in California, therefore NA) that Clay points out.

Chuck implies (or even outright says?) that Clay's distinctions (which I agree with Clay are properly tagged) are more-or-less explicitly "defined" in that giant federal source Chuck quoted. Yes, there are parts of that which have beautifully succinct definitions, although picking and choosing among them (as we might wish to ignore others) doesn't move the ball forward, especially as we write wiki to establish or better-define (for NA) Best Practices (for NA). This (NA) documentation should highlight differences in NA, not redefine them needlessly.

We can't "backtrack" existing tagging, its clear documentation (in ORM/Tagging and usage=*) as well as its rendering in ORM for a simple "wish for simplicity," we'll have to do better than that.

Let's agree that what we already do (and document, and render) is correct. It isn't 100% true that usage=* and service=* are always mutually exclusive, this is only 100% true with usage=main and usage=branch. We must accept that and hew our wiki (here, elsewhere) and our tools (if any) to that reality. Stevea (talk) 21:05, 16 June 2020 (UTC)

Clay and Steve - I do see your point completly on not accidentally (or especially semi-intentionally) changing things where the international ORM tagging scheme has made an explicit exception. Let me make a pass through this draft and tweak my wording some to make that clearer and see if it still keeps the other parts of this defintiion usable. The exception makes me a little itchy coming in as a recent ORM outsider, but in a lot of ways the ORM exception and the basic rail industry definitions aren't completely incompatible, either. Let me do a little tweaking and see what I can make of it!

I'll also doublecheck my original live Route Importance section after, to make sure I didn't accidentally imply the same exclusion there as well. I don't think I do, but I'd rather check.

Thanks! Chuck (talk) 21:55, 16 June 2020 (UTC)

Okay, I did some tweaking to fix this, and also pulled up the renderer code to verify how this exception is used, and added that as well. That way, the mapper knows how to decide whether they want to use the dual tag exception or not. Chuck (talk) 22:27, 16 June 2020 (UTC)

Draft of Useful Combination

A quick note for @Clorox, I like the change on the track_ref tag under Useful Combination, but that part of the draft is already up live on the actual OpenRailwayMap/Tagging in North America page. I'm going to go ahead and copy your change verbatim to the live version to make sure it doesn't get lost.

I've seen two alternate things proposed for track_ref, and I don't know if I've seen a consensus yet on which is right (as I'm still fairly new), so that's been on my list of questions. One has been the simple track numbering you mention in your edit, which does sound to me like it matches what's in OpenRailwayMap/Tagging under track_ref ... except we do have slightly different numbering schemes, too. For most railroads, there's a "working name" like 5 or L06 or Main 1 that's used in the operating manuals and the ETTs, and then there's an actual track reference number that uniquely identifies that track systemwide. However, those aren't always easy to find. So, I'm curious which is the better fit for NA long term for which tag, but I haven't gotten to ask the question yet.

Chuck (talk) 18:19, 17 June 2020 (UTC)

A simple "chime in" that I don't believe I've ever seen (NA-wide or worldwide in OSM for that matter) a "real debate" on what consensus has emerged or how we do or should do railway:track_ref=* in NA. The railway:track_ref=* wiki solidified with only a couple of edits in 2015-16 and hasn't changed since. While Chuck's view of rail from an industry insider (bridge engineer?) and having looked at a lot of NA rail maps is deep and valuable here, it certainly couldn't hurt to welcome more of that perspective and a good healthy discussion on how we (NA) might best use railway:track_ref=*: even (especially?) if it is exactly the same as the rest of the world does so in OSM. Its wiki implies that railway:track_ref=* is ONLY for tracks "inside railway station area", and ref=* is used for "reference number of the railway line the track belongs to." If NA can adhere to that (and does in existing tagging, or that could relatively easily be achieved) then we're doing fine in regard to railway:track_ref=*. Maybe we could "sharpen up focus" on railway:track_ref=* in the Useful Combinations section by making this distinction with railway:track_ref=* (AND ref=* as more "the line, not station-track"). But again, we're largely duplicating existing wiki / docs as we do this, and I really do see these NA pages as "well, these are differences in NA from the rest of how OSM tags rail around the world." Stevea (talk) 22:25, 17 June 2020 (UTC)

Agreed, Steve. Plus, if something we do really is completely different, I feel like it should probably have a different tag, instead of trying to jam it into an international tag where it really doesn't fit. That way, we don't populate a whole ton of information that someone tries to pull into a data application that expects it to have the international meaning at some point. I think the reporting marks turned out to be a perfect example of this. Jamming them into ref would've made them print with current settings, but I firmly agree with everyone who pointed out to me the problems in that idea.

One tie-in on that - from reading the international tagging info over and over, they consider yards to be "freight stations," I'm guessing from context that's more of a direct translation from German that doesn't come across directly. Because of that, I've been interpreting them to mean that track_ref to apply to all station and yard tracks, since their other terminology seems to lump those together. And using it that way (filling out with the operating track numbers Clay was talking about) appears likely to make us completely consistent with the international use. If we turn out to need a field for a differnt kind of individual track id number, and it's not like a number that's used internationally, we should probably make a new field if the time comes. Chuck (talk) 23:13, 17 June 2020 (UTC)

Yeah, I WAS a bit unclear on how when Clay added his railway:track_ref=* additions that "Main Track 2" should have railway:track_ref=2, "Yard Track 57B" should have railway:track_ref=57B — that sorta made me go "huh?" First, why drop "Yard" and "Main" as that's like losing data we can't get back and Second, wait, "ref" becomes "track_ref" um, huh? But now, as I see that (whether from a German translation or not) as long as we're agreeing that yards are "freight stations," meaning that yards have the same rules as "stations" regarding to the use of railway:track_ref=*, it is becoming more clear to me. I think I need a bit more practice thinking about it, but now that in my mind the initial crystallization of how the Germans think about things (their agglutinative language?) and this likely heavily influenced how ORM tagging evolved, it makes more sense. Anybody else grok this as I do? I THINK I'm on the right "track" (heh!) of understanding this! Stevea (talk) 02:39, 18 June 2020 (UTC)

Adding railway:track_ref=* to stations and yards is a practice I pretty much directly copied from German OSM. I don't think they number their main tracks the same way, but in North America we certainly do, so I took the liberty of adding the tag to main tracks as well. It doesn't have to be mutually exclusive with adding a track's full name in a separate tag.

By the way, I have a pretty good working understanding of German if anyone needs clarity on any technical terms. I haven't had much conversational practice lately but I can definitely find comparable lay and technical terms in English. And if any wiki pages could use better German → English translations, I'm happy to work on it. clay_c (talk) 16:33, 18 June 2020 (UTC)

The dual tag (one numerical, one written out) makes sense to me, and seems consistent with how I understand the rest of the tagging scheme so far. On the translation, the number one thing I can think of is to maybe take a side by side look at OpenRailwayMap/Tagging and see if the concepts are being translated across clearly. There are some things that don't look like they come across, and I'm not sure if it's a translation thing, a "they don't have that in Germany" thing, or a "they don't have that in Europe so even our British friends haven't 'corrected' it already" thing. One is that I don't really see the concept of a control point in there, only interlockings, which are control points here but which the wiki implies only exist where there's a signal box - just as an example.

Another example is "freight station". The tagging page seems to make clear that's a yard to whoever wrote it. I don't know if that's a translation thing, or a British thing where it's correct for their application. If that's correct for British rail, it's one we'll need to clarify on our tagging page here, since freight station here means something very specifically different.

Just some thoughts! Chuck (talk) 11:57, 19 June 2020 (UTC)

I got a bit hung up with "freight station, as has it its meaning in German and is essentially equivalent to 'yard' in English-speaking countries (both UK and US?) yet also means something quite specific (which is not a yard) in the US." That's a fairly tangled knot, potentially if not actually confusing (if all true), and if we're going to unsnarl it, we must do so carefully so local and worldwide rail semantics and OSM tagging well-harmonize. Chuck and Clay, I'd encourage the two of you to put your heads together and dialog (here?), as this is a bit beyond my ken, but it is a fascinating conversation for me to watch. Stevea (talk) 15:53, 19 June 2020 (UTC)

Agreed. I think we might actually need some British input to help us figure out if this difference is a translation issue, or a North America thing.

For North America, "freight station" referrs very specifically to a building, almost all of which are now closed. This was the railroad equivalent to a UPS shipping office or a LTL trucking terminal, back when you could still ship individual parcels with a railroad instead of full carloads. If you have a pallet of something to ship, you could drive right to the freight station and consign it with the railroad for shipment, and they'd ship that pallet (or smaller parcel) right to the freight station at your recipient's town. In very small towns, this was most often the other half of the passenger station building, but in any decent sized town and almost all cities, it was its own freestanding building, usually with a boxcar loading dock on one side, and a street loading dock on the other. Examples:

Former freight station (standalone)

Former freight station (standalone)

Former freight station (standalone, LARGE)