Home » railML newsgroups » railML.infrastructure » Representation of operational stations
Representation of operational stations [message #1740] Mon, 26 March 2018 13:50 Go to next message
Tobias Bregulla is currently offline  Tobias Bregulla
Messages: 20
Registered: June 2017
Junior Member
=== Deutsche Version siehe unten ===

Currently railML 2.4 knows the following four enumeration values of the
attribute <ocp><propOperational>@operationalType for stations:
* passenger
* freight
* shunting
* other
For Bahnkonzept programme export the question arises, how operational
stations should be modeled in railML 2.x. This means stations at which
passengers cannot get in and out, goods aren't loaded or unloaded nor
wagons are shunted (usually). Typical examples are the overtaking
stations on the high-speed lines, where mainly slower trains are
overtaken by faster trains, e.g. Saubachtal station on the high-speed
line VDE 8.1 of the DB Netz (Kilometre 236.5 of line 5919
Nuremberg-Erfurt-Leipzig, see
https://upload.wikimedia.org/wikipedia/commons/7/75/%C3%9Cbe rholbahnhof-Saubachtal-Okt2015.jpg
for an overview picture).

We propose the addition of a fifth attribute "operational" in railML 2.4
(and 3.x for sure) for such stations. Otherwise the leaving of any value
could be an option, but this could intersect with an "unknown" value.
(Maybe another word could reflect the common British term better?)

In addition, we suggest an addition to the descriptions of the elements
and, if necessary, a list of the meaningful combinations on the
corresponding wiki page. We will be happy to contribute constructively,
if desired.

Kind regards,

Tobias Bregulla and the whole Bahnkonzept team

==============================================
Abbildung von Betriebsbahnhöfen

Gegenwärtig kennt railML 2.4 die folgenden vier Aufzählungs-Werte des
Attributs <ocp><propOperational>@operationalType für Bahnhöfe:
- passenger (Fahrgäste/Passagiere)
- freight (Güter/Fracht)
- shunting (Rangieren/Verschieben)
- other (anderes)
Für uns stellt sich die Frage, wie Betriebsbahnhöfe (in der Schweiz:
Dienstbahnhöfe), in railML 2.x modelliert werden sollen. Das betrifft
Bahnhöfe, an denen weder Fahrgäste ein- und aussteigen können, keine
Güter ein- oder ausgeladen werden oder (in der Regel) keine Wagen
rangiert werden. Typische Beispiele sind die Überholbahnhöfe an den
Schnellfahrstrecken, an denen vor allem Überholungen von langsameren
durch schnellere Züge stattfinden, wie z.B. der Bahnhof Saubachtal an
der Schnellfahrstrecke VDE 8.1 der DB Netz (Kilometer 236,5 der Strecke
5919 Nürnberg-Erfurt-Leipzig; siehe
https://upload.wikimedia.org/wikipedia/commons/7/75/%C3%9Cbe rholbahnhof-Saubachtal-Okt2015.jpg)

Wir schlagen die Ergänzung eines fünften Attributes "operational" in
railML 2.4 sowie 3.x für derartige Stationen vor.

Zudem schlagen wir einer Ergänzung der Beschreibungen der Elemente und
ggf. eine Aufzählung der sinnvollen Kombinationen auf der entsprechenden
Wiki-Seite vor. Gern tragen wir dabei konstruktiv bei, sofern gewünscht.
Re: Representation of operational stations [message #1742 is a reply to message #1740] Tue, 27 March 2018 10:42 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Tobias,

Am 26.03.2018 um 13:50 schrieb Tobias Bregulla:
> Currently railML 2.4 knows the following four enumeration values of the
> attribute <ocp><propOperational>@operationalType for stations:
> * passenger
> * freight
> * shunting
> * other

I assume you are referring to the attribute @trafficType? The attribute
@operationalType is used to define the operational functionality of an
OCP containing the values
* station
* stoppingPoint
* depot
* crossover
* junction
* blockPost
* blockSignal
* other
Further values and adaptations are currently under discussion, see [1].

> For Bahnkonzept programme export the question arises, how operational
> stations should be modeled in railML 2.x. This means stations at which
> passengers cannot get in and out, goods aren't loaded or unloaded nor
> wagons are shunted (usually). Typical examples are the overtaking
> stations on the high-speed lines, where mainly slower trains are
> overtaken by faster trains, e.g. Saubachtal station on the high-speed
> line VDE 8.1 of the DB Netz (Kilometre 236.5 of line 5919
> Nuremberg-Erfurt-Leipzig, see
> https://upload.wikimedia.org/wikipedia/commons/7/75/%C3%9Cbe rholbahnhof-Saubachtal-Okt2015.jpg
> for an overview picture).
>
> We propose the addition of a fifth attribute "operational" in railML 2.4
> (and 3.x for sure) for such stations. Otherwise the leaving of any value
> could be an option, but this could intersect with an "unknown" value.
> (Maybe another word could reflect the common British term better?)

The proposal sounds reasonable to me. What do other users/developers
think about it? Does anybody have a better English term for "operational"?

> In addition, we suggest an addition to the descriptions of the elements
> and, if necessary, a list of the meaningful combinations on the
> corresponding wiki page. We will be happy to contribute constructively,
> if desired.

Thank you for your offer! Every contribution with the aim to enrich best
practices and examples in our railML wiki is highly appreciated.

[1] https://www.railml.org/forum/index.php?t=msg&th=483& goto=1583&#msg_1583

--
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: Representation of operational stations [message #1743 is a reply to message #1740] Tue, 27 March 2018 10:47 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Tobias,

Am 26.03.2018 um 13:50 schrieb Tobias Bregulla:
> [...] Typical examples are the overtaking
> stations on the high-speed lines, where mainly slower trains are
> overtaken by faster trains, e.g. Saubachtal station on the high-speed
> line VDE 8.1 of the DB Netz (Kilometre 236.5 of line 5919
> Nuremberg-Erfurt-Leipzig, see
> https://upload.wikimedia.org/wikipedia/commons/7/75/%C3%9Cbe rholbahnhof-Saubachtal-Okt2015.jpg
> for an overview picture).

Btw, isn't this an OCP of type "siding" as proposed in [1]?

[1] https://www.railml.org/forum/index.php?t=msg&th=483& goto=1741&#msg_1741

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: Representation of operational stations [message #1745 is a reply to message #1742] Tue, 27 March 2018 11:35 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 a Trac ticket for this issue, see [1].

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

Best regards
Christian

Am 27.03.2018 um 10:42 schrieb Christian Rahmig:
> Dear Tobias,
>
> Am 26.03.2018 um 13:50 schrieb Tobias Bregulla:
>> Currently railML 2.4 knows the following four enumeration values of the
>> attribute <ocp><propOperational>@operationalType for stations:
>> * passenger
>> * freight
>> * shunting
>> * other
>
> I assume you are referring to the attribute @trafficType? The attribute
> @operationalType is used to define the operational functionality of an
> OCP containing the values
> * station
> * stoppingPoint
> * depot
> * crossover
> * junction
> * blockPost
> * blockSignal
> * other
> Further values and adaptations are currently under discussion, see [1].
>
>> For Bahnkonzept programme export the question arises, how operational
>> stations should be modeled in railML 2.x. This means stations at which
>> passengers cannot get in and out, goods aren't loaded or unloaded nor
>> wagons are shunted (usually). Typical examples are the overtaking
>> stations on the high-speed lines, where mainly slower trains are
>> overtaken by faster trains, e.g. Saubachtal station on the high-speed
>> line VDE 8.1 of the DB Netz (Kilometre 236.5 of line 5919
>> Nuremberg-Erfurt-Leipzig, see
>> https://upload.wikimedia.org/wikipedia/commons/7/75/%C3%9Cbe rholbahnhof-Saubachtal-Okt2015.jpg
>>
>> for an overview picture).
>>
>> We propose the addition of a fifth attribute "operational" in railML 2.4
>> (and 3.x for sure) for such stations. Otherwise the leaving of any value
>> could be an option, but this could intersect with an "unknown" value.
>> (Maybe another word could reflect the common British term better?)
>
> The proposal sounds reasonable to me. What do other users/developers
> think about it? Does anybody have a better English term for "operational"?
>
>> In addition, we suggest an addition to the descriptions of the elements
>> and, if necessary, a list of the meaningful combinations on the
>> corresponding wiki page. We will be happy to contribute constructively,
>> if desired.
>
> Thank you for your offer! Every contribution with the aim to enrich best
> practices and examples in our railML wiki is highly appreciated.
>
> [1] https://www.railml.org/forum/index.php?t=msg&th=483& goto=1583&#msg_1583
>


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Representation of operational stations [message #1746 is a reply to message #1743] Wed, 28 March 2018 10:50 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Tobias,

in my understanding of the current railML schemes, a purely-operational station as you describe them is a station without any traffic service (dt: Bahnhof, der keine Zugangsstelle ist, keine verkehrlichen Eigenschaften hat).

So, to model such stations, we use an <ocp> without the sub-element <propService>.

To make it explicitly, if you fear a misunderstanding with an unknown <propService>, you can either use an empty <propService> element or set all its services to false:

<ocp id='ocp_DKT_B' name='Dresden-Klotzsche Bbf.' type='operationalName'>
<propOperational operationalType='station' orderChangeable='true' ensuresTrainSequence='true'/>
<propService/>
<designator register='RL100' entry='DKT B'/>
</ocp>

or

<ocp id='ocp_DKT_B' name='Dresden-Klotzsche Bbf.' type='operationalName'>
<propOperational operationalType='station' orderChangeable='true' ensuresTrainSequence='true'/>
<propService passenger='false' goodsLoading='false'/>
<designator register='RL100' entry='DKT B'/>
</ocp>

Please be aware that it is always good provide your interface with an own specification of which elements/attributes you used and how, complementing the railML scheme - a kind of use case documentation. Here, you can specify what a missing or an empty <propService> means.

> We propose the addition of a fifth attribute "operational" in railML 2.4...

I think that this would not be in the original sense. Even a station with "services" (dt: verkehrlichen Eigenschaften) would be operational as well. Please be also aware the possible misunderstanding with the sub-element <propOperational>.

> Btw, isn't this an OCP of type "siding" as proposed in [1]?

As far as I know, "siding" has been intended for sidings (dt: Nebengleise; hier: Anschlussstelle = Nebengleis abzweigend auf freier Strecke).

A pure station for overtakings or crossings (dt: reiner Überholungs- oder Kreuzungsbahnhof) would be a "loop". But in the operational meaning, it is still a station (dt: i. S. v. Zugmeldestelle). Since the name of the attribute is _operational_Type, the value should be 'station'.

(Dt: Im betrieblichen Sinne sind auch reine Überholungsbahnhöfe Zugmeldestellen. Da der Name des Attributs "_betrieblicher_ Typ" ist, sollte hier für alle Zugmeldestellen einheitlich 'station' verwendet werden. Die Unterscheidung der verkehrlichen Eigenschaften (Reiseverkehr, Güterverkehr oder keiner davon) sollte nicht im Element <propOperational> = "betriebliche Eigenschaften", sondern im Element <propService> = "verkehrliche Eigenschaften" erfolgen.)

With best regards,
Dirk.
Re: Representation of operational stations [message #1748 is a reply to message #1746] Tue, 03 April 2018 10:48 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Dirk,

Am 28.03.2018 um 10:50 schrieb Dirk Bräuer:
> So, to model such stations, we use an <ocp> without the sub-element <propService>.
>
> To make it explicitly, if you fear a misunderstanding with an unknown <propService>, you can either use an empty <propService> element or set all its services to false:
>
> <ocp id='ocp_DKT_B' name='Dresden-Klotzsche Bbf.' type='operationalName'>
> <propOperational operationalType='station' orderChangeable='true' ensuresTrainSequence='true'/>
> <propService/>
> <designator register='RL100' entry='DKT B'/>
> </ocp>
>
> or
>
> <ocp id='ocp_DKT_B' name='Dresden-Klotzsche Bbf.' type='operationalName'>
> <propOperational operationalType='station' orderChangeable='true' ensuresTrainSequence='true'/>
> <propService passenger='false' goodsLoading='false'/>
> <designator register='RL100' entry='DKT B'/>
> </ocp>

I prefer the second solution explicitly stating the boolean service
parameters with value "false". Missing service parameters can be
interpreted as being "unknown". As suggested by you we then need to add
this set of "interpretation rules" in the railML Wiki [1].

The central question to be solved: do we need to have a complementary
information with the attribute <ocp><propOperational>@trafficType in
addition to the attributes in <ocp><propService>? Any comments on this
question are highly appreciated.

>> We propose the addition of a fifth attribute "operational" in railML 2.4...
>
> I think that this would not be in the original sense. Even a station with "services" (dt: verkehrlichen Eigenschaften) would be operational as well. Please be also aware the possible misunderstanding with the sub-element <propOperational>.

This conflict could be solved by changing the current attribute
<ocp><propOperational>@trafficType into an element
<ocp><propOperational><traffic> that can be repeated. The modified
example may look like this:

<ocp id='ocp_DKT_B' name='Dresden-Klotzsche Bbf.' type='operationalName'>
<propOperational operationalType='station' orderChangeable='true'
ensuresTrainSequence='true'>
<traffic type="operational"/>
</propOperational>
<propService passenger='false' goodsLoading='false'/>
<designator register='RL100' entry='DKT B'/>
</ocp>

[1] https://wiki.railml.org/index.php?title=IS:propService

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: Representation of operational stations [message #1853 is a reply to message #1748] Fri, 22 June 2018 12:34 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 OCP traffic type
as formulated in Trac ticket #328 [1]:

* adding new value "operational"

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 Tobias (and all others that have a need for it):
Looking at the explanations in [2], do you still agree with current
proposal of Trac ticket #328 to be implemented with railML 2.4 or would
you like to change it? In particular: Does the "Betriebsbahnhof" (en:
loop and/or overtaking track with no passanger nor freight access) fit
to what you originally intended to model and are you satisfied with the
solution described in the wiki?

[1] https://trac.railml.org/ticket/328
[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

--
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: Representation of operational stations [message #1938 is a reply to message #1853] Thu, 30 August 2018 17:14 Go to previous messageGo to next message
Tobias Bregulla is currently offline  Tobias Bregulla
Messages: 20
Registered: June 2017
Junior Member
Dear all!

Am 22.06.2018 um 12:34 schrieb Christian Rahmig:
> let me summarize the current proposal for changing the OCP traffic type
> as formulated in Trac ticket #328 [1]:
> * adding new value "operational"

We would ask to enrich the OCP traffic type by adding new value
"operational" as formulated in Trac #328 for railML 2.4.

> My question to Tobias (and all others that have a need for it):
> Looking at the explanations in [2], do you still agree with current
> proposal of Trac ticket #328 to be implemented with railML 2.4 or woul
> you like to change it? In particular: Does the "Betriebsbahnhof" (en:
> loop and/or overtaking track with no passanger nor freight access) fit
> to what you originally intended to model and are you satisfied with he
> solution described in the wiki?

Reason: For the export of the operational meaning of an OCP we use the
element <propOperational>, since in our view the element <propService>
only specifies the peripheral and additional offers or services of a
station. For this reason, this element is often not evaluated in reading
subsequent systems, but an explicit specification of the status is required.

For railML 3.x we would suggest to find a unified modelling with lesser
or no overlaps between <propOperational> and <propService> to avoid
these possible misunderstandings.

Best regards,

Tobias and the Bahnkonzept team

Am 27.03.2018 um 10:42 schrieb Christian Rahmig:
> I assume you are referring to the attribute @trafficType? The attribute
> @operationalType is used to define the operational functionality of an
> OCP containing the values

Yes, that hint and the assumption were completely correct. I apologize
for the mix-up.
Re: Representation of operational stations [message #1982 is a reply to message #1853] Tue, 02 October 2018 14:14 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear all,

Am 22.06.2018 um 12:34 schrieb Christian Rahmig:
> [...]
> let me summarize the current proposal for changing the OCP traffic type
> as formulated in Trac ticket #328 [1]:
>
> * adding new value "operational"
>
> [...]
> [1] https://trac.railml.org/ticket/328

based on your feedback the modifications described in Trac ticket #328
[1] have been implemented for 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
Previous Topic: Marking @frontier and @chargeFrontier as DEPRECATED?
Next Topic: [railML3.1] TrainDetectionElement and TrainDetectionElementSection
Goto Forum:
  


Current Time: Fri Mar 29 12:44:01 CET 2024