| [railML2] Usage of //ocpTT/times/@scope [message #2492] |
Tue, 14 July 2020 15:37  |
Milan Wölke
Messages: 145
Registered: April 2007
|
Senior Member |
|
|
Hi community,
the railML's TT developer group has decided to clarify the documentation
on <trainPart/ocpsTT/ocpTT/times>@scope
(https://wiki2.railML.org/index.php?title=TT:times). In that regard we
first collected how <times> is used among the members of the developer
group. The following list describes the common understanding as of today:
"calculated": Times resulting from the running time simulation; not yet
communicated to a party.
"scheduled": Operational times agreed between IM and RU; the arrival and
departure time as operationally scheduled
"published": Customer related times communicated from the RU to the end
customer (passenger/freight forwarder/...; e.g an earlier departure time
than @scheduled which is communicated to the passengers).
Sometimes they could be also less precise than the @scheduled times,
e.g. scheduled times are precise down to the second, while published
times could be limited to minutes. Also published times are often
provided only for the ocpTTs of a train, where a difference between
@scheduled and @published occurs (to be confirmed by the community!).
"actual": Describes measured times that the train generated by its run.
So far we do not know of usage for the other enumeration values of
<trainPart/ocpsTT/ocpTT/times>@scope ("earliest" and "latest").
Which of the 6 values are you using in your tools and systems? What is
the current semantics in place?
You would help us a lot, if you could provide your understanding of
<times> in your tools, so we can see if we have a consensus and thus can
sharpen the documentation to improve understanding for new people using
railML. This also allows us to choose correct and clear modelling when
developing the TT section of railML 3.x.
Thanks in advance.
Best regards, Milan
--
Milan Wölke - Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany
Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
|
|
|
|
|
|
|
| Re: [railML2] Usage of //ocpTT/times/@scope [message #2501 is a reply to message #2492] |
Thu, 23 July 2020 15:07  |
Dirk Bräuer
Messages: 313
Registered: August 2008
|
Senior Member |
|
|
Dear Milan,
here the reply on the usage of <times>@scope in our ex- and imports:
We use
<times>.scope=scheduled for the operational times, obligatory
<times>.scope=published for possible different traffic (customer) times, optional
<times>.arrival+arrivalDay for arrival times, not existing where trains run-through and at the first <ocp> of a train's route
<times>.departure+departureDay for departure or run-through times, not existing at the last <ocp> of a train's route
So, in our exports, there is at least one and maximum two such elements <times> at each <ocpTT>.
In the same sense, we expect for imports
- that there is at least one element <times>.scope=scheduled at each <ocp> and
- that, in case there are more than one elements <times>, their .scope differs (is disjunct).
---
> "scheduled": Operational times agreed between IM and RU; the arrival and
> departure time as operationally scheduled
No, that is not the documented usage in our railML files. We use "scheduled" for all planning stages including slot orders (which are naturally not yet agreed by the IM). We understand "scheduled" simply as a synonym for "geplant".
I think that the original intended difference between "calculated" and "scheduled" was that "calculated" only refers to the pure run time calculation and "scheduled" to the actual planning. A planning includes practically always more than the pure (physical) run time. In that sense, "calculated" would be the same as what can be expressed by <sectionTT>.<runTimes @minimalTime>.
> "calculated": Times resulting from the running time simulation; not yet
> communicated to a party.
I think this could be a bit misleading since the occurrence of these times in a railML file is already a kind of communication to a party. I think the end of the sentence should only be "not yet published". But we could possibly declare "calculated" as deprecated.
---
> "published": Customer related times communicated from the RU to the end
> customer (passenger/freight forwarder/...; e.g an earlier departure time
> than @scheduled which is communicated to the passengers).
> Sometimes they could be also less precise than the @scheduled times,
> e.g. scheduled times are precise down to the second, while published
> times could be limited to minutes.
I agree.
---
> Also published times are often
> provided only for the ocpTTs of a train, where a difference between
> @scheduled and @published occurs (to be confirmed by the community!).
I even would declare this to a general rule: As long as there are no different "published times", the "scheduled times" are also valid for passenger information.
---
> So far we do not know of usage for the other enumeration values of
> <trainPart/ocpsTT/ocpTT/times>@scope ("earliest" and "latest").
I remember that there once was a discussion to use "earliest" and "latest" do define the "slot" which a train could have in it's timetable. But this would be redundant to reserves (supplements etc.) which already have their attributes. I think there should be a Wiki post clarifying that the timetable slot of a train has to be expressed by reserves and not by earliest and latest.
I think the original meaning behind earliest and latest was to express a rather large allowance in slot orders (and only in slot orders), so before the actual timetabling takes place. Such as "I want to arrive between 8 and 10 am." This happens in freight traffic orders, Deutsche Bahn explicitly allows such orders. So, this should be a question for the use case "slot ordering" (@Joachim?). If there is no need for "earliest" and "latest" in this already documented use case, we should declare it deprecated. Otherwise, we should limit it to that use case.
Best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
