Home » railML newsgroups » railML.infrastructure » railML 2.3 infrastructure extension proposal operational properties of an OCP (railML 2.3 infrastructure extension proposal operational properties of an OCP)
Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1510 is a reply to message #1466] Fri, 24 February 2017 15:33 Go to previous messageGo to previous message
Torben Brand is currently offline  Torben Brand
Messages: 157
Registered: March 2016
Senior Member
Christian Rahmig wrote:
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.


My reply:
The four Norwegian generic values for simultaneous entry are: Standard, alternative 1, alternative 2 and alternative 3. For more information, see: https://trv.jbv.no/wiki/Signal/Prosjektering/Forriglingsutru stning#Samtidige_togbevegelser
The Norwegian line description book (DE:"Streckenbuch") lists the four alternatives, but also stations with "partial" functionality. This means that some routes have simultaneous entry functionality and others do not on the same OCP. This is an indicator to get more information from other sources. One future source could be the upcoming interlocking schema. An alternative would be to have a sub-element that refers to the specific routes that have simultaneous entry. This would require routes to be described in railML. Therefore, I suggest to leave it at "partial".

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.


As I read the documentation a <track>@type"mainTrack" is valid for both the path and the stations.
To be able to seperate between a main track in a station and on the path, we need to add a new value "mainStationTrack"? But this would remove the possibility for long tracks through stations. See railML wiki: mainTrack=DE:"durchgehendes Hauptgleis" and stationTrack=DE:"Bahnhofsgleis (Hauptgleis im Bahnhof) and compare to Fiedler „Bahnwesen" 5.Auflage page 311-312.
However, this is not relevant if I understand the documentation to be that there is only one main track, independent from path or station.

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.

I agree the solution is complex.
It would be easier, as you suggest, to create a new enumeration value to distinguish between a stopping point within a station (todays value "stoppingPoint") and on the path (new value "NO:halt", like I suggest.
Also alternatively, you could use value "stoppingPoint" for both and use the suggested line section extension to determine if a ocp (or any other object) is within a station or on the path. But this would again be somewhat complex and require the use of an optional new extended element. For macroscopic purposes I suggest the approach with the new enumeration "halt".
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: [railML 2.5] state
Next Topic: [railML2] Basic speed profile
Goto Forum:
  


Current Time: Fri Apr 26 17:05:41 CEST 2024