| Re: [railml3] Signal types and functions [message #2141 is a reply to message #2134] |
Mon, 11 February 2019 17:24   |
Thomas Nygreen JBD
Messages: 68
Registered: February 2017
|
Member |
|
|
Dear Jörg,
Thank you for your replies, which helped me untangle some of the IS and IL issues from each other. I will therefore reply to the IL issues in the interlocking thread.
Jörg von Lingen wrote on Sat, 09 February 2019 09:32
<signalIS>@type is about the physical types of objects one will call "signal"
I agree, but the remaining <signalIS>@type values describe a small minority of signals. The remaining attribute values in IS are insufficient for describing the majority of signals. The @type values that were removed with RC2 describe signal types that are normally physically different. My first reaction was therefore that it was odd to move this physical description from IS to IL.
There are many possible ways to draw the border between IS and IL, and I am more concerned with the available modelling space as a whole and not with exactly where the border is drawn. Signals are especially tricky, as some of the physical differences we are used to are only there to make it easy to distinguish different functional types of signals. So I am reconsidering my initial reaction.
Still, we need a way to generically describe the physical type of a signal. I suggest that we fully embrace the approach of using subelements for different types of signals, and <signalConstruction>@type to categorise the physical type of signal. Consequently I also suggest to remove <signalIS>@type. The functional role of a signal is specified in IL.
Quote:
<signalIS>@switchable is a real addition to <signalConstruction>@type because there are signals of type "semaphore"
which may be switchable or not, e.g. electrification signals like "main switch off". Of course, with "light" signals one
can assume they are always switchable.
I find it hard to believe that you have semaphore signals where the arms cannot be moved to display different aspects, unless this is just a matter of the signal being out of service (disabled). Do you have a visual example of a non-switchable semaphore signal?
I think the list of types should be extended with (at least) "board", "pole" and "other:*", and maybe also "lamp" and "flag" (which are movable and therefore harder to model). Switch indicators, like semaphores, are mechanical signals, so maybe it is better to replace "semaphore" with "mechanical"? Should we also distinguish between light signals that switch colour, light signals that turn on and off, and other (positional or shaped) light signals?
Looking at railML2.4nor, there are also two attributes that I hope can be included in railML 3.1, with adjustments of the implementation if necessary: @nor:lamps (integer number of [independent] lamps a signal has) and @nor:mounted (enumerated list of possible mounts for a signal, currently "pole", "gantry" and "other:*", could also include "wall", "ground" etc.).
Suggestions:
- Create element <signalIS>/<isFoulingPoint> with reference to corresponding <switchIS> or <crossing>.
- Create element <signalIS>/<isRadioSignal> which also describes what kind of radio signal this is (i.e. what instructions it provides).
- Add optional (and repeatable?) <signalIS>/<ruleCode> (feel free to suggest better name), of type rail3:Designator.
- Add <signalConstruction>@type values "board", "pole", "lamp", "flag" and rail3:tOtherEnumerationValue. Rename "semaphore" to "mechanical".
- Add new optional attribute <signalConstruction>@numberOfLamps describing the number of individual lamps in a light signal (one lamp may consist of several bulbs for redundancy).
- Add new optional attribute <signalConstruction>@mountedOn with enumerated values "pole", "gantry", "wall", "ground" and rail3:tOtherEnumerationValue.
- Remove <signalIS>@type
Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
|
|
|
|
Members
Search
Help
Login
Home
