Hello everyone. I just got started mapping with OSM/ORM. I've added and cleaned up a few things and while I'm sure I've made some mistakes I've learned quite a bit.
1.) Is there an official convention for designating passenger train storage yards at the end of the line? I've noticed some users prefer to tag them as "service_station" and the guidelines weren't too clear. To me a "service station" should be an employees-only station where regular trains do stop, but only employees are allowed to board/exit (e.g. LIRR Hillside, NJT Meadowlands Maintenance Complex). I've been adding them as yards (they're also more visible zoomed out) but if someone had already had them as service_station but I left them alone.
2.) I've noticed that if someone tagged an "area" as a yard, it won't display in ORM. For a few of these, I've added a yard "point" so it could be seen on ORM. It seems "redundant" though.
3.) Should intermodal terminals ("ramps") be tagged as yards? Should we consider a new tag?
Lastly, is there a guide for what renders in ORM and what doesn't? It might be helpful since sometimes I add something yet it takes a few days for ORM to update so it's hard to know in advance what will render. Things that I've realized won't render: funiculars and funicular stations (they're there but no highlighting), abandoned:railway=station (would be nice to see some of the historic stops and terminals, maybe rendered with a strikethrough without the blue text), railway=preserved (the entire Strasburg Railroad wasn't rendering and it's a freight shortline as well as a tourist line, I switched it to railway=rail, usage=branch, railway:preserved=yes which worked rather nicely), signal_boxes, signals, defect detectors (and we should add defect_detector:high_car yes/no as an allowed tag), tunnel names (but bridge areas seem to render; it would be nice to "tag" the Howard Street Tunnel especially since it's right under a light rail line), turntable "areas" (possibly even turntables themselves), switches, buffer stops Things I'm not totally sure will render: railway=workshop, railway=interlocking Things I know will render: railway=junction, railway=crossing, railway=site (can we consider a tag for "timetable stations" on freight railroads, even as a sub-tag?), railway=milestone (can we consider a railway:position:prefix for milestone prefixes, I don't think we should use things like railway:position=mi:CFP14.0)
OK that's quite a lot for a first post from a new guy. Thanks for reading. My best to you, Jon
Lastly, is there a guide for what renders in ORM and what doesn't?
Use the source, Luke! Have a look at the bug tracker, several things that are missing are just missing because noone ever cared to implement it..
It might be helpful since sometimes I add something yet it takes a few days for ORM to update so it's hard to know in advance what will render. Things that I've realized won't render: funiculars and funicular stations (they're there but no highlighting),
This is intentional, we don't consider them railway:
https://github.com/OpenRailwayMap/OpenRailwayMap-CartoCSS/blob/ cd2a50634e6d8747ee689258cc431c6931fed1da/standard_labels.mss#L43
abandoned:railway=station (would be nice to see some of the historic stops and terminals, maybe rendered with a strikethrough without the blue text), railway=preserved (the entire Strasburg Railroad wasn't rendering and it's a freight shortline as well as a tourist line, I switched it to railway=rail, usage=branch, railway:preserved=yes which worked rather nicely),
https://github.com/OpenRailwayMap/OpenRailwayMap-CartoCSS/issues/7
signal_boxes, signals,
https://www.openrailwaymap.org/? lat=52.29524733743353&lon=9.635098278522491&zoom=18&style=signals
What is correct that no _UK_ (or _US_) signals are rendered. In fact only DE, AT, and FI are supported. This is just because at least a defined tagging scheme for all of the possible signals or the implementation in the MapCSS and CartoCSS styles is missing.
defect detectors (and we should add defect_detector:high_car yes/no as an allowed tag),
Not implemented.
tunnel names (but bridge areas seem to render; it would be nice to "tag" the Howard Street Tunnel especially since it's right under a light rail line),
https://www.openrailwaymap.org/? lat=52.1280282306381&lon=9.872835874557493&zoom=16&style=standard
turntable "areas" (possibly even turntables themselves),
Looks like this was broken by switching to CartoCSS, or the latest fix is not yet deployed on the server yet.
switches,
https://www.openrailwaymap.org/? lat=52.15820687474143&lon=9.946752190589905&zoom=17&style=standard
buffer stops
Correct, only the attached signals (Sh0 or Sh2 signs in Germany) are rendered.
Things I'm not totally sure will render: railway=workshop, railway=interlocking
They will not render, no rendering rules for them.
Eike
Welcome! I'm fairly new myself, and have been going through some of the same questions for the past few months.
Eike has already covered most of your questions from a technical standpoint, but I can jump in with some related information from a regional standpoint that ties into some of that, since you appear to be a fellow North American.
Context to be aware of - OpenRailwayMap started as a German project and spread from there, and that's how the ORM tagging scheme started as well. From what I can tell, most of the English wiki translation was done by Brits. Overall it's very cleanly done and sensible, but there are some fundamental concepts that just don't translate right in North American railroading from either German or British practice, and some others that we've only recently (last few months) really started to hash our way through. Your #1 question has actually been a recent topic, and actually got covered in part by a pretty cool international web/audio meeting a dozen or so of us got to participate in back on 7/4, so a lot of this stuff is pretty fresh and not yet documented. That's also why we've got some really *big* holes in how the map still shows up in NA ... giant things like having no functional line labelling at all to speak of in NA, because the European tagging scheme as it relates to how they actually label their lines is completely different (and the team doing the rendering had no idea until June that what's done now doesn't work for us). That was probably the biggest topic of that 7/4 meeting.
And speaking of documentation, as much as possible we've started trying to get some of these NA-specific tweaks added into the regional wiki as we work them out: https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging_in_North_America
Wiki progress comes in fits and starts, since we're all volunteers and it sometimes comes down to "I can map with my free hour today or I can *write* about maps."
A few of your more specific questions that I might be able to add on:
1. This is definitely one where the concept didn't translate well at all. Basically, yard is our catch-all in NA (everything that isn't schedule or train order controlled mainline according to the FRA in the US), and internationally they make a distinction between yards used for freight classification (railway=yard) and yards used exclusively for storage or maintenance (railway=service_station) that we really usually don't. I personally don't necessarily see an immediate value in the distinction, but since they render similarly and the international tagging is a little more granular, I can't see any drawback to tagging it the way it's currently written. That seemed to be the general consensus at the meeting, too.
2. This is intentional. There are a lot of railway yards that are long, skinny, and curved. If you placed the label by having the map software do something like calculate the geometric center of the area, on a long curved yard your label might not even fall anywhere within the yard. So, all location labels (stations, yards, junctions, and control points ... or "Operating Sites" on the wiki, which is another German term that really doesn't actually translate to English at all) are meant to have one node to serve as the operating site labelling point. Essentially, this makes for a better, more readable rendered map. (I started a draft for a new NA wiki page last month to start trying to clarify and illustrate issues like that, but got busy at work and had only finished about the first quarter - the draft is on my user page at https://wiki.openstreetmap.org/wiki/User:Nathhad/Operating_Sites_and_Interlo... and the third illustration shows what I was describing with the curved yard.)
3. I haven't seen this one discussed yet, and it's a really good question. These really *aren't* considered yards in North America that I've ever seen, even though they are operated under yard rules. In the real world, we tend to give them a more specific designation here than just yard, similar to "service_station" being more of a German-specific designation. The Wiki currently calls for tagging as man_made=container_terminal ( https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging#Container_Termina...), which I do agree with, but as far as I know the name for it wouldn't currently render anywhere in OpenRailwayMap. That's because in the international scheme of things these would be considered part of a yard (with a railway=yard operating site note to label it), not a freestanding thing. So ... to be determined?
In general on the rendering, that's very much a work in progress too, because the team that makes that happen just completely switched rendering engines a few months ago due to some software in the old stack being deprecated, and had to completely rewrite the rendering scheme as a result. There's a lot left to do on the new scheme write up, so it's hard to tell which things are intentionally not rendered, which just aren't implemented yet, and which ones are local issues that the rendering team didn't even *know* were an issue or question here (like track labelling in North America).
Chuck
OK so commuter rail yards are indeed service_stations. I'll go back and edit a few of them. Perhaps I should attempt to edit the OSM wiki page to clarify this. I did like how the "yards" seemed to stand out at higher zoom levels and had a contrasting color (brown) from all the other "operating sites." ============== It may be useful to add a tag category (not one that necessarily renders) such as railway:yard = classification (hump yards, larger flat switching yards), storage, interchange (yard where two railroads exchange traffic), local (road manifest or "regional" drops off/picks up on the way to another large yard, local freights originate here and then switch out local customers), intermodal, transload, etc.
How does one propose a tag "officially?" I mean I don't plan on going into OSM wiki and adding tags unilaterally. And I already suggested two more in my last post (defect_detector=high_car, railway:position:prefix) ====================================
I like your Interlockings draft. Definitely seems like there's a conflict in terminology. I know on the old Pennsylvania Railroad, it was only an "interlocking" if it had an onsite tower, otherwise it was a controlled point. So if I'm reading this right, an "interlocking" is a Relation that contains a signal_box (legacy tower or just an equipment enclosure), the signals, switches, AND an operating site Point which can either be a "crossover" or a "junction."
That's a little confusing since I had assumed a "junction" would be more like a named point where two lines diverged which sometimes gave it's name to the nearby town. Examples: https://en.wikipedia.org/wiki/List_of_New_Jersey_railroad_junctions and I have been adding in some of these.
Another point of confusion is that some crossovers and junctions are obvious, yet how would you describe a control point at the end of a siding where two tracks become one? Or one main track splits into two "equal" mains?
In general on the rendering, that's very much a work in progress too, because the team that makes that happen just completely switched rendering engines a few months ago due to some software in the old stack being deprecated, and had to completely rewrite the rendering scheme as a result. There's a lot left to do on the new scheme write up, so it's hard to tell which things are intentionally not rendered, which just aren't implemented yet, and which ones are local issues that the rendering team didn't even *know* were an issue or question here (like track labelling in North America).
Focusing on the last line... are you referring to the reference/name tagging or track numbering. I've noticed that the line name (subdivision/district) only appears when the ref field is filled out. EIke showed me an example in Europe where even the tunnel name appeared along with the "ref." I did see a few examples in the lines originating from Portsmouth/Norfolk, Virginia where the ref numbers were tagged on CSX and NS lines and even the line name started rendering. Of course it's nearly impossible to figure out what reference codes a US railroad uses even with an ETT.
And if there's ever a US signal tagging or documenting committee I'd be happy to participate. Reading the European-centric rules for tagging still confuses me. I still can't tell how I'd tag a US CP/"home"/interlocking signal vs. an intermediate/automatic signal. And while some roads use GCOR or NORAC, others use their own rule book
Comments interspersed below:
On Fri, Aug 21, 2020 at 11:44 AM jbittner@gmail.com wrote:
OK so commuter rail yards are indeed service_stations. I'll go back and edit a few of them. Perhaps I should attempt to edit the OSM wiki page to clarify this. I did like how the "yards" seemed to stand out at higher zoom levels and had a contrasting color (brown) from all the other "operating sites." ============== It may be useful to add a tag category (not one that necessarily renders) such as railway:yard = classification (hump yards, larger flat switching yards), storage, interchange (yard where two railroads exchange traffic), local (road manifest or "regional" drops off/picks up on the way to another large yard, local freights originate here and then switch out local customers), intermodal, transload, etc.
How does one propose a tag "officially?" I mean I don't plan on going into OSM wiki and adding tags unilaterally. And I already suggested two more in my last post (defect_detector=high_car, railway:position:prefix) ====================================
There's a tag proposal process for OpenStreetMap overall of course, but at least 90% of the OpenRailwayMap tags are generally specific to ORM and usually rendered only by ORM ... so for the most part in my limited experience, tags like what you're suggesting usually just get discussed here on the ORM mailing list that I've seen. A tag like railway:yard= won't affect anyone else in the OSM ecosystem outside ORM, so generally if there seems to be enough support from the rest of the OpenRailwayMap users on the list, we seem to just roll with it from there.
Personally, I like your railway:yard= suggestion, as this is info that would definitely be useful in the NA railroading world, at least.
I like your Interlockings draft. Definitely seems like there's a conflict in terminology. I know on the old Pennsylvania Railroad, it was only an "interlocking" if it had an onsite tower, otherwise it was a controlled point. So if I'm reading this right, an "interlocking" is a Relation that contains a signal_box (legacy tower or just an equipment enclosure), the signals, switches, AND an operating site Point which can either be a "crossover" or a "junction."
That's a little confusing since I had assumed a "junction" would be more like a named point where two lines diverged which sometimes gave it's name to the nearby town. Examples: https://en.wikipedia.org/wiki/List_of_New_Jersey_railroad_junctions and I have been adding in some of these.
Fair question. They're all controlled points either way (usually), but an interlocking is called an interlocking because there's some sort of technological system there to partly automate control of that CP and prevent "unsafe" conditions. In the case of the PRR, you would only see that at a point with a tower because for most of the PRR's existence, a physical interlocking plant (the machine inside the tower) was the only technology we had available to do that. The machinery was all human operated, but the "automation" part is the set of interlocks built into the machine that would physically prevent you from setting paths that conflicted - as in, in the case of a super simple diamond crossing with no switches, it was physically impossible to set both crossing routes clear at the same time. When you cleared the first route, a physical interlock would engage that would lock the second route lever at stop. That's what makes an interlocking an interlocking.
Now, nearly all CP's in signalled territory (especially in CTC territory) are interlockings, they are just remote controlled, and the interlocking automation is partly software based. The tower itself is no longer needed as part of the interlocking, because you don't need the physical interlocking machine it once housed, or a person to manually throw the levers.
Similarly but much less common, I've also some interlockings that aren't CP's, though definitely not so much on big mainline routes. The only ones I've personally seen have been automated diamond crossings. Several literally have a control button for each route, and you pull up to the home signal, someone has to get out and hit the button for your route on the control box, and the system will clear you through and lock out the button for the opposing route. It's like the simple junction equivalent of ABS. Still technically an interlocking by the simplest definition, but not any sort of train order control point otherwise.
But, to add to the confusion - the OpenRailwayMap tagging wiki is still stuck in 1935. The main definition of an interlocking there in the tagging scheme still implies a tower, see https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging#Interlocking. I don't know if this is more a matter of how the European railroads with the most active mapping contributors are still run, or if this is a translation issue. Regionally for North America, a remote controlled interlocking is still an interlocking, so it's still 100% appropriate to group the signals, turnouts, and label in that interlocking into an interlocking range relation (see https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging#Interlocking_rang...), that relation just wouldn't have a signal_box member. The Operating Site node (the map label point) would be included in the interlocking range relation with the "facility" role.
Definitely confusing. Took me a month of asking questions to figure that much out, because at least for NA no one had really gotten that far into trying to map to the detail level of starting to add these relations, so the question just hadn't come up.
Another point of confusion is that some crossovers and junctions are
obvious, yet how would you describe a control point at the end of a siding where two tracks become one? Or one main track splits into two "equal" mains?
That one's insanely confusing because of a translation issue, but easy once you know the non-obvious answer. That control point is railway=spur_junction. Is that a spur junction in English? Yeah, absolutely not, I'm right there with you, it's a complete mistranslation. This small part of operating site tagging is an absolute mess. But ... that's what it is, and it works right otherwise. On the main Tagging wiki page, https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging#Sidings you can see that they've given the description, "The position where a spur forks from a main line," and then every single other piece of text or description in that section clarifies that it's actually the CP at the end of a siding. So the actual CP tagging is really:
railway=junction - CP where two lines cross, OR CP where a branch line spits off (an actual spur junction) railway=crossover - CP where you can switch tracks on a multi-track main railway=spur_junction - CP at the end of a controlled siding railway=site - any CP that doesn't fit the other three (I actually do have several moving bridge CP's in my area, so their example there is actually a good fit)
That's another one of the areas I was intending to clarify on that NA Operating Sites draft I'd started but hadn't had time to finish.
In general on the rendering, that's very much a work in progress too, because the team that makes that happen just completely switched
rendering
engines a few months ago due to some software in the old stack being deprecated, and had to completely rewrite the rendering scheme as a result. There's a lot left to do on the new scheme write up, so it's
hard
to tell which things are intentionally not rendered, which just aren't implemented yet, and which ones are local issues that the rendering team didn't even *know* were an issue or question here (like track labelling
in
North America).
Focusing on the last line... are you referring to the reference/name tagging or track numbering. I've noticed that the line name (subdivision/district) only appears when the ref field is filled out. EIke showed me an example in Europe where even the tunnel name appeared along with the "ref." I did see a few examples in the lines originating from Portsmouth/Norfolk, Virginia where the ref numbers were tagged on CSX and NS lines and even the line name started rendering. Of course it's nearly impossible to figure out what reference codes a US railroad uses even with an ETT.
The ref field (aka Line Segment Numbers in the US). That one was another month worth of questions on my part to figure out, because even though they nominally exist in the US, we barely use them. My new European friends here were very confused when I first started asking, because apparently that's a very alien concept, so I ended up learning a bunch. Apparently their railroads do not actually own their railroad network ... they generally have an independent network analogous to our highway network with literal numbered routes that everyone uses, and their railroad operators are just equivalent to our trucking companies, running on tracks that someone else owns. Boy was that a bit confusing to sort out on my end. Here, operator=railroad, and route numbers are mostly superfluous even though they theoretically exist for every mainline route. You identify routes by their operator and maybe by a route name, no one uses the numbers. UP and BNSF out west seem to actually use them some, and from what I've seen at least have the line segment number for each line shown in their timetables. NS has the LS number shown in their track charts, but not timetables. CSX I've only ever been able to find them in their FRA railroad crossing inventory forms (pick a crossing and download the PDF, and usually it's right at least). A lot of the Class II and especially Class III lines in my area don't even have them in the crossing inventory forms where they're supposed to be, and honestly probably don't even know what they are for their own lines. I've got a few local lines that are absolutely like that.
As for the ones around Norfolk ... that's me! That's where I've been mapping off and on the last few months while I try to figure some of this out.
I'm still on the fence about whether the ref tag is even worth rendering here in North America. It's used so comparatively little even among the Class I's (compared to more valuable info like the operator reporting marks and subdivision name) that, in the area here that I've gone through the work to find them and enter them, so far I even find my own work to just be useless map clutter. That's something of an open question that we still need to discuss within the NA part of the ORM community. So far I've found one person who does find them useful within work he's doing, so I can't honestly say they're not useful at all.
Meanwhile, worse, they're appearing in place of the usual labelling in NA (on every other non-ORM rail map) that actually *is* useful, the reporting marks. That's another one that was a really interesting intercultural discussion, because when I first brought it up, most non-NA friends were basically wondering why we'd do the equivalent on our maps of naming a road after the trucking company that drives on it most. Nevertheless we all worked it out, and we have a promise from the gentleman who does most of the work on the renderer to help work out custom rendering rules for (at least) Canada, Mexico and the US that label properly for us (reporting marks and subdivision name) so we can get the map usable. Meanwhile, we didn't even have a reporting marks tag until a couple of months ago to use (now agreed to be operator:short=, though several of us have tagged about a thousand with reporting_marks= while we were settling on a permanent answer) so there wasn't even anything to render anyway. That's one where there's a lot of work to do to get the map readable, but it'll make a big difference for us once we do and Michael can help us get it rendered right.
And if there's ever a US signal tagging or documenting committee I'd be happy to participate. Reading the European-centric rules for tagging still confuses me. I still can't tell how I'd tag a US CP/"home"/interlocking signal vs. an intermediate/automatic signal. And while some roads use GCOR or NORAC, others use their own rule book
I don't know if any work has been done at all yet on signalling for the US. Someone had at least copied the GCOR and NORAC basic rulebook sections and images into the wiki as a starting point and we recently moved that to its own dedicated wiki page ( https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Work_Rules_in_North_Ameri...), but as far as I know no one has volunteered to lead any further effort yet. That's definitely a job looking for a volunteer to take the lead and start figuring it out, and if you're interested I suspect the rest of us in NA will be happy to nominate you to be the "regional volunteer specialist" on that part and support you however we can!
Chuck
openrailwaymap@openrailwaymap.org
-
Chuck Sanders -
jbittner＠gmail.com -
Rolf Eike Beer