| Re: [railml3] Signal types and functions [message #2138 is a reply to message #2131] |
Mon, 11 February 2019 15:51   |
christian.rahmig
Messages: 436
Registered: January 2016
|
Senior Member |
|
|
Dear Thomas,
dear all,
Am 08.02.2019 um 20:38 schrieb Thomas Nygreen:
> [...] 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>.
You are right, there is some kind of redundancy. The idea was to provide
the information on two levels:
- high level (only one word): using attribute <signalIS>@type
- detailed level: using child element <signalIS><is*Signal>
Depending on the requirements resulting from the use case, the
information about the signal shall be modelled either in one way or the
other.
> 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.
Yes, <signalIS>@type is far away from being complete. But the list can
be extended due to the "otherEnumerationValue" extension. Apart from
this, a @ruleCode may be a good solution that can be integrated into the
<designator> element.
> [...] 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.
As Jörg already wrote: we used two different definition of "virtual".
Therefore, we decided to remove the IS based "virtual" (a signal is not
physically present outside at the track) and put it into the
<signalConstruction> child element.
> 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.
"board" can be considered as a new value for
<signalIS><signalConstruction>@type. It will be defined as a
"non-switchable semaphore signal". The enumeration value "semaphore"
would be used for switchable semaphore signals. Are there any examples
for non-switchable virtual signals?
Any feedback is highly appreciated...
Best regards
Christian
--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
