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)
railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1457] Tue, 20 December 2016 18:27 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
Dear railML infrastructure forum,
This posting contains the discussion to an extension towards the
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 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"
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.
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.
Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1466 is a reply to message #1457] Mon, 02 January 2017 17:29 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
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
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 next message
Torben Brand is currently offline  Torben Brand
Messages: 156
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".
Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1583 is a reply to message #1466] Thu, 18 May 2017 17:51 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Christian and Torben,

>> 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?

Yes, of course. In Germany (and other countries), we have the same type
of sidings. In Germany they are called Anschlussstelle und
Ausweichanschlussstelle depending on interlocking and operational rules.
It is an <ocp> but not a station. In both cases, the line track has to
be blocked between the adjacent stations during the operation of
entering and leaving the siding.

Currently we model such an <ocp> as follows:

<ocp id=...>
<propOperational orderChangeable='false'
ensuresTrainSequence='false' />
<propService goodsLoading='true'/>
<propEquipment>
<summary hasHomeSignals='false' hasStarterSignals='false'/>
</propEquipment>

We do not model the siding itself since there can be no train operation
at it (just shunting). The train begins and ends at the main track at
the <ocp>.

The intention of "sidingTrack" is to model any non-main track,
independently whether in stations or line-side. "Non-main track" means
tracks with no train operation, just shunting.

I think it's not necessary to explicitly distinguish between a siding of
a station or a line-side siding. Torben has already suggested to create
a possibility to assign track elements to <ocp>s. This implements the
solution to distinguish the two kinds of sidings.

Best regards,
Dirk.
New reflected thoughts towards infrastructure extension proposal operational properties of an OCP [message #1625 is a reply to message #1457] Fri, 14 July 2017 09:46 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
Some ocps have areas (usually stations) as others are point based (usually stopping point). But it is up to the user to define this. They can do this through referencing tracks under the existing sub element <ocp/propEquipment/trackRef>.

See aIso discussion under "line section": An alternative to lineSection type "openSection" (NO:"linjen",DE:"freihe Strecke" railML wiki "open track", term to be fixed), could be to add a new <propOperationa @operationalType="openSection". I do not recomended this, as the open section is not an ocp and ocps can overlap the open section. Thus a solution in lineSection is recomended. What do you think?

In Norway we also have ocp's on main signals in large stations that have alternative entry routes from the same neighbour ocp into the station. This is a sort of mesoscopic modelling where there is missing a microscopic route allocation defining the path into the station. Thus I suggest to add an new value for ocp @operationalType:"other:mainSignal"

I also like to suggest to add a macroscopic attribute to all ocp's a @timingPoint [absPos mileage].
Today the timing point can only be defined in an ocp microscopically on the track level as a <crossSection> which have to be defined per track. For macroscopic models the new approach would be simpler. Also historically an ocp (in Norway) has an absPos mileage timing point, where the local dispatcher used to sit. Today's remote controlled stations have no longer local dispatchers, but retain the same timing point for timetable purposes. But also additional timing points have been allocated to TVD's, for automatic time registration purposes. If we have the @timingPoint we could allocate the ocp general TT mileage there. This is used in timetabling and is deemed sufficient there. But for the use case simulation we would like to use the timing points of the TVD's. We could then use todays <crossSections> to define the automatic timing points. An alternative is to use both <crosssection>@type:"station" for the macroscopic timing point and <crosssection>@type:"autoblock" for the microscopic automatic time registration point (but I am uncertain if this is the correct use of the value "autoblock"). But this solution would lose the macroscopic advantage.
Ps. Could anyone describe the values "autoblock" and "block" @type <crossSection>? I could not find anything either in wiki, forum nor schema.

We in Norway still think it's important to have a seperate operationalType for "siding". Mapping the ocp like Dirk describes with describing the ocp's caracteristics in 6 lines with the attributes describing it in propOperational, propEquipment and propService seems less efficient as to define one unique term. We suggest to differentiate between "Anschlusstelle" and "Ausweichanschlusstelle" through use of @ensuresTrainSequence. We define all passing times for "sidings" ocp's in the TT in Norway today. So it would be usefull to differentiate them as <propOperational @operationalType="siding" in the TT as well.

I propose to retract my suggestion for a new <propOperational>@operationalType:"halt". The purpose of this was to model stopping points within stations. I think that this can be sufficient modelled through using the existing @operationalType:"stoppingPoint" in combination with a set value for <ocp>@ocpParentRef. This will indicate that the stopping point is part of another ocp presumably a station and thus in Norway a "stoppested" (stopping point within a station).
Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1741 is a reply to message #1583] Tue, 27 March 2018 10:28 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear all,

we were recently discussing the different types of OCP in our railML 3.x
Schematic Track Plan use case working group. Therefore, I would like to
come back to this forum post opened by Torben Brand from
Jernbanedirektoratet:

>>> 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?
>
> Yes, of course. In Germany (and other countries), we have the same type
> of sidings. In Germany they are called Anschlussstelle und
> Ausweichanschlussstelle depending on interlocking and operational rules.
> It is an <ocp> but not a station. In both cases, the line track has to
> be blocked between the adjacent stations during the operation of
> entering and leaving the siding.
>
> Currently we model such an <ocp> as follows:
>
> <ocp id=...>
> <propOperational orderChangeable='false'
> ensuresTrainSequence='false' />
> <propService goodsLoading='true'/>
> <propEquipment>
> <summary hasHomeSignals='false' hasStarterSignals='false'/>
> </propEquipment>

In order to complete the modelling, I suggest to follow Torben's
proposal and add the enumeration value "siding" for attribute
<ocp><propOperational>@operationalType.

If you agree, we may bring this as last minute change into railML 2.4.

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
Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1744 is a reply to message #1741] Tue, 27 March 2018 11:14 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear all,

I filed the Trac ticket #327 [1] dealing with this issue.

[1] https://trac.railml.org/ticket/327

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


Am 27.03.2018 um 10:28 schrieb Christian Rahmig:
> Dear all,
>
> we were recently discussing the different types of OCP in our railML 3.x
> Schematic Track Plan use case working group. Therefore, I would like to
> come back to this forum post opened by Torben Brand from
> Jernbanedirektoratet:
>
>>>> 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?
>>
>> Yes, of course. In Germany (and other countries), we have the same type
>> of sidings. In Germany they are called Anschlussstelle und
>> Ausweichanschlussstelle depending on interlocking and operational rules.
>> It is an <ocp> but not a station. In both cases, the line track has to
>> be blocked between the adjacent stations during the operation of
>> entering and leaving the siding.
>>
>> Currently we model such an <ocp> as follows:
>>
>> <ocp id=...>
>> <propOperational orderChangeable='false'
>> ensuresTrainSequence='false' />
>> <propService goodsLoading='true'/>
>> <propEquipment>
>> <summary hasHomeSignals='false' hasStarterSignals='false'/>
>> </propEquipment>
>
> In order to complete the modelling, I suggest to follow Torben's
> proposal and add the enumeration value "siding" for attribute
> <ocp><propOperational>@operationalType.
>
> If you agree, we may bring this as last minute change into railML 2.4.
>
> Best regards
> Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1820 is a reply to message #1583] Mon, 04 June 2018 08:27 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Dirk, dear all,

we discussed the topic of modelling a siding once again in the railML 3
use case working group "Schematic Track Plan". We also talked about your
current way of modelling:

Am 18.05.2017 um 17:51 schrieb Dirk Bräuer:
> [...]
> Yes, of course. In Germany (and other countries), we have the same type
> of sidings. In Germany they are called Anschlussstelle und
> Ausweichanschlussstelle depending on interlocking and operational rules.
> It is an <ocp> but not a station. In both cases, the line track has to
> be blocked between the adjacent stations during the operation of
> entering and leaving the siding.
>
> Currently we model such an <ocp> as follows:
>
> <ocp id=...>
> <propOperational orderChangeable='false'
> ensuresTrainSequence='false' />
> <propService goodsLoading='true'/>
> <propEquipment>
> <summary hasHomeSignals='false' hasStarterSignals='false'/>
> </propEquipment>
>
> We do not model the siding itself since there can be no train operation
> at it (just shunting). The train begins and ends at the main track at
> the <ocp>.

From operational perspective it is complete although not mentioning the
term "siding", but for use case "SCTP" we need further information about
the siding. In particular, we want to know about the number and length
of the tracks included in this siding. And: what value does the
attribute <opc><propOperational>@operationalType have?

Any comments are highly appreciated...

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
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 Go to previous messageGo to next message
christian.rahmig is currently offline  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
Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1942 is a reply to message #1744] Fri, 31 August 2018 10:53 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear all,

Trac ticket #327 [1] has been implemented for railML 2.4.

Best regards
Christian

Am 27.03.2018 um 11:14 schrieb Christian Rahmig:
> [...]
> [1] https://trac.railml.org/ticket/327


--
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
Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1948 is a reply to message #1851] Mon, 03 September 2018 18:59 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Christian and Torben,

> * Mark value "blockPost" as DEPRECATED

? As you can see from [1], we use 'blockPost' for combined blocking signals which are locally staffed. Despite this is an old-fashioned model, there are still some of these "Blockstelle" (as for instance the example BBAE 'Bärhaus') and we do not know how many years they will still exist. So marking "blockPost" as DEPRECATED, does it mean we are not allowed to encode them this way in railML any-more?

> * Adding new value "siding"

> We in Norway still think it's important to have a seperate
> operationalType for "siding". Mapping the ocp like Dirk
> describes with describing the ocp's caracteristics in 6
> lines with the attributes describing it in propOperational,
> propEquipment and propService seems less efficient as to
> define one unique term.

Ok, but this means redundancy: We then can find a siding either with the new value "siding" or with the old kind we did encode it so far.
Please avoid redundancy because it means much more effort for importing interfaces and therefore, raises implementation costs and reduces acceptance!

> @ensuresTrainSequence. We define all passing times for
> "sidings" ocp's in the TT in Norway today. So it would be
> usefull to differentiate them as <propOperational
> @operationalType="siding" in the TT as well.

Yes, we also encode passing times for such sidings in Germany. As this is already done since many years, it is no reason for a new enumeration value.

Any <ocp> can be referred from <TT>. Please explain what you mean with "to differentiate them as <propOperational> @operationalType="siding" in the TT as well".

> From operational perspective it is complete although not mentioning the term "siding", but for use case "SCTP" we need further information about the siding. In particular, we want to know about the number and length of the tracks included in this siding.

Yes, ok, no objection. But here, we discuss only the attributes of the (macroscopic) railML element <ocp>. The <ocp> is only the virtual container for the crossSection. You can still encode all the <track>s, <switches> etc. and therefore model the infrastructure of the "siding" in any meso- or microscopic level you prefer. Do you intend to name the number and length of the tracks in the macroscopic <ocp> additionally, redundantly to meso <tracks> and the microscopic <switches>?

Dirk.

[1]
https://wiki.railml.org/index.php?title=Dev:Types_of_ocps#Bl ockstelle_.E2.80.A2_Locally_staffed_block_post
Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #2672 is a reply to message #1942] Thu, 25 February 2021 09:59 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
I would like to come back to the proposed attribute @simultaneousEntry in the initial posting in this thread and explained further in reply postings in the thread. It is now used in railML2.4nor extension and defined as: Enumerates the different Norwegian infrastructure design and operational rule types of simultaneous entry into a station. See Norwegian technical design rules for definitions of the 4 types that have simultaneous entry. In addition to the two types "none" and "partial".
https://trv.banenor.no/wiki/Signal/Prosjektering/Forriglings utrustning#Samtidige_togbevegelser.

The Norwegian railway sector proposes to introduce the extension into railML2.5 under <propOperational>. For a more international and generic clean approach I suggest to split the existing extension attribute @simultaneousEntry into two attributes @hasSimultaneousEntry with the enumeration values: "yes","no" and "partial". The national rule specific type for stations with simultaneous entry can be defined with @simultaneousEntryruleCode.

What does the community think?

[Updated on: Thu, 25 February 2021 09:59]

Report message to a moderator

Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #2762 is a reply to message #2672] Fri, 11 June 2021 16:54 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear all,

Torben Brand wrote on Thu, 25 February 2021 09:59
The Norwegian railway sector proposes to introduce the extension into railML2.5 under <propOperational>. For a more international and generic clean approach I suggest to split the existing extension attribute @simultaneousEntry into two attributes @hasSimultaneousEntry with the enumeration values: "yes","no" and "partial". The national rule specific type for stations with simultaneous entry can be defined with @simultaneousEntryruleCode.

What does the community think?

as there has been no objecting feedback by the community, I suggest to follow Torben's suggestion. The Trac ticket #416 [1] already summarizes the railML 2.5 solution proposal.

One thing still need to be clarified: what are the values of the enumeration @simultaneousEntry?

Any comment is highly appreciated...

[1] https://trac.railml.org/ticket/416

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #2763 is a reply to message #2762] Mon, 14 June 2021 23:20 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
Christian Rahmig <coord(at)infrastructurerailMLorg> wrote:
> Dear all,
>
> Torben Brand wrote on Thu, 25 February 2021 09:59
>> The Norwegian railway sector proposes to introduce the
>> extension into railML2.5 under <propOperational>. For a
>> more international and generic clean approach I suggest to
>> split the existing extension attribute @simultaneousEntry
>> into two attributes @hasSimultaneousEntry with the
>> enumeration values: "yes","no" and "partial". The national
>> rule specific type for stations with simultaneous entry
>> can be defined with @simultaneousEntryruleCode.
>>
>> What does the community think?
>
>
> as there has been no objecting feedback by the community, I
> suggest to follow Torben's suggestion. The Trac ticket #416
> [1] already summarizes the railML 2.5 solution proposal.
>
> One thing still need to be clarified: what are the values of
> the enumeration @simultaneousEntry?
>
> Any comment is highly appreciated...
>
> [1] https://trac.railml.org/ticket/416
>
> Best regards
> Christian
>

For this simple approach of mapping the simultanious entry in a station we
suggest the enumeration values to be:
"yes","no", "partial" and "other:"

--
TOBR
Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #2768 is a reply to message #2763] Fri, 18 June 2021 14:31 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Torben,

thank you very much for your feedback. I adopted the Trac ticket #416 [1] accordingly. The proposed solution will be implemented with upcoming railML 2.5.

[1] https://trac.railml.org/ticket/416

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: [railML 2.5] state
Next Topic: [railML2] Basic speed profile
Goto Forum:
  


Current Time: Thu Mar 28 19:33:29 CET 2024