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)
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 previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior 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


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
 
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: railML 3.x - NTSM use case organisational/contact data
Next Topic: railML 2.3 infrastructure extension proposal - locks
Goto Forum:
  


Current Time: Sat May 04 20:40:58 CEST 2024