Home » railML newsgroups » railml.rollingstock » need for new element stopingActivity time (stopingActivity)
Re: need for new element stopingActivity time [message #1965 is a reply to message #1962] Sun, 16 September 2018 14:26 Go to previous message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 148
Registered: May 2011
Senior Member
The request was placed in TRAC https://trac.railml.org/ticket/342.

Best regards,
Joerg v. Lingen

Rollingstock Coordinator

On 14/09/2018 22:28, Dirk Bräuer wrote:
> No objections from my side.
>
> I agree that it would be fine to have the _technical_ (minimum) times for split/join/reverse of a <vehicle> and possibly a <formation>.
>
> I see some need for clarifications additional to that what Torben already mentioned:
>
> - For join/split, we should make these times independent of the shunting distance (the distance both trains stopped from each other when arriving before a join) and independent from the local interlocking technology (kind of signals, whether the second train stops in front of a flag, a main signal, a shunting signal or simply by the buffers of the train in front). This probably means to encode a theoretical-only time value which must be raised by the shunting and/or interlocking time.
>
> - For reverse, the same applies for the walking time between the two cabs (reversing time must be raised by the walking time in case there is only one driver). But please consider that there may be engines with only one cab (centre cab) where even one driver can simply turn around. So it may be the easiest solution to provide two times (reversing with the same driver, reversing with change of drivers) and set these times equal in case the engine has only one cab. This saves encoding the number of and distance of the cabs.
>
> Concerning @scope and @range, I would like to limit it to "technical" and "minimum" and to avoid "operational", "average" a.s.o. Operational and average times may depend on the local rules, authorities, state, Infrastructure Manager and therefore cannot be given at the <vehicle>. And more, to enumerate too many overlapping values here makes it very difficult to import such railML files in future as one possibly needs a "conversion matrix". So I vote for limiting this only to the really necessary aspects or limit it for certain use cases.
>
> Dirk.
>
 
Read Message
Read Message
Read Message
Read Message
Previous Topic: new values for places and service
Next Topic: missing minOccurs="0" for <trainBrakeOperation>
Goto Forum:
  


Current Time: Tue May 07 17:24:27 CEST 2024