Signals and Panels
The current implementation of signals is not sufficient for a practical usage. In particular, it is currently not possible to distinguish between light signals and panels/signposts showing static information. In the forum threads [http://www.railml.org/forum/ro/?group=1&id=148] and [http://www.railml.org/forum/ro/?group=1&id=149] this subject has been discussed and the following aspects are derived:
-
It is better to modify the element
signal
instead of introducing a new elementpanel
, because often combinations of switcheable and non-switcheable signals/signal elements exist. -
The element
signal
resembles a physical unit, which is situated (with orientation) next to the track and therefore contains the attributes pos, direction and optionally also the sub-elementgeoCoord
as already implemented. -
A signal may show several signal aspects, which are defined in
signalAspect
sub-elements. -
A signal aspect can be identified via its parameters id, name and code, which are inherited from the type "tElementWithIDAndName".
-
A signal aspect may be fixed (panel) or switcheable (e.g. light signal), which is modelled with the boolean parameter switcheable.
-
A signal aspect may refer to a certain functionality. It is proposed to group these funcionalities into speed, etcs, levelCrossing, gsm, catenary and signalingSystem and to refer to these groups using the parameter type.
-
A signal aspect with
type="speed"
may refer to a certain speed change on the track. For providing this reference, the parameter elementRef of type "tGenericRef" can be used.
Further attributes for signals, signal aspects or signal frames are considered to be more related to an interlocking point of view on signals and therefore momentarily discarded.
Here is a short example of a signal showing two signal aspects:
<signal id="s01" pos="42.0" type="main">
<signalAspect id="s01a01" switchable="true" type="block">
</signalAspect>
<signalAspect id="s01a02" switchable="false" type="speed" elementRef="sc01">
</signalAspect>
</signal>