Home » railML newsgroups » railML.infrastructure » [railML2] Enhancing the <lock> element
[railML2] Enhancing the <lock> element [message #2589] Mon, 16 November 2020 14:32 Go to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear all,

after the very basic implementation of the signaling element <lock> in railML 2.4 (see [1]), it has been suggested to extend it with upcoming version railML 2.5.

In particular, three modifications are proposed in Trac ticket #428 [2]:
* new attribute @positionAtTrack to describe the location of the lock left or right of the track
* new attribute @controllerRef to link the lock with the controller from where it is controlled
* new attribute @keyStorageRef to link the lock with the OCP where the key is stored in case it is not inserted in the lock.

Further, the question about "types of locks" remains: until further generalization of lock types enabling the introduction of an enumeration attribute, it is suggested to use the free text attribute @description for it.

Are there any objections against that railML 2.5 proposal?

[1] https://www.railml.org/forum/index.php?t=msg&th=484& goto=1941&#msg_1941
[2] https://trac.railml.org/ticket/428

Best regards
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML2] Enhancing the <lock> element [message #2671 is a reply to message #2589] Thu, 25 February 2021 08:57 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 157
Registered: March 2016
Senior Member
The Norwegian railway sector appreciates the suggestion for introduction of generic descriptions of a locks properties. We have no objections to the suggested implementation in railMl2. We suggest the coordinators double check if the suggested attributes in the previous and in this posting are also contained in [railML3].

We would like to suggest further adding two important attributes of the lock: its type and a reference to what it locks.

With the above suggested attributes, we now have a generic internationally clearly understandable general type description. But we have an UC to unambiguous designate a national type to a national rule. Here we suggest to use the attribute @ruleCode in raillML2.5. An example for the rule code would the Norwegian rule book for locks: https://orv.banenor.no/orv/doku.php?id=Brukerveiledninger:pe rsonale_som_skal_betjene_signalanlegg:kontroll%C3%A5ser_og_s amlel%C3%A5ser#lasetyper
Listing and describing the different types and their operational rules for the Norwegian lock types.

For railML3 I leave it to the coordinators to describe the type with either: @ruleCode, @kind, @type, @system or <designator>.

Reference to what the lock actually locks can be done either from the lock or to the lock. In railML2.4nor extensions we have the attribute @lockRef on the element <switch>, <crossing> and the <derailer>. But you could also have a subelement <takesControlOf> with an @ref attribute like in railML3. What does the community prefer?

Report message to a moderator

Re: [railML2] Enhancing the <lock> element [message #2687 is a reply to message #2671] Thu, 25 March 2021 13:52 Go to previous messageGo to next message
Michael Gruschwitz is currently offline  Michael Gruschwitz
Messages: 11
Registered: May 2020
Junior Member
Dear all!

Am 25.02.2021 um 08:57 schrieb Torben Brand:
> Reference to what the lock actually locks can be done either
> from the lock or to the lock. In railML2.4nor extensions we
> have the attribute @lockRef on the element <switch>,
> <crossing> and the <derailer>. But you could also have a
> subelement <takesControlOf> with an @ref attribute like in
> railML3. What does the community prefer?

We prefer the solution to have the attribute @lockRef on the element
<switch>, <crossing> and the <derailer> as it is implemented in the same
manner on the <controllerRef>.

Best regards,
--
Michael Gruschwitz
Bahnkonzept Dresden/Germany

Report message to a moderator

Re: [railML2] Enhancing the <lock> element [message #2700 is a reply to message #2687] Sun, 11 April 2021 06:08 Go to previous message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 87
Registered: March 2016
Member
Thanks for your feedback. We will the attribute @lockRef as suggested.


Best regards,
Joerg v. Lingen - Interlocking Coordinator
Am 25.03.2021 um 13:52 schrieb Michael Gruschwitz:
> Dear all!
>
> Am 25.02.2021 um 08:57 schrieb Torben Brand:
>> Reference to what the lock actually locks can be done either
>> from the lock or to the lock. In railML2.4nor extensions we
>> have the attribute @lockRef on the element <switch>,
>> <crossing> and the <derailer>. But you could also have a
>> subelement <takesControlOf> with an @ref attribute like in
>> railML3. What does the community prefer?
>
> We prefer the solution to have the attribute @lockRef on the element <switch>,
> <crossing> and the <derailer> as it is implemented in the same manner on the
> <controllerRef>.
>
> Best regards,

Report message to a moderator

Previous Topic: [railML2/3] <trainDetector> for manually operated stations
Next Topic: [railML2] adding an attribute for clearance on switches and crossings.
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Apr 19 10:18:57 CEST 2024