| Re: railML 2.3 infrastructure extension proposal signal types and functions [message #1515 is a reply to message #1474] |
Fri, 24 February 2017 16:16   |
Torben Brand
Messages: 158
Registered: March 2016
|
Senior Member |
|
|
Christian Rahmig wrote:
The whole topic of signalling is currently an underdeveloped field in
railML. Considering the upcoming railML interlocking topics, railML
infrastructure scheme needs to react on the requirements from
interlocking and extend the signal model. This will be part of railML v3
and need to be discussed in detail with the community. For railML v2.3
the key attributes for specifying a signal are - as you correctly
identified - <signal>@type and <signal>@function.
My reply:
Agreed, we continue to use <signal>@type and <signal>@function in railML2 and use it in railML3. The structure is also used in OpenStreetMap.
I suggest to extend the attribute <signal>@type following the ideas of
OpenStreetMap (see [1] .
Except for the proposed "road" this list looks quite exhaustive to me.
Do you miss any type of signal?
I miss, in the OSM list, my proposed signal types (see original posting for explanation): danger, derailer, switch and main level crossing. The signal type I suggested "road" is contained in OSM type "crossing" ("A signal that indicates that the technical equipment (lights, barriers, bells) of a level crossing is active to warn automobile drivers about an approaching train.") The type distant level crossing is contained in OSM type "crossing_distant". Interestingly it refers to a "level signal" that is not contained in the OSM type list ("A signal which notifies the train driver to attend a level signal which will follow."). OSM should thus be extended with signal type "crossing_main".
Is there plans for compatibility between OSM signal types and railML3? What about their use of underscore as a separator? In railML2 upper-case letters are used as separators.
The proposed values [<signal>@function "area" and "levelCrossing"] don't seem to be functions, but types.
I agree that the suggested values should be types and not functions.
These two types of signals [sub elements <NO:forsiktigKjøring> and <NO:middelkontrolllampe>]seem to be very specific. What kind of signal
features do you need in order to have this type of signal modelled as
sub element? Alternatively, if you do not want to define the signal in
detail, you could model them via the parameter <signal>@type if it
allows to have an other enumeration value ("any enumeration value").
I used sub-elements as these signals belong to a main signal. Just as the existing sub-element "line signal" (XSD:"sub-element for defining a line signal or panel"). I understand now that I misunderstood. The sub-elements are used to describe a signal (type) further, not to attach another signal to a main signal. I will change my extension to using signal types (with the same absPos as the main signal).
Well summarized. We should try to model the common ground in railML, but leave the possibility for country specific signals.
I suggest, based on the feedback, to change my suggested extension for signal to:
<signal>@type"other:danger" https://lovdata.no/forskrift/2008-02-29-240/9-30
<signal>@type"other:derailer" https://lovdata.no/forskrift/2008-02-29-240/9-27
<signal>@type"other:switch" https://lovdata.no/forskrift/2008-02-29-240/9-25
<signal>@type"other:crossingMain" https://lovdata.no/forskrift/2008-02-29-240/9-28
<signal>@type"other:crossingDistant" https://lovdata.no/forskrift/2008-02-29-240/9-29
<signal>@type"other:crossingRoad" https://trv.jbv.no/wiki/Signal/Prosjektering/Veisikringsanle gg#Signal_mot_vei_3
<signal>@type"other:shuntingArea" https://lovdata.no/forskrift/2008-02-29-240/9-22
<signal>@type"other:slowSpeed" https://lovdata.no/forskrift/2008-02-29-240/9-19
<signal>@type"other:clearedFouling" https://lovdata.no/forskrift/2008-02-29-240/9-19
<signal>@type"other:line" https://lovdata.no/forskrift/2008-02-29-240/9-20
<signal>@type"other:deflectingSpeed" https://lovdata.no/forskrift/2008-02-29-240/9-24
Short explanation:
"shuntingArea" is placed on a main exit signal. Is used for a shunting area instead of a shunting signal that is used for a shunting route.
"slowSpeed" is placed on a main home or intermediate signal. Is used for routes ending in a buffer stop or for shortened routes.
"clearedFouling" is placed on a main exit signal. The signal indicates when the last axel has passed the fouling point.
"line" is placed on a main exit signal. Is used to indicate which line the set route applies to.
"deflectingSpeed" is placed on a main home signal. Is used to indicate the deflecting speed for the applied route. The speed value itself will be described in the existing sub-element <SignalSpeed> referring to a speed change.
<signal>@function I leave as it is in railML 2.3.
I agree that we can change the following values in railML3 (but not so important for me):
railML2 :
<signal>@function"home"
<signal>@function"blocking"
RailML3/OSM:
<signal>@function"entry"
<signal>@function"block"
The "track indicator" signal is very Norwegian specific. I suggest instead to describe it as a variant of a repeater signal with sub-element use:
<signal>@type"repeater"@function"exit"
<NO:togsporsignal>
|
|
|
|
Members
Search
Help
Login
Home
