Home » railML newsgroups » railml.timetable » Meaning and usage of @shuntingTime
Meaning and usage of @shuntingTime [message #1847] Mon, 18 June 2018 19:41 Go to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear all,

I corrected the Wiki page TT:times concerning the usage of arrival at first and and departure at last <ocpTT> of a train as ordered by the last <TT> developer telco.

When doing so, I became aware that there is still an attribute
<ocpTT>.<times>.@shuntingTime: "This is the shunting time used inside a station"

There is another @shuntingTime at:
<ocpTT>.<stopDescription>.@shuntingTime: "usually defined at first/last ocpTT"

So, obviously we can notice that it is NOT intended to use the first arrival time nor the last departure time to encode the time when a train enters/leaves its track. Rather, it is intended to use one of the @shuntingTime for that.
I imagine it like this:
- First departure is 8.10 hours at first <ocpTT>.
- Train occupies the track from 7.45 hours at first <ocpTT>.
- Instead of <ocpTT>.<times arrival='7:45' departure='8:10'/>
it is intended to say <ocpTT>.<times departure='8:10' shuntingTime='0:25'/>.

Any objections? If not, we should clarify this in Wiki. Else, we should clarify what @shuntingTime is to be used for.

Also, we should clarify the relation between the two @shuntingTime instances. If nobody has an idea, I would recommend to declare <ocpTT>.<stopDescription>.@shuntingTime as deprecated and <ocpTT>.<times>.@shuntingTime as the only one to be used.

With best regards,
Dirk.
Re: Meaning and usage of @shuntingTime [message #1927 is a reply to message #1847] Mon, 27 August 2018 12:20 Go to previous messageGo to next message
Heribert Neu is currently offline  Heribert Neu
Messages: 7
Registered: January 2018
Junior Member
Hello Dirk,

first a note: the shuntingTime is an attribute of <ocpTT> and not of <ocpTT>.<times>.

I agree with you that the specification of the shuntingTime at the <stopTimes> is not required. In my opinion the shuntingTime at <stopTimes> can be declared as deprecated.

You also write:
So, obviously we can notice that it is NOT intended to use the first arrival time nor the last departure time to encode the time when a train enters/leaves its track
I contradict this based on the following arguments:
1. The values in <times> also have a scope: actual, calculated, published, scheduled etc.. The shuntingTime as attribute of <ocpTT> does not have this scope and the assignment would therefore be problematic.
2. Shunting can also take place and be completed before the train is made available. Thus, the shunting time would be an additional information about arrival and departure.
3. For me the ShuntingTime is an additional optional specification. For example, a train in a station is strengthened with additional vehicles, the mapping would then be:
<ocpTT ... shunting Time 0:15>.<times arrival='7:45' departure='8:10' scope: scheduleded/><ocpTT/>
The attribute shuntingTime here would provide the information that at the station a shunting of the duration of 15 min must take place and thus the stopover lasts in any case accordingly long. This example could be used as an example for using shuntingTime in the wiki.
4. Since we have very different use cases for data transfer with RailML, I would not restrict flexibility at this point.

Best Regards
Heribert
Re: Meaning and usage of @shuntingTime [message #1944 is a reply to message #1927] Mon, 03 September 2018 12:18 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Heribert,

thank you for your reply. No objections from my side.

> 1. The values in <times> also have a scope: actual,
> calculated, published, scheduled etc.. The shuntingTime as
> attribute of <ocpTT> does not have this scope and the
> assignment would therefore be problematic.

Yes, I agree.

> 4. Since we have very different use cases for data transfer
> with RailML, I would not restrict flexibility at this
> point.

Ok. I agree that the question "what does @shuntingTime mean" can only be answered by a use case.

So far, we can only summarise that we have no known use case and do not know how to use @shuntingTime. So, I would not like to add any example.

However, we still should avoid to have two competing @shuntingTimes. So, there is still my suggestion to declare one or both as deprecated.

At the today's <TT> developer telephone conference, it was agreed to open a "ticket" to fix that at least one @shuntingTimes should become deprecated from a future railML <TT> version.

With best regards,
Dirk.
[railML2] Re: Meaning and usage of @shuntingTime [message #2447 is a reply to message #1944] Wed, 27 May 2020 16:38 Go to previous messageGo to next message
Vasco Paul Kolmorgen
Messages: 55
Registered: November 2004
Member
Dear all,

in the today's railML 3 developer meeting we discussed the shunting time
too. This reminded us to solve this this long-standing for railML 2.5 too.
Therefore I want to remind for the already opened ticket (see
https://trac.railml.org/ticket/343) and your opinion for railML 2.5 (in
this thread) and/or railML 3.2 (in a new thread).

Best regards,
--
Vasco Paul Kolmorgen - Governance Coordinator
railML.org (Registry of Associations: VR 5750)
Phone railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Am 03.09.2018 um 12:18 schrieb Dirk Bräuer:
> Dear Heribert,
>
> thank you for your reply. No objections from my side.
>
>> 1. The values in <times> also have a scope: actual,
>> calculated, published, scheduled etc.. The shuntingTime as
>> attribute of <ocpTT> does not have this scope and the
>> assignment would therefore be problematic.
>
> Yes, I agree.
>
>> 4. Since we have very different use cases for data transfer
>> with RailML, I would not restrict flexibility at this
>> point.
>
> Ok. I agree that the question "what does @shuntingTime mean" can only be answered by a use case.
>
> So far, we can only summarise that we have no known use case and do not know how to use @shuntingTime. So, I would not like to add any example.
>
> However, we still should avoid to have two competing @shuntingTimes. So, there is still my suggestion to declare one or both as deprecated.
>
> At the today's <TT> developer telephone conference, it was agreed to open a "ticket" to fix that at least one @shuntingTimes should become deprecated from a future railML <TT> version.
>
> With best regards,
> Dirk.
Re: [railML2] Re: Meaning and usage of @shuntingTime [message #2542 is a reply to message #2447] Mon, 28 September 2020 18:33 Go to previous message
Milan Wölke is currently offline  Milan Wölke
Messages: 139
Registered: April 2007
Senior Member
Hi all,

in the last timetable developer group meeting this issue was discussed. We decided that //ocpTT/@shuntingTime should be set deprecated. Additionally the wiki documentation for //ocpTT/stopDescription/stopTimes/@shuntingTime should be improved. This will be published with version 2.5 of railML.

Best regards, Milan


Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: Train Turnback Association
Next Topic: Attribute processStatus to be declared deprecated for <train>, <trainPart> and <trainGroup>
Goto Forum:
  


Current Time: Fri Mar 29 12:38:57 CET 2024