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: 251
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 message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 251
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.
Previous Topic: train stablings
Goto Forum:
  


Current Time: Fri Sep 21 00:17:17 CEST 2018