| 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: 311
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
