Proposal:Railway Signals

Railway Signals
Proposal status:	Obsoleted (inactive)
Proposed by:	Michael2402
Tagging:	railway=signal Data item
Statistics:
Draft started:	2011-08-27

Motivation

Whit this proposal I propose a common tagging scheme 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.

Proposal

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 direction 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 (normal 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 some more 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 with 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-dependent	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-dependent. 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 centre 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 coming.
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 omitted 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 with 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?)

Members:

Way or node	Role	Recurrence?	Discussion
	signal	1	The signal this relation belongs to
	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.
	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.
	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.

Examples

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

What this proposal does not cover

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

Discussion

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.

Maybe 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[sic] tagging of signals. I think this proposal is in a way replaced by the OpenRailwayMap tagging because it is better for a detailled[sic] tagging, whereas this proposal is only good for a very general tagging. --rurseekatze 11:33, 4 August 2012 (BST)