| Signal characteristics (de: Signaleigenschaften) [message #1705] |
Tue, 13 February 2018 09:52  |
christian.rahmig
Messages: 474
Registered: January 2016
|
Senior Member |
|
|
Dear friends of railML,
the element <signal> currently owns an attribute @sigSystem of type
xs:string. Since it is not described in the railML wiki (see [1]), using
of this attribute is quite unclear.
Q1: Do you use <signal>@sigSystem in your application / railML interface?
Q2: If so, how do you use it? Which values do you fill there?
It is the aim of railML.org to clarify and document the usage of this
attribute with the upcoming version 2.4. Therefore, the ticket #162 (see
[2]) has been re-animated.
Any feedback is highly appreciated...
[1] http://wiki.railml.org/index.php?title=IS:signal
[2] https://trac.railml.org/ticket/162
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
|
|
|
|
| Re: Signal characteristics (de: Signaleigenschaften) [message #1717 is a reply to message #1705] |
Mon, 12 March 2018 13:28  |
Tobias Bregulla
Messages: 20
Registered: June 2017
|
Junior Member |
|
|
Hello Christian,
we do not use <signal>@sigSystem in our exports as we find a modelling
way to have the same meaning by using <signal>@ruleCode. Last week we
filled some examples for speed signals and signals in the corresponding
Wiki page (see http://wiki.railml.org/index.php?title=IS:signal) with
OUR way of modelling. I think that this is far away from being perfect
but we are expecting a more granular modelling from railML 3.x IS & IL
work. I expect good results from the communities work in these use cases
than in railML 2.x.
By the way, what about:
- <signal>@maskableRoute,
- <signal>@maskableATC,
- <signal>@sight and
- <signal>@distNearestDangerPoint?
These elements are neither well documented in the Wiki than clear from
the semantics. It seems that there are also a lot of dependencies to a
IL scheme which does not exists in railML 2.x for now.
On our part, we have no objections to a statement as DEPRECATED as of
railML 2.4 to these five attributes. We prefer more a clear railML
scheme than a wide, but unclear and undocumented scheme.
Best regards,
Tobias Bregulla
Bahnkonzept Dresden/Germany
Am 13.02.2018 um 09:52 schrieb Christian Rahmig:
> Dear friends of railML,
>
> the element <signal> currently owns an attribute @sigSystem of type
> xs:string. Since it is not described in the railML wiki (see [1]), using
> of this attribute is quite unclear.
>
> Q1: Do you use <signal>@sigSystem in your application / railML interface?
>
> Q2: If so, how do you use it? Which values do you fill there?
>
> It is the aim of railML.org to clarify and document the usage of this
> attribute with the upcoming version 2.4. Therefore, the ticket #162 (see
> [2]) has been re-animated.
>
> Any feedback is highly appreciated...
>
> [1] http://wiki.railml.org/index.php?title=IS:signal
> [2] https://trac.railml.org/ticket/162
>
> Best regards
> Christian
|
|
|
|
| Re: Signal characteristics (de: Signaleigenschaften) [message #1719 is a reply to message #1717] |
Mon, 12 March 2018 15:23 |
christian.rahmig
Messages: 474
Registered: January 2016
|
Senior Member |
|
|
Dear Tobias,
Am 12.03.2018 um 13:28 schrieb Tobias Bregulla:
> Hello Christian,
>
> we do not use <signal>@sigSystem in our exports as we find a modelling
> way to have the same meaning by using <signal>@ruleCode. Last week we
> filled some examples for speed signals and signals in the corresponding
> Wiki page (see http://wiki.railml.org/index.php?title=IS:signal) with
> OUR way of modelling. I think that this is far away from being perfect
> but we are expecting a more granular modelling from railML 3.x IS & IL
> work. I expect good results from the communities work in these use cases
> than in railML 2.x.
Thank you for this feedback and for adding these valuable examples in
the wiki!
> By the way, what about:
> - <signal>@maskableRoute,
> - <signal>@maskableATC,
> - <signal>@sight and
> - <signal>@distNearestDangerPoint?
>
> These elements are neither well documented in the Wiki than clear from
> the semantics. It seems that there are also a lot of dependencies to a
> IL scheme which does not exists in railML 2.x for now.
I created a Trac ticket based on your input [1]. If there are no
objections from the railML community, the mentioned attributes are going
to be marked DEPRECATED with railML 2.4.
[1] https://trac.railml.org/ticket/322
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
|
|
|
|
| Re: Signal characteristics (de: Signaleigenschaften) [message #1764 is a reply to message #1719] |
Sat, 14 April 2018 15:34 |
Torben Brand
Messages: 165
Registered: March 2016
|
Senior Member |
|
|
We use <signal @sigSystem> in Norway in railML2.3nor for our use case SCTP and capacity planning.
This to indicate if the signal is a conventional signal with lamps or if it is a markerboard. So in Norway we use only the two values "ETCS" or "conventional".
Alternatively we could use the presences of the <ETCS> subelement. For markerboards and the absence of the sub element to indicate conventional signalling.
Please note that my forum posting from august 2017 concerning the correct distincion between conventional signals and markerboards has never been answered. https://www.railml.org/forum/index.php?t=msg&goto=1627&a mp;a mp;&srch=marker+board#msg_1627
<signal @sight>
We do not use this in our use cases. But I know that Bane NOR will need to map the sight distance towards a signal in railML2.3nor for the use case signal planning.
[Updated on: Sat, 14 April 2018 15:35] Report message to a moderator |
|
|
|
| Re: Signal characteristics (de: Signaleigenschaften) [message #1817 is a reply to message #1764] |
Wed, 30 May 2018 15:42 |
christian.rahmig
Messages: 474
Registered: January 2016
|
Senior Member |
|
|
Dear Torben,
thank you for your feedback. So, you seem to be the first one to use the
attribute <signal>@sigSystem. Congratulations ;-)
OK, for the purpose of distinguishing between conventional signals and
ETCS marker boards, it is suggested to make use of the sub-element
<signal><etcs>. In particular, use
<signal ...>
<etcs switchable="false" .../>
</signal>
for modelling an ETCS markerboard, and use
<signal type="main" ...>
</signal>
for modelling a conventional main signal.
What do you think about that solution?
Am 14.04.2018 um 15:34 schrieb Torben Brand:
> [...]
> <signal @sight>
> We do not use this in our use cases. But I know that Bane
> NOR will need to map the sight distance towards a signal in
> railML2.3nor for the use case signal planning.
I suggest to discuss with the interlocking community whether signal
sight shall be considered as a single value in signal related
interlocking information or whether it is necessary to have this signal
sight mapped to the railway network, e.g. as an area.
Anybody else being interested in <signal>@sight or its content?
Thanks and 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
|
|
|
|
| Re: Signal characteristics (de: Signaleigenschaften) [message #1880 is a reply to message #1817] |
Sat, 14 July 2018 17:40 |
Torben Brand
Messages: 165
Registered: March 2016
|
Senior Member |
|
|
signal@sigSystem="simplified" (older generation signalling systems still in use)
We have found a new use for the suggested deprecated attribute signal@sigSystem.
We use it for old systems that are still in use, but are not according to current standard. Thus we can use the existing @types and declare in sigSystem that they are of an older and more simple generation. This applies in Norway for "enkelt inkjørsignal" and "togsporsignal". Their modern equivalent would be type=main & function=home and type=repeater & function=exit. We initially planned to map these older signals with using these values and modifying the signals into old ones with usage of a Norwegian extension sub-eleemnt under signal. Using the sigSystem with value "simplified" makes it much cleaner. I have heard that there are also different generation of signals in Switzerland. Maybe this is also something for them? Or do you just use additional "other:" signal types for the old signals?
|
|
|
|
Members
Search
Help
Login
Home
