Home » railML newsgroups » railml.infrastructure » railML 2.3 infrastructure extension proposal signal types and functions (railML 2.3 infrastructure extension proposal signal types and functions)
railML 2.3 infrastructure extension proposal signal types and functions [message #1461] Tue, 20 December 2016 18:34 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 20
Registered: March 2016
Junior Member
Dear railML infrastructure forum,
This posting contains the discussion to an extension towards the
signal
We need to model all relevant signals to the use case according to Norwegian law ( https://lovdata.no/dokument/SF/forskrift/2008-02-29-240/KAPI TTEL_9#KAPITTEL_9Wink.
This is done through extending the type (5 new values) and function (2 new values) attributes. The defined combination of type and function form the specific signals in Norway, but are considered universal. So the terms are in English.
There are two Norwegian specific signals that are part of a type main signal and are thus defined in new sub elements under signal in Norwegian.
The new values for the attribute @type under element <signal> are:
• "danger"
Used in Norway for signals that indicate that an avalanche fence has been broken. We chose a more generic description for warning signs in general. Other examples that fit the specification could be: cross wind signals. If there is a need to further distinguishes a type of danger signal I suggest using a later added sub element or extended value range of function.
• "derailer"
Indicates if the derailer has blocked the track.
• "switch"
Indicates the position of the switch.
• "trackIndicator"
Repeats (only) to the conductor the state of the main-exit signal. This is a different signal than a type repeater signal (that is valid for the train driver).
• "road"
Road side signals not valid for the train driver. But contained in schematic drawings.
The new values for the attribute @function under element <signal> are:
• "area"
Signals that are valid for a (undisclosed) area and not a signal route.
• "levelCrossing"
Defines either a type main/distant/road. Further attributes to be found in existing sub element <levelCrossing>
The new sub elements under element <signal> are:
• <NO:forsiktigKjøring>
Sub signal under type main and function home or intermediate. Used for shortened signal routes or dead end tracks.
• <NO:middelkontrolllampe>
Sub signal under type main and function exit or intermediate to indicate that the train is within the clearance point.
Re: railML 2.3 infrastructure extension proposal signal types and functions [message #1474 is a reply to message #1461] Mon, 16 January 2017 12:44 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 44
Registered: January 2016
Member
Dear Torben!

Am 20.12.2016 um 18:34 schrieb Torben Brand:
> [...]
> signal
> We need to model all relevant signals to the use case
> according to Norwegian law
> ( https://lovdata.no/dokument/SF/forskrift/2008-02-29-240/KAPI TTEL_9#KAPITTEL_9).
>
> This is done through extending the type (5 new values) and
> function (2 new values) attributes. The defined combination
> of type and function form the specific signals in Norway,
> but are considered universal. So the terms are in English.
> There are two Norwegian specific signals that are part of a
> type main signal and are thus defined in new sub elements
> under signal in Norwegian.

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.

> The new values for the attribute @type under element
> <signal> are:
> • "danger"
> [...]
> • "derailer"
> [...]
> • "switch"
> [...]
> • "trackIndicator"
> [...]
> • "road"
> [...]

I suggest to extend the attribute <signal>@type following the ideas of
OpenStreetMap (see [1]). In particular, @type may have the following values:

* main
* main_repeated
* distant
* minor
* minor_distant
* combined
* shunting
* crossing (or levelCrossing)
* crossing_distant (or levelCrossing_distant)
* crossing_info (or levelCrossing_info)
* crossing_hint (or levelCrossing_hint)
* electricity
* humping
* speed_limit
* speed_limit_distant
* whistle
* ring
* route
* route_distant
* wrong_road
* stop
* stop_demand
* station_distant
* radio
* departure
* resetting_switch
* resetting_switch_distant
* snowplow
* short_route
* fouling_point
* train_protection
* ##(other)

Except for the proposed "road" this list looks quite exhaustive to me.
Do you miss any type of signal?

> The new values for the attribute
> @function under element
> <signal> are:
> • "area"
> [...]
> • "levelCrossing"
> [...]

The proposed values don't seem to be functions, but types. Do you find
them in the previous list? For the attribute @function, I suggest to
adapt the list of possible values to the tagging proposal of
OpenStreetMap (see [1]). In particular, OSM distinguishes between the
following signal functions:

* entry (instead of home)
* exit
* block (instead of blocking)
* intermediate

> The new sub elements under element <signal> are:
> • <NO:forsiktigKjøring>
> [...]
> • <NO:middelkontrolllampe>
> [...]
>

These two types of signals 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").

To summarize: signalling remains a very country-specific topic. With the
attributes @type and @function, railML infrastructure provides the
possibility of having a basic generalized approach. By keeping the
enumeration of @type open (by using an other enumeration value), the
model remains open for any specific extensions. <signal> sub elements
shall only be used if detailed attributes of the signals have to be defined.

[1] http://wiki.openstreetmap.org/wiki/Tag:railway%3Dsignal

Any comments or questions are 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
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 Go to previous message
Torben Brand is currently offline  Torben Brand
Messages: 20
Registered: March 2016
Junior 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]Wink.
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>

Previous Topic: railML 2.3 infrastructure extension proposal tunnel resistance factor
Next Topic: railML 2.3 infrastructure extension proposal - controller
Goto Forum:
  


Current Time: Mon May 01 08:13:24 CEST 2017