Proposed features/Railway Signals

From OpenStreetMap Wiki
Jump to: navigation, search
Railway Signals
Status: Obsoleted (inactive)
Proposed by: Michael2402
Tagging: railway=signal
Drafted on: 2011-08-27


Whit this proposal I propose a common tagging sheme for railway signals.

railway=signal for nodes has been proposed with Proposed features/Railway, they also introduces ref=*

I know this is special, but on the other hand OSM is a good base for railway simulations, railway maps, and other railway stuff, so railway-interested people want to add this information to the map to use it later on or draw special maps. For this, there should be a common way to map it.


This proposal may contain old information and needs to be updated.

For current ideas see DE:OpenRailwayMap.

I propose this practice to allow mappers to include a usable signal mapping convention. Signals for railways are also signs on the side of the track that cannot change state.

Mapping signals

There are two ways to map a signal:

  • Place the signal on the way it belongs to. The signal is assumed to be standing on the default side of the track (right/left) and pointing in the direciton of the track. There is no relation needed. This is good for most default cases.
  • Place the signal next to the track, at the position it is standing (normaly 1,5..2m from the middle of the track). The signal has a relation to the track it is for which states the direction it is pointing at.

For most renderers, the positioning is not important, since the positions are close enough together. But for visualization or building maps for train simulation programs, it is important to know which direction the signal is facing and where it is standing.

The railway=signal node

All signals should be a node with railway=signal, which may have somemore attributes:

Key Value Description
ref * The number of the signal. It is usually written on the signal. Also covered by Proposed features/Railway
signal:purpose main A normal signal. It makes the train stop or drive like a traffic light.

Default form: light.
In Germany the HP signal, Sh signal and most tram signals.

signal:purpose distance/approach A distance signal (BE) or approach signal (AE) that displays the state of the next main signal. In the relation, the next signal should be added with a "for"-role

Default form: light.
In Germany, the Vr-signal or the so called Fahrtanzeiger.

signal:purpose combined A main signal that also displays the next signal state.

Default form: light.

signal:purpose crossing A special signal that states if the traffic lights for the level crossing have been activated and the train may pass that crossing

Default form: light.

signal:purpose direction A Signal that displays the direction the train will drive.
For trams, this is normally just a light with < and >, for railways, it is a Sign with a letter on it (Zs2) and also the sign next to the junction.

Default form: light.

signal:purpose whistle A whistle sign

Default form: sign.

signal:purpose speed_limit The signal only sets a speed limit. If it does other things, do not use this but the other value.

Default form: sign.

signal:purpose speed_limit_advance A speed limit sign will come

Default form: sign.

signal:purpose stop Stop here. In Germany a white sign wiht a H on it. For trams, sometimes a white line on the ground. The stop can be added with a for-role

Default form: sign.

signal:purpose station_advance A station will come, start to break here.

Default form: sign.

signal:exact_type country-dependend The official type of the signal for that country.
For Germany, this could be hp, vr, ks, tram (for tram signals) and others.
signal:states a list A List of possible states, they are country-dependend. All possible signal states should be mapped (which can be seen by the lights the signal has).
For Germany e.g.: hp0, hp1, hp2, ...
signal:form or semaphore A signal that uses mechanical elements to display it's state.
signal:form:semaphore yes
signal:form or light A signal that uses lamps
signal:form:light yes
signal:form or sign A normal sign that cannot change state.
signal:form:sign yes
signal:height normal | height in meters of center of main signal The height of the signal. low and normal depends on exact_type
signal:deactivated yes, no States that the signal is deactivated. In germany, marked by a white cross.
signal:speed_limit yes|unknown|speed The signal gives a speed limit. Use unknown, if the actual value is unknown, end if it is an end-of-speed-limit sign (normally with temporary=yes), and use yes if it is a dynamic speed signal. Otherwise, use the speed in km/h. You should also note a value if it is not displayed but given by a previous sign (in Germany, when a speed limit starts with an A sign)
signal:speed_limit:temporary no Set this to yes if it is a temporary speed limit.
signal:speed_limit:form see signal:form the form of the signal.
signal:speed_limit_advance like speed limit The signal states that there is a speed limit comming.
signal:speed_limit_advance:form like speed limit the form of the signal.
signal:speed_limit_advance:temporary no Set this to yes if it is a temporary speed limit.

The form tag may be ommitted for signals where the form is given by the type.

The signals may be placed on the track or beside the track. If they are paced beside the track, they must be in a relation whith the track.

See also: [[1]] Thanks to rurseekatze for his many hints and ideas.

German signals

These are some common German signals.

signal:purpose exact_type states form Description
main hp or hp_block¹ hp0, hp1 light A Hp light signal that is used for blocks on the tracks.
main hp or hp_leafe¹ hp0, hp1, hp2, sh2 light A hp signal that is used inside stations.

¹It has to be discussed if the exact shape of the signal lights are defined by the states the signal may have or by the exact_type-tag.

See: [[2]].

The signal relation

A signal is not just standing there, it has a special meaning and belongs to a track. Therefore, for each signal there is a signal relation.

The relation has only one key: type=signal (or type=signaling?)


Way or Node Role Recurrence? Discussion
Node signal 1 The signal this relation belongs to
Way track:forward or track:backward 1 The track segment which is protected by the signal (i.e. the track "behind" the signal which can only be entered when the signal is cleared). This also indicates in which direction the signal aspect is visible: set track:forward if the signal aspect applies when travelling in the direction of the way, or track:backward otherwise.
Node for 0 or more, depending on type. The thing which is protected by the signal. For example, a signal could protect a level crossing, an approach signal "protects" a main signal, or an exit signal protects several points/switches. For normal (block) signals, this role can be omitted.
Node track_position 0-1 The position on the track that defines where the signal is positioned. The node must be placed on the track. If there is no node with this role, the signal is assumed to be for the closest point on the track to the signal.


There are a lot of different railway signals. Since I live in Germany, I mostly know German signals, but also some other european signaling system.

What this proposal does not cover

  • Speed limit mapping for railway tracks.
  • Dynamic signaling systems that do not have visible signals


Feel free to discuss this page, or just edit it.

I know that many names could be better, but I have no better Ideas, so feel free to suggest tags/values.

Maby it would also be possible to remove the advance.signals and just add an advance-tag and a advance-role to the signal relation.

Sorry for the probably many English mistakes, since I am not a native speaker.

I just realized that the proposal at DE:OpenRailwayMap (in German) is also focused on German infrastructure. It seems that that proposal is much more extensive and evaluated, and it is not only focused on signals but railway infrastructure in general. --Rohieb 17:07, 3 August 2012 (BST)

You're right, the tagging proposal of the OpenRailwayMap contains more aspects of the railway infrastructure and offers a more detailled tagging of signals. I think this proposal is in a way replaced by the OpenRailwayMap tagging because it is better for a detailled tagging, whereas this proposal is only good for a very general tagging. --rurseekatze 11:33, 4 August 2012 (BST)