Difference between revisions of "TT:times"

From wiki.railML.org
Jump to: navigation, search
[checked revision][checked revision]
(added german translation of semantic constraint)
(+id)
 
Line 53: Line 53:
 
* Es muss akzeptiert werden, dass {{TT:Tag|ocpTT}}.{{TT:Tag|times}} Elemente mit unterschiedlichen Werten für {{@|scope}} untereinander nicht konsistent sein müssen. Ein Zug mag bei der Trassenbestellung für eine bestimmte Zeit bestellt sein, allerdings kann es sein, dass dieser Wunsch nicht erfüllt werden kann, und der Zug zu einer anderen Zeit fährt.
 
* Es muss akzeptiert werden, dass {{TT:Tag|ocpTT}}.{{TT:Tag|times}} Elemente mit unterschiedlichen Werten für {{@|scope}} untereinander nicht konsistent sein müssen. Ein Zug mag bei der Trassenbestellung für eine bestimmte Zeit bestellt sein, allerdings kann es sein, dass dieser Wunsch nicht erfüllt werden kann, und der Zug zu einer anderen Zeit fährt.
 
* Wenn {{@|scope}}= 'actual' verwendet wird, muss die übergeordnete operating period und/oder timetable period des train(part) nur einen einzelnen Betriebstag referenzieren. Es muss festgelegt werden, auf welchen Betriebstag sich die erfassten Ist-Zeiten beziehen.
 
* Wenn {{@|scope}}= 'actual' verwendet wird, muss die übergeordnete operating period und/oder timetable period des train(part) nur einen einzelnen Betriebstag referenzieren. Es muss festgelegt werden, auf welchen Betriebstag sich die erfassten Ist-Zeiten beziehen.
* {{@|scope}}='Earliest' und 'latest' werden im Use Case Trassenbestellung verwendet um die gewünschte Zeit für den Zug zu beschreiben: Der Kunde möchte eine Trasse mit der frühesten Abfahrt an X oder der spätesten Ankunft an Y bestellen. Entsprechend beziehen sich 'earliest' und 'latest' auf sehr frühe Planungsphasen, bei denen eine erste Idee eines Zugfahrplans ausgetauscht wird. Bei der Beschreibung einer solchen Idee macht es nur Sinn am ersten oder letzten {{TT:Tag|ocpTT}} {{TT:Tag|times}} anzugeben. Das impliziert auch, dass nur für einen einzigen {{TT:Tag|ocpTT}} Zeiten angegeben werden sollten. Alle anderen {{TT:Tag|ocpTT}} können angegeben werden um die gewünschte Route zu definieren, sind aber nur ohne angegebene Zeiten sinnvoll. Anderenfalls müsste erklärt werden, wie Widersprüche zwischen unterschiedlichen 'earliest' und 'latest' Angaben des selben Zuges zu verstehen sind. Ein weiterer Use Case, bei dem 'earliest' und 'latest' zum Einsatz kommen können ist Fahrplan Simulation. 'Earliest' und 'latest' können hier verwendet werden, um entweder die Eingangsdaten für eine Simulation zu beschreiben, oder aber die Ergebnisse der Simulation an ein Fahrplanplanungstool weiterzugeben.}}|status=proposed|proposed=2019-06-19}}
+
* {{@|scope}}='Earliest' und 'latest' werden im Use Case Trassenbestellung verwendet um die gewünschte Zeit für den Zug zu beschreiben: Der Kunde möchte eine Trasse mit der frühesten Abfahrt an X oder der spätesten Ankunft an Y bestellen. Entsprechend beziehen sich 'earliest' und 'latest' auf sehr frühe Planungsphasen, bei denen eine erste Idee eines Zugfahrplans ausgetauscht wird. Bei der Beschreibung einer solchen Idee macht es nur Sinn am ersten oder letzten {{TT:Tag|ocpTT}} {{TT:Tag|times}} anzugeben. Das impliziert auch, dass nur für einen einzigen {{TT:Tag|ocpTT}} Zeiten angegeben werden sollten. Alle anderen {{TT:Tag|ocpTT}} können angegeben werden um die gewünschte Route zu definieren, sind aber nur ohne angegebene Zeiten sinnvoll. Anderenfalls müsste erklärt werden, wie Widersprüche zwischen unterschiedlichen 'earliest' und 'latest' Angaben des selben Zuges zu verstehen sind. Ein weiterer Use Case, bei dem 'earliest' und 'latest' zum Einsatz kommen können ist Fahrplan Simulation. 'Earliest' und 'latest' können hier verwendet werden, um entweder die Eingangsdaten für eine Simulation zu beschreiben, oder aber die Ergebnisse der Simulation an ein Fahrplanplanungstool weiterzugeben.}}|status=proposed|proposed=2019-06-19|id=TT:010}}
 
|notes =  
 
|notes =  
 
===Semantics and restrictions of the attribute {{Attr|scope}}===
 
===Semantics and restrictions of the attribute {{Attr|scope}}===

Latest revision as of 15:37, 9 July 2019

times
 


Scheme description / Schemenbeschreibung / Description du schéma

Position of times in the XML-Tree / Position von times im XML-Baum / position de times dans l’aborescence XML

  • Children: None

Multiplicity / Anzahl / Multiplicité

[0..∞]

Semantics / Bedeutung / Sémantique

The Element <times> describes arrival and departure times with their scope.

Das Element <times> beschreibt Ankunfts- und Abfahrtszeiten und ihre Interpretation.
 
Please, be aware of the semantic constraint(s)!

Attributes of times / Attribute von times / Attributs de times

  • scope: the scope Possible values are:
  • actual in the sense of "current"; timetable data, that the train generated by its run; see also remarks below
  • calculated timetable data, calculated by a simulation tool
  • published timetable data, that the passenger gets on written sheets or online
  • scheduled timetable data, that the train driver gets in written or electronic form
  • earliest used to express a wish of a customer at a very early planning stage of a train when there is not yet a detailed timetable: The train shall leave the parent <ocpTT> not earlier than at the given departure time. Not to be used to encode the supplement of a run time. See also remarks below.
  • latest used to express a wish of a customer at a very early planning stage of a train when there is not yet a detailed timetable: The train shall arrive at the parent <ocpTT> not later than at the given arrival time. Not to be used to encode the supplement of a run time. See also remarks below.
  • 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.
Note.png Not to be confused with <train>@scope, that distinguishes different pathes of a train.
  • arrival: arrival time;
    • not to be specified if the attribute ocpType of the parent <ocpTT> has the value pass - use departure for run-through (passing) times;
    • At the first <ocpTT> of a <trainPart> that is not the first one of the <trainPartSequence>, the attribute is optional. If it is set and there are predecessor <trainPart>s, then the value of the arrival attribute of the corresponding <ocpTT>s must be equal to the value at this <trainPart>.
    • 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 means "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.
  • 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 means "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.
    • At the last <ocpTT> of a <trainPart> that is not the last one of the <trainPartSequence>, the attribute is optional. If it is set and there are successor <trainPart>s, then the value of the departure attribute of the corresponding <ocpTT>s must be equal to the value at this <trainPart>.
  • xs:anyAttribute: This provides an extension point for non-railML attributes in a foreign namespace. How to use it?
    (introduced with version 2.2)

Syntactic Constraints / Syntaktische Beschränkungen / Contraintes syntactiques

  • scope: tTimeScope (union of (restriction of xs:string, tOtherEnumerationValue); tOtherEnumerationValue is an arbitrary string starting with 'other:' followed by at minimum two characters, white space not allowed for extending railML enumeration lists); mandatory
  • arrival: xs:time; optional
  • arrivalDay: xs:integer; default: 0; optional
  • departure: xs:time; optional
  • departureDay: xs:integer; default: 0; optional

Semantic Constraints / Semantische Beschränkungen / Contraintes semantiques

Private-cloud-icon.png Proposed Semantic Constraint "TT:010":
 
Semantics and restrictions of the attribute @scope
The attribute @scope is used to distinguish different <times> elements at the same parent <ocpTT>. Typically, they refer to different planning stages: While 'scheduled' and 'published' are later planning stages and 'actual' is probably the latest because the train is already running, 'earliest' and 'latest' are early planning states because they define something like the "first idea" of the timetable of a train.
 
Therefore, the following semantical constraints apply:
  • All elements <ocpTT>.<times> with the same @scope of the same <trainPart> define the same planning stage and are therefore semantically linked equally and shall be consistent.
  • It must be accepted that elements <ocpTT>.<times> with different @scope are not necessarily consistent between each other: A train may be ordered for a “wished” time but not all those requests may be fulfilled. A train may be planned to a certain time but may run to a different (later or earlier).
  • When @scope='actual' is used, the higher level operating period and/or timetable period of the train(part) shall refer to only one certain operating day. It must be clarified semantically the actual times of which actual operating day (if more than one) are mentioned.
  • @scope='Earliest' and 'latest' are intended to define a "wish" of a customer in the use case of "slot ordering": The customer likes to order a slot with the earliest departure at... or with the latest arrival at... Therefore, 'earliest' and 'latest' are related to early planning states because they define something like the "first idea" of the timetable of a train. When addressing a wish of an earliest departure or latest arrival, this makes sense only at the very first / last <ocpTT> and implies to give only one <ocpTT> with <times>. All other <ocpTT>s may be given to define the wished route but do only make sense without <times>. Otherwise, it must be clarified semantically how any objections between concurring earliest/latest times of the same train are to be understood. Another use case 'earliest' and 'latest' can be used for is timetable simulation. 'Earliest' and 'latest' can be used here to either specify the input for a simulation or as output of a simulation run to transfer the results to a subsequent scheduling tool.

Das attribute @scope wird verwendet um verschiedene <times> Elemente am selben übergeordneten Element unterscheiden zu können. Typischerweise beziehen sich die Werte auf unterschiedliche Zustände des Planungsprozess: Während 'scheduled' und 'published' sich auf späte Zustände des Planungsprozess beziehen und 'actual' den vermutlich spätesten - da der Zug zu in diesem Zustand ja bereits unterwegs ist - , beziehen sich 'earliest' und 'latest' auf frühe Planungsphasen, da sie eine erste Idee des Fahrplans eines Zuges darstellen. Entsprechend gelten folgende semantischen Abhängigkeiten:

  • Alle <ocpTT>.<times> Elemente mit dem selben @scope des selben <trainPart> beschreiben die gleiche Planungsphase, sind entsprechend semantisch verknüpft und müssen demzufolge in sich konsistent sein.
  • Es muss akzeptiert werden, dass <ocpTT>.<times> Elemente mit unterschiedlichen Werten für @scope untereinander nicht konsistent sein müssen. Ein Zug mag bei der Trassenbestellung für eine bestimmte Zeit bestellt sein, allerdings kann es sein, dass dieser Wunsch nicht erfüllt werden kann, und der Zug zu einer anderen Zeit fährt.
  • Wenn @scope= 'actual' verwendet wird, muss die übergeordnete operating period und/oder timetable period des train(part) nur einen einzelnen Betriebstag referenzieren. Es muss festgelegt werden, auf welchen Betriebstag sich die erfassten Ist-Zeiten beziehen.
  • @scope='Earliest' und 'latest' werden im Use Case Trassenbestellung verwendet um die gewünschte Zeit für den Zug zu beschreiben: Der Kunde möchte eine Trasse mit der frühesten Abfahrt an X oder der spätesten Ankunft an Y bestellen. Entsprechend beziehen sich 'earliest' und 'latest' auf sehr frühe Planungsphasen, bei denen eine erste Idee eines Zugfahrplans ausgetauscht wird. Bei der Beschreibung einer solchen Idee macht es nur Sinn am ersten oder letzten <ocpTT> <times> anzugeben. Das impliziert auch, dass nur für einen einzigen <ocpTT> Zeiten angegeben werden sollten. Alle anderen <ocpTT> können angegeben werden um die gewünschte Route zu definieren, sind aber nur ohne angegebene Zeiten sinnvoll. Anderenfalls müsste erklärt werden, wie Widersprüche zwischen unterschiedlichen 'earliest' und 'latest' Angaben des selben Zuges zu verstehen sind. Ein weiterer Use Case, bei dem 'earliest' und 'latest' zum Einsatz kommen können ist Fahrplan Simulation. 'Earliest' und 'latest' können hier verwendet werden, um entweder die Eingangsdaten für eine Simulation zu beschreiben, oder aber die Ergebnisse der Simulation an ein Fahrplanplanungstool weiterzugeben.
     
    Proposed on June 19th 2019
    Please, recognize our guidelines on semantic constraints

Best practice & Examples / Empfohlene Anwendung & Beispiele / Bonnes pratiques & exemples

Not yet described. / Noch nicht beschrieben. / Pas encore décrit.

Notes / Anmerkungen / Notes

Semantics and restrictions of the attribute scope

Please note that 'earliest' and 'latest' are not intended to encode the "slot" every timetable has by its supplement: They are not to be used as a redundancy to <ocpTT>.<sectionTT>.<runTimes>.operationalReserve, additionalReserve, minimalTime. It is a matter of course that every timetable defines a "slot" of times rather than an exact time - 'run time' is a random variable in a physical sense – so to express this volatility, use the above mentioned attributes of the element <runTimes>.

Example:

      <trainPart id='tp_1' >
        <operatingPeriodRef ref='opp_once_a_day'/>
        <ocpsTT>
          <ocpTT sequence='1' ocpRef='ocp_A' ocpType='stop'>
            <times scope='earliest' departure='16:30'/>
            <times scope='scheduled' departure='16:31:18'/>
            <times scope='published' departure='16:30'/>
            <times scope='actual' departure='16:39:10'/>
          </ocpTT>
          <ocpTT sequence='2' ocpRef='ocp_B' ocpType='pass'>
            <times scope='scheduled' departure='16:38:02.46'/>
            <times scope='actual' departure='16:45:27'/>
          </ocpTT>
          <ocpTT sequence='3' ocpRef='ocp_C' ocpType='stop'>
            <times scope='latest' arrival='16:55'/>
            <times scope='scheduled' arrival='16:49:12.46'/>
            <times scope='published' arrival='16:50'/>
            <times scope='actual' arrival='16:56:02'/>
          </ocpTT>
      </trainPart>

The train part runs from ocp_A via ocp_B to ocp_C. Originally there was an order saying the train shall leave ocp_A at the earliest at 16:30 hours and shall arrive at ocp_C not later than 16:55 hours. Only the use case can clarify whether the time difference between 16:30 and 16:55 must be greater than the actual minimum run time or which priority applies in case of any discrepancy.

The train was scheduled to leave ocp_A at 16:31:18, to pass ocp_B at 16:38 and to arrive at ocp_C at 16:49. But, the published departure time at ocp_A was 16:30, so one minute earlier than scheduled and just in time of the 'earliest' limit. The published arrival was 16:50, so rounded up to the next full minute, probably to be “on the safe side”.

Finally, the train did actually leave ocp_A at 16:39:10, so 8 minutes late (even 9 mins related to the published time). It did pass ocp_B at 16:45, still 7 mins late and did arrive at ocp_C at 16:56, also 7 mins late. So, it did fail to reach the “latest” arrival limit – we have to accept a discrepancy between ‘latest’ and ‘actual’ at ocp_C. The <operatingPeriodRef>='opp_once_a_day' of the <trainPart> must clarify to which certain day the actual times refer.

Handling midnight overruns/Umgang mit Mitternachtsübergängen

→Main Article: How to indicate midnight overruns in railML

The attributes arrivalDay and departureDay are a counting of the number of midnight overruns relatively to a reference place (e. g. departure, see below). These attributes are optional with default value 0, e. g they do not have to be written as long as a train didn’t run over midnight. But, after the first run over midnight, they must be written with values >0.

It is intended that the arrival/departureDay counting starts with 0 at the first departure of a train. Therefore, the value -1 can occur in rare cases of an arrival before the first departure (“arrival from nowhere”, from outside the scope of the railML file). In case a train did already run over midnight before the first departure in the railML data, this first <ocpTT> may also have an arrival/departureDay >0.

If a <train> consists of several <trainPart>s which are sequentially linked, the day counting normally refers to the first departure of the whole <train>. So, it may happen that single <trainParts> already start with day counting >0.

A “back-jump” of the day counting may happen especially from the view of a commercial train (<train> with type=’commercial’): This means that the train first refers to <trainPart>s which did run over midnight and later refers to <trainPart>s which did not run over midnight.

For more information, see:
[1] How to indicate midnight overruns in railML
[2] Examples for a non-zero operating day offset at the first ocpTT of a train run

Die Attribute arrivalDay und departureDay stellen eine Zählung der Anzahl Mitternachtsübergänge relativ zu einem Bezugspunkt (s. u.) dar. Diese Attribute sind optional mit Default-Wert 0, d. h. sie müssen solange nicht angegeben werden, solange ein Zug noch nicht über Mitternacht gefahren ist. Nach dem ersten Mitternachtsübergang, d. h. sobald ihr Wert >0 ist, sind sie jedoch anzugeben.

Es ist vorgesehen, dass die Tages- bzw. Mitternachtszählung (arrival/departureDay) an der ersten Abfahrt eines Zuges mit 0 beginnt. Demzufolge kann der Wert -1 vorkommen bei der ersten Ankunft im seltenen Fall, dass der Zug am ersten Bahnhof über Mitternacht steht und zuvor „von außerhalb“ kommt. Sollte der Zug bereits vor dem ersten abgebildeten Abfahrtsbahnhof – quasi „im Ausland“ – über Mitternacht gefahren sein, darf diese erste <ocpTT> ebenfalls einen Tagesindex (arrival/departureDay) >0 aufweisen.

Wenn ein Zug aus mehreren (zu aufeinanderfolgenden Abschnitten verketteten) Zugteilen besteht, bezieht sich die Tageszählung i. d. R. auf den ersten Abfahrtsort des Gesamtzuglaufs. Bei einzelnen Zugteilen kann es also vorkommen, dass diese bereits mit Tageszählung >0 beginnen.

Wenn Zugteilläufe (in railML: commercial trains) von einem Zug auf einen anderen übergehen, kann es zu einem „Rückschritt“ der Tageszählung von >0 auf =0 kommen. Dies bedeutet, dass Zugteillauf von einem Zug, der bereits über Mitternacht gefahren ist, übergeht auf einen Zug, der noch nicht über Mitternacht gefahren ist.

Für weitere Infomationen hierzu s.

[1] Abbildung von Mitternachtsübergängen in railML

[2] Beispiele für Verkehrstage-Offsets ungleich 0 an der ersten <ocpTT> eines Zuglaufs

Open issues / Offene Punkte/Pedenzen / Questions ouvertes

Not yet described. / Noch nicht beschrieben. / Pas encore décrit.