Home » railML newsgroups » railML.infrastructure » Representation of operational stations
Re: Representation of operational stations [message #1748 is a reply to message #1746] Tue, 03 April 2018 10:48 Go to previous messageGo to previous 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
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Marking @frontier and @chargeFrontier as DEPRECATED?
Next Topic: [railML3.1] TrainDetectionElement and TrainDetectionElementSection
Goto Forum:
  


Current Time: Tue May 14 05:20:05 CEST 2024