Home » railML newsgroups » railml.interlocking » Re: Signal characteristics
Re: Signal characteristics [message #1718] Mon, 12 March 2018 13:31 Go to next message
Tobias Bregulla is currently offline  Tobias Bregulla
Messages: 15
Registered: June 2017
Junior Member
Dear railML-IL-community,

as my newsreader does not allow a crosspost and follow-up currently I
want to give your interest to the following post in the IS forum too.

Any feedback is welcome, please use the IS forum please! TB

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 [message #1726 is a reply to message #1718] Thu, 15 March 2018 06:45 Go to previous message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 88
Registered: May 2011
Member
Thanks Tobias for the hint.

Indeed in the 2.x versions of IS were introduced some functional data because no IL part was available. Within railML3
the functional aspects of an element like signal shall be placed in the IL part. In the current draft of IL there are
elements and attributes forseen to cover such data. In addition it has to be noted that issues like DangerPoint or the
shown signal aspect are related to routes but not the signal itself.

Best regards,
Dr.-Ing. Jörg von Lingen - Rollingstock scheme coordinator
- Interlocking scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 351 87759 40; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org


Tobias Bregulla wrote on 12.03.2018 13:31:
> Dear railML-IL-community,
>
> as my newsreader does not allow a crosspost and follow-up currently I
> want to give your interest to the following post in the IS forum too.
>
> Any feedback is welcome, please use the IS forum please! TB
>
> 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
Previous Topic: British Signalling System in railML V2.3
Next Topic: Clarification on Itineraries
Goto Forum:
  


Current Time: Sat Nov 17 16:13:47 CET 2018