| Re: [railml3] Signal types and functions [message #2152 is a reply to message #2147] |
Mon, 18 February 2019 23:26   |
Thomas Nygreen JBD
Messages: 68
Registered: February 2017
|
Member |
|
|
christian.rahmig wrote on Mon, 18 February 2019 14:55
> My proposal: extend <signalConstruction>@type with value "board".
> Together with existing values "light", "semaphore" and "virtual" we
> should have a complete picture, haven't we?
I have also suggested "pole" and rail3:tOtherEnumerationValue (and "flag" and "lamp", but ignore them for now).
At least in Norway we have several signal poles (or posts), that do not have a board on them, but instead a colour pattern along the pole/post. So I still suggest to add "pole" (or "post").
I think we can ignore "flag" for now, and consider "lamp" a light signal. They are both used in Norway by local dispatchers, train staff and during maintenance. They can both be handheld, mounted in a support on the platform or in the tracks. But as they are movable, I do not know how to properly model their use. So we will probably have to continue modelling their effect virtually.
But I still strongly suggest to add rail3:tOtherEnumerationValue.
christian.rahmig wrote on Mon, 18 February 2019 14:36
> <isAnnouncementSignal>
> @type = {"whistle", "horn", ...}
> @refersToElement = {reference to level crossing, halt, etc.}
One board can refer to more than one element, so <refersToElement> should be a repeatable child element. One example is the Norwegian signal 67D which refers to both a level crossing and a halt. One level crossing announcement signal (67B) can also refer to multiple level crossings (we have lines with more than two level crossings per kilometre, on average).
> <isDangerSignal>
> Is a fouling point (clearance post) also a danger signal?
In Norway, this is signal 64A (a pole/post). In Torben's table, this signal is listed as a border signal. But this signal can be used for multiple purposes:
- end (i.e. border) of allowed shunting area outside of the outer switch in a station
- border of a stabling or maintenance yard
- clearance point between tracks
- position of track circuit activating level crossing protection
My question is: should this signal use different types depending on the use?
> <isVehicleEquipmentSignal>?
> @type = {snowplowUp, snowplowDown, ...}
Can we separate type of equipment and action? That would make it easier to categorise and to filter on all signals relevant for a given equipment kind.
Torben Brand wrote on Mon, 18 February 2019 11:26
> It is good that we have the sub element designator with
> the register + entry attributes. Thus, we can always uniquely define
> a national signal.
The way that <designator> is used on <ocp> in railML2.x is as an identifier of the element, not of the type. The parallel for a signal is something like <designator register="BaneData" entry="SA-SIG-010898"/>. That is why I suggest a separate child element like <ruleCode> (if we want to keep the name from 2.x), which uses the same structure: <ruleCode register="TJN" entry="67D"/>
I would also like to reiterate my following suggestions:
> * 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.
Also remember to create child elements for signal types we do not have in Norway. From the current @type list, at least <isRadioSignal> seems relevant.
Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
|
|
|
|
Members
Search
Help
Login
Home
