User:UrbanUnPlanner/North American Signal Tagging

The tagging scheme for signals and signs described in OpenRailwayMap/Tagging/Signal and Tag:railway=signal appears to be based on continental European (German?) signaling schemes and thus does not translate directly to North American signaling practice (this is similar to the situation described in User:Nathhad/Operating Sites and Interlockings with regards to the broader incorporation of signals, switches, and other devices on the railway into interlockings, control points, and other types of operating sites). As a result of this, and the lack of a defined scheme, most signal tagging in the US that is present is quite minimal, and signals in the US are not rendered on OpenRailwayMap even when present and tagged. This document is intended to present a basic framework for tagging North American rail signals that meshes with the existing tagging scheme as best as possible, so as to not confuse international users.

Sourcing signal information

Unlike some areas, where information about railway signaling layouts is widely or even publically available, North American signaling information is generally only documented for the internal use of the operator(s) on the line, and thus not generally openly available for use on OpenRailwayMap. That said, some things can be deduced from aerial, or if lucky, street-level imagery:

• Aerial images will show the presence of a signal mast or gantry, and good quality ones will provide enough detail to make out individual heads, although you will need to rely on the shadow of the signal against the ground to do so in overhead shots. While this doesn't provide precise location details, or aspect information, it is sufficient to tag most other things on a full-height signal (function, form, height, and facing/positioning).
• Some signals are located near enough to grade crossings or otherwise public roads that they are clearly visible from street-level imagery. This is a major boon for block (intermediate) signals in particular, since the number plate on the signal mast provides the Key:ref for the signal, and oftentimes this reference can be readily translated into the signal's milepost location (Key:railway:position) as well. Absolute signals at control points and other interlockings, as well as distant signals in otherwise non-signaled territory, are less fortunate cases where street-level imagery adds little to what can be tagged from aerial shots, though, and this still is insufficient to determine the full set of aspects for the signal.
• Signs (aside from mileposts, where the FRA provides sufficient data to place many of them in conjunction with good quality aerial imagery) will require street level imagery to tag/map. As a result, the tagging of wayside signs should focus on areas where signs are unusual or present at a significant density (mostly terminal areas), as well as on lines where speed restriction signage is critical (such as mountain grade railways), although the latter is more difficult.

The proposed tagging scheme

The scheme proposed here adapts the basic OpenRailwayMap signal tagging scheme to better handle North American signals. In particular:

• ref= is the value on the number plate for an intermediate signal when available from documentation or street-level imagery, and should be left blank if not otherwise available from usable internal documentation. Also note that it is possible for a railway to have multiple internal designations for a given signal: the signal engineers may call it one thing, the train protection (Positive Train Control) data may call it another thing, a dispatcher or Rail Traffic Controller (American for "signaler") may call it something else, and the train crew in the field may call it a different name yet. FIXME: if an operator has multiple designations for the same object in their official documents, which one takes priority?
• railway:position=, railway:signal:position=, andrailway:signal:direction= work as they do in the rest of the world.
• The first major divergence from international practice in North America is that we generally don't use subsidiary signals to govern non-primary movements at a given location. This means that most signals in North America are main signals (FIXME: should we be using combined instead of main, given that interlocking signals are integrated with the block signaling on the line just about everywhere in North America?), and the only other type that you'd find used for a signal is distant on signals that provide the distant signal function at the boundary between signalled and non-signalled ("dark") territory. Signs, and sign-like indicators such as those that indicate the status of wayside horn systems to the traincrew, can use other types, though. (FIXME: points indicators can be found on non-resetting points in North America, and there are other North American peculiarities such as blue flags/signals out there, how do we want to handle these?)
• The second major divergence from international practice that we have to accommodate is that one may see multiple kinds of light signal in North America, even if one is operating under the same workrules the whole time! In particular, NORAC accommodates four different light signaling schemes: color light (each lens produces one color), searchlight (all colors from the same lens), and two setups that use multiple lights in different fashions, namely PRR (mostly Amtrak now) position lights (which became position color lights) and B&O (became CSX) color position lights. (FIXME: do we want to go into this level of detail, or should these all be tagged as form=light? Is this a job for signal shape, even?) Other railroads may only have one form (generally color light), or a mix of color light and searchlight signals (as described in the GCOR).
• Signal heights, fortunately, can simply be accommodated using dwarf or normal, as described in the general scheme. Unless you have street-level imagery or very high-quality aerials available, though, it is unlikely you'll be able to document the presence of dwarf signals in an area.
• Signal states are not discussed here as they'd have to be mapped from the internal documentation, as discussed above. Were one to have this data, though, it could be mapped as described in the general scheme, although a consensus would be needed as to how to refer to aspects (by name? by work rule?) if we were to map this data, and some signals display "custom" aspects that differ from the norm for a given railroad or area.
• Finally, we come to signal function, which is the third place we diverge from the normal tagging scheme. Unlike the standard tagging scheme, there are many places in North America where the terms "entry signal" and "exit signal" have no meaning at all, and even if they could be reasonably assigned a meaning, such phrasing is not used in North American practice. Currently, absolute (interlocking) signals are tagged as function=entry/protection, but this is tentative until a better definition can be found. (FIXME: do we want to stick with the current practice, treat all absolute signals as either entry signals or protection signals, come up with a more-meaningful-in-North-America value such as absolute or home for this field, or try our best to assign entry and exit signals, along with a separate type for signals where lines diverge or cross in the absence of passing sidings?) Likewise, current practice is to tag block signals as function=intermediate, but that's because North American practice calls them "intermediate" signals instead of "block" signals, so should we be tagging these as function=block instead?

Tagging wayside signs

The other type of "signal" in the OpenRailwayMap scheme that is common enough in North America to handle here is the mapping of signs. While this requires street-level imagery, as discussed above, this can be useful in areas where speeds or working rules change frequently, or when the meaning of other wayside signs is non-obvious (such as with whistle posts in and around some quiet zones). These are always tagged with a form=sign (FIXME: heights tagging with multiple signs on the same board?), but they use a type corresponding to what kind of sign they are:

• The first kind of sign are speed (limit) signs/boards -- these use the speed_limit type, prefixed with the name of the working rulebook involved (GCOR, NORAC, or CROR), or the name of the operator (NS, CSX, VTA, NYCTA, and so on) if the operator uses a non-standard rulebook or it is not known what rulebook the operator uses (LRT systems may not use a standard set of "railroad rules", and heavy rail transit systems will have their own, unique, rulebooks). The speed can be specified using the standard tagging for such, although generally speaking, the value on a speed limit board in North America will be in MPH. Finally, the caption should be set to the actual text of the sign, including any prefixes or other markers that determine what class of train the speed applies to.
• The second kind of sign that is covered in this scheme are working rules signs. These use a category of workrules, and also use the same rulebook/operator prefix scheme and caption tagging as before, although attached to a designation for the specific rule that's begins or ends at the sign instead of a generic workrules. Note that most workrules signs in North America are double-sided signs, with separate captions for the forward and backward directions, as well as tags for workrules:begin and workrules:end. (FIXME: designate workrules by what they are on the sign, or by a citation into a rulebook, or...?)
• Finally, we get to whistle posts. These can be marked using the whistle category, with a caption that's either W for a standalone whistle post, or X for a whistle post for a crossing, along with any modifiers for multiple crossings, quiet zones, or such. Note that North American quiet zone crossings still have whistle posts: these will have a designator (such as the letters "QZ", or a red prohibition circle-and-slash over a W) on them to distinguish them from regular whistle posts, and should be tagged using crossing:horn=optional in addition to having a distinct caption value.