[railML2] Enhancing the <lock> element [message #2589] |
Mon, 16 November 2020 14:32 |
christian.rahmig
Messages: 465 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
|
|
|
|
|
Re: [railML2] Enhancing the <lock> element [message #2700 is a reply to message #2687] |
Sun, 11 April 2021 06:08 |
Jörg von Lingen
Messages: 91 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,
|
|
|