| [railml3] Signal types and functions [message #2131] |
Fri, 08 February 2019 20:38  |
Thomas Nygreen JBD
Messages: 68
Registered: February 2017
|
Member |
|
|
Dear all,
Note that this post also concerns IL.
In railML3.1rc2 <signalIS>@type values overlapping with <signalIL>@signalFunction have been removed. While I agree that the enumeration lists for these (and other parallel properties in IS and IL) should not overlap, I think that the issue runs deeper in this case.
The remaining values for <signalIS>@type are
- "foulingPoint": a fouling point that marks the begin of an intersection of different tracks' loading gauges
- "departure": A signal indicating that a passenger train is ready to leave the station.
- "snowplow": a snowplow signal
- "stop": In general, this sign marks a position on a track, where a train needs to stop. In most cases it indicates the position where a passenger train should stop at a platform (stopPost). On branch lines with simplified operational rules, this signal may also be used to mark a position where a train has to stop to wait for a permission to proceed. Made redundant by <isStopPost>.
- "levelCrossing": a level crossing signal Made redundant by <isLevelCrossingSignal>.
- "electricity": A sign/board for electric locomotives indicating when and where the pantograph or other collector needs to be lowered. Made redundant by <isCatenarySignal>.
- "radio": A sign/board providing instructions on train radio usage.
- "speed": a speed sign/board Made redundant by <isSpeedSignal>.
The remaining values for <signalIS>@type seem quite arbitrary and oddly specific while still missing information necessary for a meaningful interpretation. My best suggestion is to replace the attribute with a structured variant of the 2.x @ruleCode (<designator>?), and create further isXXX where necessary.
The values for <signalIL>@signalFunction (which should be shortened to @function to avoid repeating the element name, or renamed to @type) are:
- "main"
- "repeater"
- "distant"
- "shunting"
- "barrage"
- "block"
- "junction"
- "exit"
- "intermediateStop"
- "intermediate"
- "entry"
This list mixes two separate sets of values, as one signal can be for instance a main exit signal. While "main", "repeater", "distant" and "shunting" are hierarchical types of signals, "block", "exit", "intermediate" and "entry" describe the role or function of a (main) signal (in a route). (I am not familiar with the three remaining values.) The first set of values should be assigned to a separate attribute. Since these are normally physically different signal types, maybe they also belong in IS?
Furthermore, <signalIS>@virtual was moved to a new enumeration value in <signalIS>/<signalConstruction>@type (with values "virtual", "semaphore" and "light"), but there is also still a <signalIL>@isVirtual attribute. So one of these is probably still redundant.
Additionally, <signalIS>@switchable is also related to <signalConstruction>@type as it is "set TRUE if the signal is able to show several signal aspects, set FALSE if the signal is a static panel that always shows the same signal aspect" (my emphasis). To me it seems even more logical to include "board" than "virtual" in the list, and consequently remove @switchable.
Lastly, according to the annotation on <signalIL>@isVirtual "boards that are not wired to the interlocking can be labelled virtual." As virtual means "not physically existing", an actual board is not virtual. If the attribute is supposed to specify if the signal is wired to the interlocking or not the attribute should be renamed. Alternatively a new attribute can be added, or the information can be determined from the properties of the referenced <signalIS>.
Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
|
|
|
|
Members
Search
Help
Login
Home
