| Re: railML 2.3 infrastructure extension proposal - locks [message #1469 is a reply to message #1458] |
Mon, 02 January 2017 17:30   |
christian.rahmig
Messages: 436
Registered: January 2016
|
Senior Member |
|
|
Dear Torben,
Am 20.12.2016 um 18:29 schrieb Torben Brand:
> [...]
> ocsElements
> Locks are simple physical lineside elements that can only
> have two states: locked or unlocked. Locks reference to
> which objects they lock. Their relationship will later be
> defined in the interlocking scheme. The element <ocsElements> is
> extended with the new element
> <locks> with sub element <lock> with attributes @objectRef
> and @type [datatype: enumeration] with 5 Norwegian presets,
> the value "ERTMS" and "other:".
The lock (de: "Schlüsselsperre") is a device that is relevant for
interlocking purposes. At the same time, it is a physical element and
thus should be part of the railway infrastructure model. Currently,
modelling a lock with railML 2.3 would look like this:
<track ...>
...
<ocsElements>
<trainProtectionElements>
<trainProtectionElement id="tpe01" pos="123.4" description="lock">
</trainProtectionElement>
</trainProtectionElements>
</ocsElements>
</track>
Your approach to introduce a new element <lock> is more straightforward
and it fits better considering that a lock is not a train protection
element like an Indusi magnet. If there are use cases requiring the
specific definition of locks, I appreciate having them included in the
railML infrastructure model. Which objects are referenced by
<lock>@objectRef? What are the 5 Norwegian presets for the attribute
<lock>@type?
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
|
|
|
|
Members
Search
Help
Login
Home
