Dev:Midnight overrun

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

General / Allgemeines

There are two general possibilities to indicate midnight overruns correctly in railML:

1. Using the attributes arrivalDay and departureDay
   
2. By splitting the train’s run into <trainPart>s before and after midnight and changing <operatingPeriodRef> between these <trainPart>s and using an <operatingPeriod> after midnight which is ‘shifted’ by one day.

Possibility 1 is the one regularly recommended for midnight overruns during a train run in railML. Possibility 2 shall be avoided because of the following reasons:

• It is explicitly not wanted to break a train’s run into <trainPart>s only because of the midnight overrun.
• Timetable periods are normally not ‘closed’, i.e. after the last day of a timetable period did 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 not 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 raising 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.

Es gibt zwei grundsätzliche Möglichkeiten, Mitternachtsübergänge in railML korrekt abzubilden:

1. Mit Hilfe der Attribute arrivalDay und departureDay.
   
2. Durch Aufteilen des Zuglaufs in <trainPart>s vor und nach Mitternacht sowie Wechsel der <operatingPeriodRef>-Referenz zwischen diesen Zugteilen und durch um einen Tag verschobene Angabe der Verkehrstage der nach Mitternacht gültigen <operatingPeriod>.

Möglichkeit 1 ist die regulär vorgesehene für Mitternachtsübergänge innerhalb eines in railML abgebildeten Zuglaufs. Möglichkeit 2 soll aus den folgenden Gründen vermieden werden:

• Es ist ausdrücklich nicht vorgesehen, einen Zuglauf nur wegen des Mitternachtsübergangs in <trainPart>s aufzuteilen.
• 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 bereits im Kapitel 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“).

Indicating Midnight overruns using the attributes arrivalDay and departureDay / Abbildung von Mitternachtsübergängen mit Hilfe der Attribute arrivalDay und departureDay

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.

Die Attribute arrivalDay und departureDay stellen eine Zählung der Anzahl Mitternachtsübergänge relativ zu einem Bezugspunkt (z. B. Abfahrtsort; 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:

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.
Alle weiteren Ankunfts-, Abfahrts- und Durchfahrtszeiten des (betrieblichen) Zuges bis zu seinem Laufwegende sind mit arrivalDay=1 und departureDay=1 gekennzeichnet.

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 <trainParts>

  <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 successors 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 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 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 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. See example below.
  

• 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> 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 <trainPart>s kann es also vorkommen, dass diese bereits mit Tageszählung >0 beginnen.
  
• Wenn Zugläufe (hier in railML: commercialTrains) 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.
  

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 to ‘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 in 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 arrival/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 (arrival/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 (arrival/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 is an unlimited number of combinations of <operatingPeriod> and arrival/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 (arrival/departureDay). Um festzustellen, wann ein Zug tatsächlich fährt, muss man z. B. die Bitmaske um die Anzahl Stellen aus (arrival/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 (arrival/departureDay) geben, die inhaltlich das gleiche bedeuten.
  
• Das schreibende Programm ist frei in der Wahl der Kombination, diese kann auch „unterwegs“ wechseln.