Home » railML newsgroups » railML.infrastructure » Representation of operational stations
| Representation of operational stations [message #1740] |
Mon, 26 March 2018 13:50  |
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  |
christian.rahmig
Messages: 460
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 #1745 is a reply to message #1742] |
Tue, 27 March 2018 11:35 |
christian.rahmig
Messages: 460
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 |
Dirk Bräuer
Messages: 313
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 |
christian.rahmig
Messages: 460
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 |
christian.rahmig
Messages: 460
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 #1982 is a reply to message #1853] |
Tue, 02 October 2018 14:14 |
christian.rahmig
Messages: 460
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
|
|
|
|
Goto Forum:
Current Time: Sun Sep 15 08:52:16 CEST 2024
|
Members
Search
Help
Login
Home
