TT:times ocpTT ocpsTT trainPart: Difference between revisions
| [checked revision] | [checked revision] |
(+Tabelle) |
(Moved TT:011 to best practivce as decided in TT developer meeting) |
||
| Line 49: | Line 49: | ||
{{Deu|{{@|scope}}='earliest' und 'latest' sind ''nicht'' zur Abbildung von Fahrzeitzuschlägen zu verwenden, da dies redundant zu <ocpTT>.<sectionTT>.<runTimes>@operationalReserve, @additionalReserve, @minimalTime ist.}} | {{Deu|{{@|scope}}='earliest' und 'latest' sind ''nicht'' zur Abbildung von Fahrzeitzuschlägen zu verwenden, da dies redundant zu <ocpTT>.<sectionTT>.<runTimes>@operationalReserve, @additionalReserve, @minimalTime ist.}} | ||
|status=approved|proposed=2019-06-19|approved=2020-10-15|forum=https://www.railml.org/forum/index.php?t=msg&th=588&goto=1848&#msg_1848|id=TT:010}} | |status=approved|proposed=2019-06-19|approved=2020-10-15|forum=https://www.railml.org/forum/index.php?t=msg&th=588&goto=1848&#msg_1848|id=TT:010}} | ||
{{semcon| | {{semcon| | ||
When {{@|scope}}='actual' is used, then the operating period and/or timetable period specified at the trainpart level shall refer to only one operating day. Like this the operating day to which the actual times refer is defined. | When {{@|scope}}='actual' is used, then the operating period and/or timetable period specified at the trainpart level shall refer to only one operating day. Like this the operating day to which the actual times refer is defined. | ||
| Line 71: | Line 65: | ||
|example = | |example = | ||
===Semantics and restrictions of the attribute {{Attr|scope}}=== | ===Semantics and restrictions of the attribute {{Attr|scope}}=== | ||
===={{Attr|scope}} values 'earliest' and 'latest'==== | ====Consistency expectations==== | ||
In general it is expected that all {{TT:Tag|times}} instances of the same {{@|scope}} are consistent with each other. "consistent with each other" in this context means, that the times following the path of the train are continuously increasing. The reason for this is that it is assumed that all {{TT:Tag|times}} instances of the same {{@|scope}} are semantically linked. However, there are use cases where this may not apply. For example {{TT:Tag|times}} with the {{@|scope}} {{Enum|earliest}} or {{Enum|latest}} may encode inconsistencies as described below. Also for {{Enum|published}} {{TT:Tag|times}} it is known that in some cases consistency is broken. In some use cases this can also happen in other {{@|scope}}s, for example if railML is used as a means of transferring data from a planning system to a visualization with the express purpose of viewing inconsistencies graphically. It is acceptable practice though to refuse importing of such data in reading programs if such use case is excluded. A appropriate error reporting is advised in this case. | |||
{{Deu|Im Allgemeinen wird erwartet, dass alle {{TT:Tag|times}}-Instanzen desselben {{@|scope}} miteinander konsistent sind. "Miteinander konsistent" bedeutet in diesem Zusammenhang, dass die Zeiten, dem Zuglauf folgend, kontinuierlich ansteigen. Der Grund dafür ist, dass angenommen wird, dass alle {{TT:Tag|times}}-Instanzen desselben {{@|scope}} semantisch miteinander verbunden sind. Es gibt jedoch Anwendungsfälle, auf die dies nicht zutrifft. Zum Beispiel {{TT:Tag|times}} mit dem {{@|scope}} {{Enum|earliest}} oder {{Enum|latest}} kodieren möglicherweise Inkonsistenzen, wie beispielsweise unten beschrieben. Auch für {{Enum|published}} {{TT:Tag|times}} ist bekannt, dass in einigen Fällen die Konsistenz gebrochen wird. In einigen Anwendungsfällen kann dies auch in anderen {{@|scope}}s vorkommen, z.B. wenn railML als Mittel zur Übertragung von Daten aus einem Planungssystem in eine Visualisierung mit dem ausdrücklichen Zweck verwendet wird, Inkonsistenzen grafisch darzustellen. Es ist jedoch akzeptierte Praxis, den Import solcher Daten in Leseprogrammen zu verweigern, wenn ein solcher Anwendungsfall ausgeschlossen ist. In diesem Fall wird eine entsprechende Fehlermeldung empfohlen.}} | |||
====={{Attr|scope}} values 'earliest' and 'latest'===== | |||
As just explained it is in general assumed that the {{TT:Tag|times}} specified for {{Enum|earliest}} and {{Enum|latest}} at one {{tag|TT|ocpTT}} should be consistent with each other. Accordingly the times specified for {{Enum|earliest}} (taking into account {{@|arrivalDay}} and {{@|departureDay}}) must be earlier than those specified for {{Enum|latest}}. Only in very rare cases this assumption is broken. For example in strategic planning it may be necessary to communicate impossibilities that result from various dependencies in order for the receiving system to adjust accordingly to avoid those impossibilities. | |||
{{Deu|Wie soeben erläutert, wird im Allgemeinen davon ausgegangen, dass die für {{Enum|earliest}} und {{Enum|latest}} an einem {{tag|TT|ocpTT}} angegebenen {{TT:Tag|times}} miteinander harmonieren sollten. Dementsprechend sollten die für {{Enum|earliest}} angegebenen Zeiten (unter Berücksichtigung von {{@|arrivalDay}} und {{@|departureDay}}) früher sein als die für {{Enum|latest}} angegebenen Zeiten. Nur in sehr seltenen Fällen wird diese Annahme gebrochen. Zum Beispiel kann es bei der strategischen Planung notwendig sein, Unmöglichkeiten mitzuteilen, die sich aus verschiedenen Abhängigkeiten ergeben, damit das empfangende System entsprechende Anpassungen vornehmen kann, um diese Unmöglichkeiten zu vermeiden. | |||
====Slot ordering / {{Deu|Trassenbestellung}}==== | ====Slot ordering / {{Deu|Trassenbestellung}}==== | ||
In the use case ''slot ordering'' the attributes 'earliest' and 'latest' are intended to define a wish of a RU or authority as customer of an IM. The customer likes to order a slot with the earliest departure at... or with the latest arrival at... Therefore, 'earliest' and 'latest' are related here to early planning states because they define something like the "first idea" of the timetable of a train. | In the use case ''slot ordering'' the attributes 'earliest' and 'latest' are intended to define a wish of a RU or authority as customer of an IM. The customer likes to order a slot with the earliest departure at... or with the latest arrival at... Therefore, 'earliest' and 'latest' are related here to early planning states because they define something like the "first idea" of the timetable of a train. | ||
Revision as of 18:21, 14 July 2022
{{ElementDocu| elementName = times
|semantics = The Element <times> describes arrival and departure times of a train with their scope.
Das Element <times> beschreibt Ankunfts- und Abfahrtszeiten eines Zuges und ihre Interpretation.
|parent = <ocpTT> |childs=None |minocc=0 |maxocc=∞ |inheritedAttributes=None |ownAttributes =
- scope: The attribute @scope is used to distinguish different <times> elements at the same parent <ocpTT>. Typically, they refer to different planning or operating stages (comp. #Semantics and restrictions of the attribute scope).
Das attribute @scope wird verwendet, um verschiedene <times> Elemente am selben übergeordneten Element unterscheiden zu können. Typischerweise beziehen sich die Werte auf unterschiedliche Planungs- bzw. Betriebsstadien (vgl. #Semantics and restrictions of the attribute scope).
- Possible values are:
- actual recorded arrival and departure times
- calculated times from a simulation tool
- published times that the passengers get on written sheets or online
- scheduled times for operational purposes
- earliest acceptable arrival and/or departure time (used to express a wish of a customer at a very early planning stage of a new timetable)
- latest acceptable arrival and/or departure time (used to express a wish of a customer at a very early planning stage of a new timetable)
- expected (introduced with version 2.5) forecast times based on realtime data
- other:anything: Any value that does not fit any value from the previous enumeration list, fulfilling the constraint: at minimum two characters, whitespace is not allowed. Please, apply Dev:usingAny accordingly.
|
|
- arrival: Moment at which the train ends its movement and gets to a halt at the parent <ocpTT>; usually called arrival time.
- If this attribute is set at the first <ocpTT> of a <trainPart> that is also the first of the <trainPartSequence> of all <train>s it belongs to, it shall describe an "arrival from outside of the scope of the railML file": It expresses that the train arrives at that first <ocpTT> at the given time, but the railML file does not express from where the train arrives nor whether it arrives as a train movement at all or rather as a shunting movement.
- arrivalDay: arrival on the n-th day, with train (but not necessarily the parent trainPart) starting on day 0 at its first departure. To learn, how to handle values ≠0, see How to indicate midnight overruns in railML.
- departure: departure or run-through (passing) time;
- normally specified at all except the very last station of the last trainPart (section) of a train:
- If this attribute is set at the last <ocpTT> of a <trainPart> that is also the last of the <trainPartSequence> of all <train>s it belongs to, it shall describe "departure to outside of the scope of the railML file": It expresses that the train departs at that last <ocpTT> at the given time, but the railML file does not express to where the train departs nor whether it departs as a train movement at all or rather as a shunting movement.
- departureDay: departure on the n-th day, with <train> (but not necessarily the parent <trainPart>) starting on day 0 at its first departure. To learn, how to handle values ≠0, see How to indicate midnight overruns in railML.
- xs:anyAttribute: This provides an extension point for non-railML® attributes in a foreign namespace. How to use it?
(introduced with version 2.2)
|semcon=
|
|
|
|
|
|example =
Semantics and restrictions of the attribute scope
Consistency expectations
In general it is expected that all <times> instances of the same @scope are consistent with each other. "consistent with each other" in this context means, that the times following the path of the train are continuously increasing. The reason for this is that it is assumed that all <times> instances of the same @scope are semantically linked. However, there are use cases where this may not apply. For example <times> with the @scope earliest or latest may encode inconsistencies as described below. Also for published <times> it is known that in some cases consistency is broken. In some use cases this can also happen in other @scopes, for example if railML is used as a means of transferring data from a planning system to a visualization with the express purpose of viewing inconsistencies graphically. It is acceptable practice though to refuse importing of such data in reading programs if such use case is excluded. A appropriate error reporting is advised in this case.
Im Allgemeinen wird erwartet, dass alle <times>-Instanzen desselben @scope miteinander konsistent sind. "Miteinander konsistent" bedeutet in diesem Zusammenhang, dass die Zeiten, dem Zuglauf folgend, kontinuierlich ansteigen. Der Grund dafür ist, dass angenommen wird, dass alle <times>-Instanzen desselben @scope semantisch miteinander verbunden sind. Es gibt jedoch Anwendungsfälle, auf die dies nicht zutrifft. Zum Beispiel <times> mit dem @scope earliest oder latest kodieren möglicherweise Inkonsistenzen, wie beispielsweise unten beschrieben. Auch für published <times> ist bekannt, dass in einigen Fällen die Konsistenz gebrochen wird. In einigen Anwendungsfällen kann dies auch in anderen @scopes vorkommen, z.B. wenn railML als Mittel zur Übertragung von Daten aus einem Planungssystem in eine Visualisierung mit dem ausdrücklichen Zweck verwendet wird, Inkonsistenzen grafisch darzustellen. Es ist jedoch akzeptierte Praxis, den Import solcher Daten in Leseprogrammen zu verweigern, wenn ein solcher Anwendungsfall ausgeschlossen ist. In diesem Fall wird eine entsprechende Fehlermeldung empfohlen.
scope values 'earliest' and 'latest'
As just explained it is in general assumed that the <times> specified for earliest and latest at one <ocpTT> should be consistent with each other. Accordingly the times specified for earliest (taking into account @arrivalDay and @departureDay) must be earlier than those specified for latest. Only in very rare cases this assumption is broken. For example in strategic planning it may be necessary to communicate impossibilities that result from various dependencies in order for the receiving system to adjust accordingly to avoid those impossibilities.
{{{1}}}
- ↑ Fahrerassistenzsystem (FAS) (
)
- ↑ Betriebsleitsystem (RBL):de:Rechnergestütztes_Betriebsleitsystem de:Rechnergestütztes Betriebsleitsystem ( Rechnergestütztes Betriebsleitsystem (RBL))