Difference between revisions of "TT:times"

From wiki.railML.org
Jump to: navigation, search
[unchecked revision][checked revision]
(Corrected usage of arrival at first and and departure at last <ocpTT> of a train as ordered by TOP13 of protocol of TT developer telco of 04.06.2018)
(Notes on trains with one <ocpTT> only added)
Line 69: Line 69:
  
 
[2] [[Dev:Examples for a non-zero operating day offset at the first ocpTT of a train run|Beispiele für Verkehrstage-Offsets ungleich 0 an der ersten <ocpTT> eines Zuglaufs]]}}
 
[2] [[Dev:Examples for a non-zero operating day offset at the first ocpTT of a train run|Beispiele für Verkehrstage-Offsets ungleich 0 an der ersten <ocpTT> eines Zuglaufs]]}}
 +
 +
===Train(part)s with one <ocpTT> only===
 +
Normally, each {{TT:Tag|train}} has at least one {{TT:Tag|trainPart}} with at least two {{TT:Tag|ocpTT}}s. However, it is allowed that a {{TT:Tag|trainPart}} has only one {{TT:Tag|ocpTT}}. In this special case, the above mentioned {{Attr|arrival}} at first and {{Attr|departure}} at last {{TT:Tag|ocpTT}} case applies at the same time: The train arrives from outside and immediately departs to outside the railML file. It just shortly "says hallo" to this railML file and away again. In very rare cases, this is used, for instance, to express only an occupation of a station track by a train which is not considered further. You can imagine a whole railML file which only expresses the station timetable of one station: All trains arrive from and depart to "nowhere". You should keep that special case in mind if you handle railML files on import.
  
 
|constraints =
 
|constraints =

Revision as of 19:07, 18 June 2018

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é

[1..1]

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.

Attributes of times / Attribute von times / Attributs de times

  • scope: the scope Possible values are:

Missinginformation.png In this article there is information missing with respect to attribute semantics of scope. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion pageVasco Paul Kolmorgen 11:27, 19 April 2018 (CET)
  • actual in the sense of "current"; timetable data, that the train generated by its run
  • 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

Missinginformation.png In this article there is information missing with respect to the semantics of the enumeration items. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion pageFerri Leberl (talk) 16:20, 25 April 2018 (CEST)
  • earliest
  • latest
  • 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.
  • 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: 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

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

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

Notes / Anmerkungen / Notes

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

Train(part)s with one <ocpTT> only

Normally, each <train> has at least one <trainPart> with at least two <ocpTT>s. However, it is allowed that a <trainPart> has only one <ocpTT>. In this special case, the above mentioned arrival at first and departure at last <ocpTT> case applies at the same time: The train arrives from outside and immediately departs to outside the railML file. It just shortly "says hallo" to this railML file and away again. In very rare cases, this is used, for instance, to express only an occupation of a station track by a train which is not considered further. You can imagine a whole railML file which only expresses the station timetable of one station: All trains arrive from and depart to "nowhere". You should keep that special case in mind if you handle railML files on import.

Open issues / Offene Punkte/Pedenzen / Questions ouvertes

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