Extend definition of <lock> and add values
Open
Extend definition of <lock> and add values
Description
railML 2.4 implementation of is only very basic and needs to be extended to make usable.
Background
This ticket was raised by Norway as part of the standardisation in Norway and shall be used commonly in the future.
The element is a sub-element of . The set of attributes available in core railML2.4 for the lock element is extended in railML2.4nor (for a complete table, see 4.21.2).
The Norwegian standardisation requires a clearer definition of the element. The primary use case in railML2.4nor for the modelling of locks is capacity planning. Therefore, only the operational aspects of the lock are modelled and not what kind of object it locks and in which relation it locks them (interlocking).
For more details see document “railML2.4nor Infrastructure Documentation“ (https://www.jernbanedirektoratet.no/railML), version 1.3, 03.07.2020, point 4.21.
Links
- Forum discussion:
- Torben Brand, 20.12.2016: [https://www.railml.org/forum/index.php?t=msg&th=484&goto=1458&#msg_1458]
- Christian Rahmig, 16.11.2020: [https://www.railml.org/forum/index.php?t=msg&th=778&goto=2589&#msg_2589]
- Morten Johansson, 29.04.2021: [https://www.railml.org/forum/index.php?t=msg&th=809&goto=2708&#msg_2708]
- Trac tickets:
- #428
- #305 (Introduction of a lock as new signalling infrastructure element)
- Wiki documentation:
- IS:lock: [http://wiki2.railml.org/wiki/IS:lock]
Proposed solution in railML 2.5
Add new attribute @positionAtTrack ("left", "right") to describe location of the lock along the track.
Add new reference attribute @controllerRef to link the lock with the controller from where it is controlled.
Add new reference attribute @keyStorageRef to link the lock with the OCP where the key is stored in case it is not inserted in the lock.
The information about the lock type is currently not yet defined in a generic way. Therefore, it is suggested to use existing attribute @description (free text) for it.
Add new attribute @trackDist to specify the distance between the track's middle axis and the middle of the lock cabinet in meters (should be given at least with decimeter accuracy).
Activity
- Description changed
== Description == This ticket was raised by Norway as part of the standardisation in Norway and shall be used commonly in the future. The <lock> element is a sub-element of <ocsElements>. The set of attributes available in core railML2.4 for the lock element is extended in railML2.4nor (for a complete table, see 4.21.2). The Norwegian standardisation requires a clearer definition of the element. The primary use case in railML2.4nor for the modelling of locks is capacity planning. Therefore, only the operational aspects of the lock are modelled and not what kind of object it locks and in which relation it locks them (interlocking). For more details see document “railML2.4nor Infrastructure Documentation“ (https://www.jernbanedirektoratet.no/railML), version 1.3, 03.07.2020, point 4.21. Which of the existing elements can be used? * <lock> === Background === […] === Links === * Forum discussion: * […] * Trac tickets: * #428 + * #305 * Wiki documentation: * none == Proposed solution in railML 2.5 == tbd- Description changed
== Description == This ticket was raised by Norway as part of the standardisation in Norway and shall be used commonly in the future. The <lock> element is a sub-element of <ocsElements>. The set of attributes available in core railML2.4 for the lock element is extended in railML2.4nor (for a complete table, see 4.21.2). The Norwegian standardisation requires a clearer definition of the element. The primary use case in railML2.4nor for the modelling of locks is capacity planning. Therefore, only the operational aspects of the lock are modelled and not what kind of object it locks and in which relation it locks them (interlocking). For more details see document “railML2.4nor Infrastructure Documentation“ (https://www.jernbanedirektoratet.no/railML), version 1.3, 03.07.2020, point 4.21. Which of the existing elements can be used? * <lock> === Background === […] === Links === * Forum discussion: * […] * Trac tickets: * #428 - * #305 + * #305 (Introduction of a lock as new signalling infrastructure element) * Wiki documentation: * none == Proposed solution in railML 2.5 == tbd- Description changed
== Description == This ticket was raised by Norway as part of the standardisation in Norway and shall be used commonly in the future. The <lock> element is a sub-element of <ocsElements>. The set of attributes available in core railML2.4 for the lock element is extended in railML2.4nor (for a complete table, see 4.21.2). The Norwegian standardisation requires a clearer definition of the element. The primary use case in railML2.4nor for the modelling of locks is capacity planning. Therefore, only the operational aspects of the lock are modelled and not what kind of object it locks and in which relation it locks them (interlocking). For more details see document “railML2.4nor Infrastructure Documentation“ (https://www.jernbanedirektoratet.no/railML), version 1.3, 03.07.2020, point 4.21. Which of the existing elements can be used? * <lock> === Background === […] === Links === * Forum discussion: - * […] + * Christian Rahmig, 02.01.2017: https://www.railml.org/forum/index.php?t=msg&th=484&goto=1458&#msg_1458 * Trac tickets: * #428 * #305 (Introduction of a lock as new signalling infrastructure element) * Wiki documentation: * none == Proposed solution in railML 2.5 == tbd
- Cc added @coordination.IL
- Description changed
== Description == + + railML 2.4 implementation of <lock> is only very basic and needs to be extended to make <lock> usable. + + === Background === This ticket was raised by Norway as part of the standardisation in Norway and shall be used commonly in the future. The <lock> element is a sub-element of <ocsElements>. The set of attributes available in core railML2.4 for the lock element is extended in railML2.4nor (for a complete table, see 4.21.2). The Norwegian standardisation requires a clearer definition of the element. The primary use case in railML2.4nor for the modelling of locks is capacity planning. Therefore, only the operational aspects of the lock are modelled and not what kind of object it locks and in which relation it locks them (interlocking). For more details see document “railML2.4nor Infrastructure Documentation“ (https://www.jernbanedirektoratet.no/railML), version 1.3, 03.07.2020, point 4.21. - Which of the existing elements can be used? - - * <lock> - - === Background === - - […] - === Links === * Forum discussion: - * Christian Rahmig, 02.01.2017: https://www.railml.org/forum/index.php?t=msg&th=484&goto=1458&#msg_1458 ? ^^ ^^^^ ^^^^^^^ --- ^ + * Torben Brand, 20.12.2016: [https://www.railml.org/forum/index.php?t=msg&th=484&goto=1458&#msg_1458] ? ^^ ^^^^^^ ^ + ++ ^ + + * Trac tickets: * #428 * #305 (Introduction of a lock as new signalling infrastructure element) * Wiki documentation: - * none + * IS:lock: [http://wiki2.railml.org/wiki/IS:lock] == Proposed solution in railML 2.5 == - tbd + Add new attribute **<lock>@positionAtTrack** ("left", "right") to describe location of the lock along the track. + + Add new reference attribute **<lock>@controllerRef** to link the lock with the controller from where it is controlled. + + Add new reference attribute **<lock>@keyStorageRef** to link the lock with the OCP where the key is stored in case it is not inserted in the lock. + + The information about the lock type is currently not yet defined in a generic way. Therefore, it is suggested to use existing attribute @description (free text) for it.Restructuring Trac ticket adding links and detailed railML 2.5 solution proposal.
-
- Description changed
== Description == railML 2.4 implementation of <lock> is only very basic and needs to be extended to make <lock> usable. === Background === This ticket was raised by Norway as part of the standardisation in Norway and shall be used commonly in the future. The <lock> element is a sub-element of <ocsElements>. The set of attributes available in core railML2.4 for the lock element is extended in railML2.4nor (for a complete table, see 4.21.2). The Norwegian standardisation requires a clearer definition of the element. The primary use case in railML2.4nor for the modelling of locks is capacity planning. Therefore, only the operational aspects of the lock are modelled and not what kind of object it locks and in which relation it locks them (interlocking). For more details see document “railML2.4nor Infrastructure Documentation“ (https://www.jernbanedirektoratet.no/railML), version 1.3, 03.07.2020, point 4.21. === Links === * Forum discussion: * Torben Brand, 20.12.2016: [https://www.railml.org/forum/index.php?t=msg&th=484&goto=1458&#msg_1458] + * Christian Rahmig, 16.11.2020: [https://www.railml.org/forum/index.php?t=msg&th=778&goto=2589&#msg_2589] * Trac tickets: * #428 * #305 (Introduction of a lock as new signalling infrastructure element) * Wiki documentation: * IS:lock: [http://wiki2.railml.org/wiki/IS:lock] == Proposed solution in railML 2.5 == Add new attribute **<lock>@positionAtTrack** ("left", "right") to describe location of the lock along the track. Add new reference attribute **<lock>@controllerRef** to link the lock with the controller from where it is controlled. Add new reference attribute **<lock>@keyStorageRef** to link the lock with the OCP where the key is stored in case it is not inserted in the lock. The information about the lock type is currently not yet defined in a generic way. Therefore, it is suggested to use existing attribute @description (free text) for it.adding link to new (railML 2.5) forum post about implementation
- Cc added @coordination.IS
- Owner set to @coordination.IL
- Status changed from new to assigned
-
- Resolution set to fixed
- Status changed from assigned to closed
solved with [1116]
-
- Description changed
== Description == railML 2.4 implementation of <lock> is only very basic and needs to be extended to make <lock> usable. === Background === This ticket was raised by Norway as part of the standardisation in Norway and shall be used commonly in the future. The <lock> element is a sub-element of <ocsElements>. The set of attributes available in core railML2.4 for the lock element is extended in railML2.4nor (for a complete table, see 4.21.2). The Norwegian standardisation requires a clearer definition of the element. The primary use case in railML2.4nor for the modelling of locks is capacity planning. Therefore, only the operational aspects of the lock are modelled and not what kind of object it locks and in which relation it locks them (interlocking). For more details see document “railML2.4nor Infrastructure Documentation“ (https://www.jernbanedirektoratet.no/railML), version 1.3, 03.07.2020, point 4.21. === Links === * Forum discussion: * Torben Brand, 20.12.2016: [https://www.railml.org/forum/index.php?t=msg&th=484&goto=1458&#msg_1458] * Christian Rahmig, 16.11.2020: [https://www.railml.org/forum/index.php?t=msg&th=778&goto=2589&#msg_2589] + * Morten Johansson, 29.04.2021: [https://www.railml.org/forum/index.php?t=msg&th=809&goto=2708&#msg_2708] * Trac tickets: * #428 * #305 (Introduction of a lock as new signalling infrastructure element) * Wiki documentation: * IS:lock: [http://wiki2.railml.org/wiki/IS:lock] == Proposed solution in railML 2.5 == Add new attribute **<lock>@positionAtTrack** ("left", "right") to describe location of the lock along the track. Add new reference attribute **<lock>@controllerRef** to link the lock with the controller from where it is controlled. Add new reference attribute **<lock>@keyStorageRef** to link the lock with the OCP where the key is stored in case it is not inserted in the lock. The information about the lock type is currently not yet defined in a generic way. Therefore, it is suggested to use existing attribute @description (free text) for it. + + Add new attribute **<lock>@trackDist** to specify the distance between the track's middle axis and the middle of the lock cabinet in meters (should be given at least with decimeter accuracy).- Resolution fixed deleted
- Status changed from closed to reopened
re-open Trac ticket after forum post by Morten (29.04.2021) who requested another parameter for the element .
-
- Owner set to @coordination.IS
- Status changed from reopened to assigned
Christian shall implement (purely infrastructure focus of new request)
-
- Owner set to @documentation.GOV
solution has been implemented with railML 2.5;
documentation in wiki need to be adapted or added for new attributes; ticket has been assigned to Mr. Ferri Leberl who is responsible for the wiki documentation.
changed milestone to %2.5
removed 2.5 label
Please register or sign in to reply