| Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1851 is a reply to message #1466] |
Fri, 22 June 2018 11:43   |
christian.rahmig
Messages: 436
Registered: January 2016
|
Senior Member |
|
|
Dear all,
let me summarize the current proposal for changing the operational OCP
type as formulated in Trac ticket #327 [1]:
* Mark value "blockPost" as DEPRECATED
* Adding new value "siding"
Further, I want to direct your focus on the new wiki page [2] about
different types of OCPs. Although the examples describe the situation in
Germany, they provide a very good insight in specific modelling of
different types of OCPs. Thank you very much, Dirk and Mr. Leberl, for
this contribution!
My question to all of you:
Looking at the explanations in [2], do you still agree with current
proposal of Trac ticket #327 to be implemented with railML 2.4 or would
you like to change it?
[1] https://trac.railml.org/ticket/327
[2] https://wiki.railml.org/index.php?title=Dev:Types_of_ocps
As usual I am looking forward to receiving your comments...
Best regards
Christian
Am 02.01.2017 um 17:29 schrieb Christian Rahmig:
> Dear Torben,
>
> Am 20.12.2016 um 18:27 schrieb Torben Brand:
>> [...]
>> propOperational
>> In Norway trains are by default only allowed to enter a
>> station one by one, due to safety reasons. If a station is
>> equipped/designed with simultaneous entry features
>> (NO:samtidig innkjør) trains may enter simultaneously. This
>> is necessary to know for the capacity planner, timetable
>> planner and train driver. The element <propOperational> is extended
>> with the new
>> attribute @NO:samtidigInnkjør [datatype: enumeration]. The
>> attribute has 4 Norwegian preset values and the values
>> "partial" and "none". The precise values of the value
>> "partial" needs to be defined in another system/model.
>
> The reasons for having the attribute seem clear to me. Can you tell us
> what are the four Norwegian preset values for this parameter? Further,
> instead of "partial", which is rather unspecific, I would prefer having
> more concise values instead. Are there any other railways that make use
> of such an attribute? If yes, I have no objections against creating a
> Trac ticket and implementing this attribute with the next release.
>
>> The attribute @operationalType is extended with the value
>> "siding". In Norway a "siding" is an additional track on the
>> path (section of line between stations). It is not a station
>> according to Norwegian definition as it does not have a
>> main-home signal. Thus the path on the siding needs to be
>> blocked during the operation of entering and leaving the
>> siding. PS. There is a trackType under track with value
>> "sidingTrack" This is described in the Wiki as: "This is a
>> siding"
>
> Yes, railML already allows to specify a track as being a siding track by
> setting <track type="sidingTrack">. However, what is missing is an
> operational representation of the siding as you request it. Therefore,
> your suggestion to add the enumeration value "siding" for the attribute
> @operationalType seems to be valid. Is there anybody among the railML
> community who needs to model sidings outside of stations, too?
>
>> The attribute @operationalType is extended with the value
>> "halt". In Norway we need to separate between a halt within
>> a station and outside the station (on the path). I suggest
>> to use the existing operationalType "stopingPoint" with
>> halts within the station (As this correlates with the
>> Norwegian name "stoppested"="stoppingplace"). And the new
>> operationalType "halt" for halts on the path.
>
> An operation control point <ocp> is located on a track indirectly via
> the <crossSection> element. The track itself can be classified as a
> station track or a main route track via its attribute @type. Thus, it is
> possible to distinguish between an OCP within a station and an OCP
> outside the station (de: "freie Strecke"). Consequently, it is not
> absolutely necessary to introduce a new enumeration value "halt" for
> <ocp><propOperational>@operationalType. Your example may look like this:
>
> <track id="tr01" type="stationTrack">
> <trackTopology>
> <crossSections>
> <crossSection id="cs01" pos="123.4" ocpRef="op01">
> </crossSection>
> </crossSections>
> </trackTopology>
> </track>
> ...
> <ocp id="op01">
> <propOperational operationalType="stoppingPoint">
> </propOperational>
> </ocp>
>
> However, the solution is complex and it requires <track> elements in
> order to locate the OCP via their <crossSection> elements. Your proposed
> attribute adaptation would work also without tracks and it would assign
> the feature directly to the OCP. Therefore, I am open for more opinions
> on this issue to find a practical solution.
>
>> It needs to be defined if a station is remote controlled (by
>> CTC). Thus we have added the new bolean attribute
>> @NO:remoteControlled. Later extensions could define which
>> remote controller (CTC) is controlling the interlocking
>> controller.
>
> Accepted. Instead of a boolean attribute, it might be useful to define
> an enumeration attribute in order to specify the type of controlling. On
> the other side, the detailed definition of station control should be
> done in the <controller> element and therefore your suggested solution
> with the boolean attribute seems to fit well.
>
> 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
