Dev:Midnight overrun

This article explains, how to handle midnight overruns within the timetable subschema.

Dieser Artikel erklärt dem Umgang mit Mitternachtsübergängen im Timetable-Subschema.

Midnight overruns in railML^® / Abbildung von Mitternachtsübergängen in railML^®

General / Allgemeines

Midnight overruns in general have two aspects to be considered:

• the time of two consecutive arrivals/departures jumps back (e.g. from '23:57:53' to '00:00:19'). This has to be considered when calculating total run times of a train run.
• arrivals/departures of a <trainPart> after midnight will take place on a different day than before midnight related to its <operatingPeriod>. Since there is only one <operatingPeriod> per <trainPart>, there has to be a means to determine the actual days, when a <trainPart> arrives/departs at a certain <ocpTT>.

It is not intended to split the train’s run into a <trainPart> before and another after midnight and to create separate <operatingPeriod>s for both. Instead of that, the different operating days of the <trainPart> before and after midnight are expressed using different values for the attributes arrivalDay and departureDay. These attributes represent the day offset of the arrival/departure of a <trainPart>'s <ocpTT> in respect of its <operatingPeriod>. For operational trains (<train> with type='operational') they are a counting of the number of midnight overruns relatively to a reference place (e. g. departure, see below). They 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.

Mitternachtsübergänge im Allgemeinen weisen zwei zu betrachtende Aspekte auf:

• Die Zeiten zweier aufeinanderfolgender Ankünfte/Abfahrten springen zurück (z.B. von '23:57:53' auf '00:00:19'). Dies spielt eine Rolle bei der Berechnung der Gesamtfahrzeit eines Zuglaufs.
• Ankünfte/Abfahrten eines <trainPart>s nach Mitternacht finden an einem anderen Tag statt als vor Mitternacht bezogen auf die <operatingPeriod>. Da nur eine <operatingPeriod> pro <trainPart> existiert, sind zusätzliche Mittel notwendig, um die tatsächlichen Tage zu bestimmen, an denen ein <trainPart> an einer <ocpTT> ankommt bzw. abfährt.

Es ist nicht vorgesehen, den Zuglauf in einen <trainPart> vor und einen nach Mitternacht zu teilen und für beide individuelle <operatingPeriod>s zu erzeugen. Stattdessen werden die unterschiedlichen Verkehrstage des <trainPart>s vor und nach Mitternacht durch unterschiedliche Werte in den Attributen arrivalDay and departureDay abgebildet. Diese Attribute drücken die Verschiebung des Tages der Ankünfte/Abfahrten eines <trainPart>s an einer bestimmten <ocpTT> in Bezug auf seine <operatingPeriod> aus. Für betriebliche Züge (<train> mit type='operational') stellen sie eine Zählung der Anzahl Mitternachtsübergänge relativ zu einem Bezugspunkt (z. B. Abfahrtsort; s. u.) dar. Sie 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.

Example 1: Midnight overruns during an intermediate stop / Beispiel 1: Mitternachtsübergang während eines Zwischenaufenthalts

  <operatingPeriod id='opp_1' name='Mon-Fri' timetablePeriodRef='…'
	 bitMask='011111001111100…00111110'>
    <operatingDay operatingCode='1111100' />
  </operatingPeriod>

  <trainPart id='tp_1_of_train_1'>
    <operatingPeriodRef ref='opp_1'/>
    <ocpsTT>
      <ocpTT ocpRef='ocp_DNKW_A' ocpType='pass'>
        <times scope='scheduled' departure='23:55:35'/>
      </ocpTT>
      <ocpTT ocpRef='ocp_DNKO' ocpType='stop'>
!--                                                | here midnight overrun 
!--                                                v 
        <times scope='scheduled' arrival='23:57:53' departure='00:00:19' departureDay='1'/>
      </ocpTT>
      <ocpTT ocpRef='ocp_DWT' ocpType='stop'>
        <times scope='scheduled' arrival='00:02:17' arrivalDay='1' departure='00:03:00' departureDay='1'/>
      </ocpTT>
    <ocpsTT>
  </trainPart>

All further arrival, departure, and run through times of the (operational) train until the end of its route are marked with arrivalDay=1 and departureDay=1. Although the <operatingPeriod> states, that the <trainPart> runs from Monday to Friday, the actual operating periods of the arrivals/departures with an arrivalDay/departureDay=1 have to be interpreted as shifted by 1 day, i.e. as "Tuesday to Saturday"

Alle weiteren Ankunfts-, Abfahrts- und Durchfahrtszeiten des (betrieblichen) Zuges bis zu seinem Laufwegende sind mit arrivalDay=1 und departureDay=1 gekennzeichnet. Obwohl die <operatingPeriod> angibt, dass der <trainPart> von Montag bis Freitag verkehrt, müssen die tatsächlichen Verkehrstageregelungen der Ankünfte/Abfahrten mit einem arrivalDay/departureDay=1 als um einen Tag verschoben, d.h. als "Dienstag-Samstag" interpretiert werden.

Example 2: Midnight overrun while in motion / Beispiel 2: Mitternachtsübergang während der Fahrt

  <operatingPeriod id='opp_1' name='Mon-Fri' timetablePeriodRef='…'
	 bitMask='011111001111100…00111110'>
    <operatingDay operatingCode='1111100' />
  </operatingPeriod>

  <trainPart id='tp_1_of_train_1'>
    <operatingPeriodRef ref='opp_1'/>
    <ocpsTT>
      <ocpTT ocpRef='ocp_DNKW_A' ocpType='pass'>
        <times scope='scheduled' departure='23:55:35'/>
      </ocpTT>
      <ocpTT ocpRef='ocp_DNKO' ocpType='stop'>
        <times scope='scheduled' arrival='23:57:53' departure='23:58:23'/>
      </ocpTT>
!-- here midnight overrun --
      <ocpTT ocpRef='ocp_DWT' ocpType='stop'>
        <times scope='scheduled' arrival='00:02:17' arrivalDay='1' departure='00:03:00' departureDay='1'/>
      </ocpTT>
    <ocpsTT>
  </trainPart>

All further arrival, departure, and run through times of the (operational) train until the end of its route are marked with arrivalDay=1 and departureDay=1.
Alle weiteren Ankunfts-, Abfahrts- und Durchfahrtszeiten des (betrieblichen) Zuges bis zu seinem Laufwegende sind mit arrivalDay=1 und departureDay=1 gekennzeichnet.

Example 3: Midnight overrun between linked <trainPart>s / Beispiel 3: Mitternachtsübergang zwischen verknüpften <trainPart>s

  <operatingPeriod id='opp_1' name='Mon-Fri' timetablePeriodRef='…'
	 bitMask='011111001111100…00111110'>
    <operatingDay operatingCode='1111100' />
  </operatingPeriod>

  <trainPart id='tp_1_of_train_1'>
    <operatingPeriodRef ref='opp_1'/>
    <ocpsTT>
      <ocpTT ocpRef='ocp_DNKW_A' ocpType='pass'>
        <times scope='scheduled' departure='23:55:35'/>
      </ocpTT>
      <ocpTT ocpRef='ocp_DNKO' ocpType='stop'>
        <times scope='scheduled' arrival='23:57:53'/>
      </ocpTT>
    <ocpsTT>
  </trainPart>
!-- here midnight overrun --
  <trainPart id='tp_2_of_train_1'>
    <operatingPeriodRef ref='opp_1'/>
    <ocpsTT>
      <ocpTT ocpRef='ocp_DNKO' ocpType='stop'>
        <times scope='scheduled' departure='00:00:19' departureDay='1'/>
      </ocpTT>
      <ocpTT ocpRef='ocp_DWT' ocpType='stop'>
        <times scope='scheduled' arrival='00:02:17' arrivalDay='1' departure='00:03:00' departureDay='1'/>
      </ocpTT>
    <ocpsTT>
  </trainPart>

Please note that both <trainPart>s reference the same <operatingPeriod>. The fact that one <trainPart> will arrive on the day before its successor's departure, is indicated only by the different values of arrivalDay / departureDay. All further arrival, departure, and run through times of the (operational) train until the end of its route are marked with arrivalDay=1 and departureDay=1.

Bitte beachten Sie, dass beide <trainPart>s die gleiche <operatingPeriod> referenzieren. Der Sachverhalt, dass ein <trainPart> am Tag vor der Abfahrt seines Nachfolgers ankommt, wird nur durch die unterschiedlichen Werte von arrivalDay / departureDay abgebildet. Alle weiteren Ankunfts-, Abfahrts- und Durchfahrtszeiten des (betrieblichen) Zuges bis zu seinem Laufwegende sind mit arrivalDay=1 und departureDay=1 gekennzeichnet.

Reference place for day indexes / midnight overruns / Referenzort der Tages-/Mitternachtszählung

• It is intended that the arrivalDay/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, its first <ocpTT> may have an arrivalDay/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 <trainPart>s 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. See example below.
  

• Es ist vorgesehen, dass die Tages- bzw. Mitternachtszählung (arrivalDay/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> einen Tagesindex (arrivalDay/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 <trainPart>s kann es also vorkommen, dass diese bereits mit Tageszählung >0 beginnen.
  
• Wenn Zugläufe (insbesondere kommerzielle, d. h. <train>s mit type='commercial') von einem Zug auf einen anderen übergehen, kann es zu einem „Rückschritt“ der Tageszählung kommen. (Dies bedeutet, dass der Zuglauf von einem Zug, der bereits über Mitternacht gefahren ist, übergeht auf einen Zug, der noch nicht über Mitternacht gefahren ist.) Auch dies ist kein Fehler, s. Beispiel unten.
  

There are three trains (red, green, and blue) which are ‘broken’ into at least nine train parts at the black towns. In the run of the green and blue train there is a ‘back-jump’ of the day index at Berlin (arrDay=1 to depDay=0). This back-jump normally* comes along with an apparent change of operating day (Monday to Tuesday: operatingPeriodRef changes); both phenomena together make it ‘Monday +1’ to ‘Tuesday +0’.

* ‘Normally’ as there wouldn’t be an apparent change of operating day if the trains would operate daily.

Do you ask whether there is no such “back-jump” at the Warsaw’s route section? There could be. For this example, it is assumed that there is one through operational train from Amsterdam to Warsaw (train #1). Since this begins at Amsterdam before midnight, its day offsets refers to the Amsterdam departure so that the train arrives in Warsaw with arrivalDay=+1 but without back jump. At the Prague branch, in contrast, it is assumed to be a new operational train starting from Berlin (train #3). Its start with departureDay=0 already happens after midnight, hence the back-jump.

In diesem Bild gibt es drei Züge (rot, grün, blau), die wegen der railML^®-internen Syntax in mind. neun Zugteile unterteilt sein müssen (an den schwarz dargestellten Stationen). Im Zuglauf der Zugteile grün und blau kommt es zum „Rücksprung“ des Tagesindex‘ in Berlin (arrivalDay=1 auf departureDay=0). Der Rücksprung geht i. d. R.* mit einem scheinbaren Verkehrstagewechsel einher (operatingPeriodRef wechselt: Montag auf Dienstag). Beide Effekte zusammen führen zu ‘Monday +1’ auf ‘Tuesday +0’.

* Nur „in der Regel“, denn wenn die Züge täglich fahren würden, gäbe es keinen scheinbaren Verkehrstagewechsel.

Warum gibt es keinen Rücksprung auf dem Warschauer Abschnitt? In diesem Beispiel wurde unterstellt, dass es einen durchgehenden (betrieblichen) Zug Amsterdam – Warschau gibt. Da dieser in Amsterdam vor Mitternacht beginnt, beziehen sich seine arrivalDay/departureDay-Angaben auf die Amsterdamer Abfahrt, und er kommt in Warschau mit arrivalDay=1 an, aber ohne Rücksprung. Im Gegensatz dazu ist für den Prager Zweig unterstellt, dass in Berlin ein neuer (betrieblicher) Zug beginnt. Dessen Abfahrt mit departureDay=0 liegt bereits nach Mitternacht, daher der Rücksprung.

Meaning of the day counting / midnight overruns / Bedeutung der Tages-/Mitternachtszählung

• The operating day reference (<operatingPeriodRef>) cannot be interpreted alone. This is only possible by including the corresponding day index (arrivalDay/departureDay). To discover at which days a train actually runs it may be necessary to shift the bit mask (from <operatingPeriod>) by the number of bits from (arrivalDay/departureDay + dayIndex).
  
• Whether a change of operating days during a train run actually happens can only be obtained by comparing the shifted bit masks. A change of <operatingPeriodRef> alone is not necessarily a change of the actual operating days.
• There may be an unlimited number of combinations of <operatingPeriod> and arrivalDay/departureDay which are semantically identical, i. e. they effectively describe the same days.
  
• A writing software is free to choose any combination; it can even change the combination inside one train.
  

• Die Verkehrstage-Angabe (<operatingPeriod>) ist allein nicht interpretierbar, sondern immer nur im Zusammenhang mit dem jeweiligen Tagesindex (arrivalDay/departureDay). Um festzustellen, wann ein Zug tatsächlich fährt, muss man z. B. die Bitmaske um die Anzahl Stellen aus (arrivalDay/departureDay+ dayIndex) verschieben.
  
• Ob ein effektiver Wechsel der Verkehrstage innerhalb des Zuglaufs stattfindet, kann nur durch Vergleichen der verschobenen Bitmasken herausgefunden werden. Ein Wechsel der operatingPeriod allein ist nicht zwingend ein effektiver Verkehrstagewechsel.
  
• Es kann beliebig viele Kombinationen aus Verkehrstage-Angabe (operatingPeriod) und Tagesindex (arrivalDay/departureDay) geben, die inhaltlich das gleiche bedeuten.
  
• Das schreibende Programm ist frei in der Wahl der Kombination, diese kann auch „unterwegs“ wechseln.
  

Why not use shifted/rotated <operatingPeriod>s / Warum rotierte/verschobene <operatingPeriods> nicht verwendet werden sollten

In the introduction of this page it was recommended to use the day offset attributes arrivalDay/departureDay instead of individuelly shifted <operatingPeriod>s for <trainPart>s before and after midnight. Reasons for this recommendation are:

• Timetable periods are normally not ‘closed’, i.e. after the last day of a timetable period does not follow the first day again. A train running daily in a timetable period and running over midnight does not run daily after midnight, strictly speaking: It does no more run at the first day of the period but instead it does run at the first day after the timetable period. The bit mask of its operating days (<operatingPeriod>.bitMask) is shifted by one bit in the direction of increasing dates, i.e. even the daily-bitmask containing only 1s before will then start with a 0.
• For several <operatingPeriod>s which are often used for passenger information it may be very difficult to find (understandable) text expressions if they would be shifted by one or more days.

In der Einleitung dieser Seite wurde empfohlen, die Offset-Attribute arrivalDay/departureDay zu verwenden und nicht individuell rotierte <operatingPeriods> für <trainPart>s vor und nach Mitternacht zu erzeugen. Gründe für diese Empfehlungen sind:

• Fahrplanperioden sind i. d. R. nicht geschlossen, d. h. auf den letzten Tag einer Fahrplanperiode folgt nicht wieder der erste Tag der gleichen Periode. Ein Zug, der in einer Fahrplanperiode täglich beginnt und über Mitternacht fährt, fährt danach genau genommen nicht mehr täglich (nämlich nicht am ersten Tag der Fahrplanperiode, dafür aber zusätzlich am ersten Tag der nächsten Fahrplanperiode). Die Bitmaske seiner Verkehrstage (<operatingPeriod>.bitMask) ist gegenüber vor Mitternacht um ein Bit in Richtung aufsteigenden Datums verschoben, d. h. selbst die zuvor nur aus Einsen bestandene Täglich-Bitmaske beginnt danach mit einer Null.
• Das um Tage verschobene Angeben der Verkehrstageregelungen (operatingPeriods) ist ausdrücklich zu vermeiden, da - wie in [1] unter Abbildung spezieller Verkehrstageregelungen ohne Datumsbezug erwähnt - für viele praktisch vorkommende Verkehrstageregelungen keine exakte Folgetagsentsprechung existiert (z. B. nicht für die in Deutschland recht verbreiteten „werktags außer Samstags“ und „Sonn- und Feiertags“).

[1] Weitere Informationen und railML^®-Beispiel zu Verkehrstagen (external link, PDF; 185 kByte)

[2] Examples for a non-zero operating day offset at the first ocpTT of a train run