Difference between revisions of "TT:Midnight overrun"

From wiki.railML.org
Jump to: navigation, search
[checked revision][unchecked revision]
m (correction of spelling errors)
(Removed description of the obsolete attribute <dayOffset>, remaining relevant information was moved to other paragraphs of this page, railML examples were adapted and extended)
Line 2: Line 2:
 
=== General / {{Deu|Allgemeines}}===
 
=== General / {{Deu|Allgemeines}}===
  
There are several possibilities to indicate midnight overruns correctly in railML:<br>
+
There are two general possibilities to indicate midnight overruns correctly in railML:<br>
 
# Using the attributes {{Attr|arrivalDay}} and {{Attr|departureDay}}<br>
 
# Using the attributes {{Attr|arrivalDay}} and {{Attr|departureDay}}<br>
# By splitting the train’s run into {{TT:Tag|trainPart}}s before and after midnight and changing {{TT:Tag|operatingPeriodRef}} between these <trainPart>s…<br>
+
# By splitting the train’s run into {{TT:Tag|trainPart}}s before and after midnight and changing {{TT:Tag|operatingPeriodRef}} between these <trainPart>s and using an {{TT:Tag|operatingPeriod}} after midnight which is ‘shifted’ by one day.
:* a) …and using the attribute {{Attr|dayOffset}} {{Intro|2.2}} at the {{TT:Tag|operatingPeriod}} after midnight,<br>
+
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:
:* b) …and using an {{TT:Tag|operatingPeriod}} after midnight which is ‘shifted’ by one day.<br>
+
* It is explicitly not wanted to break a train’s run into {{TT:Tag|trainPart}}s only because of the midnight overrun.
Possibility 1 is the one regularly recommended for midnight overruns during a train run in railML. It is explicitly not wanted to break a train’s run into {{TT:Tag|trainPart}}s only because of the midnight overrun. However, possibility 2a comes into consideration for a midnight overrun before the current train run (see example below). Possibility 2b shall be avoided.
+
* 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.
  
 
{{Deu|
 
{{Deu|
Es gibt mehrere Möglichkeiten, Mitternachtsübergänge in railML korrekt abzubilden:}}<br>
+
Es gibt zwei grundsätzliche Möglichkeiten, Mitternachtsübergänge in railML korrekt abzubilden:}}<br>
 
# {{Deu|Mit Hilfe der Attribute {{Attr|arrivalDay}} und {{Attr|departureDay}}.}}<br>
 
# {{Deu|Mit Hilfe der Attribute {{Attr|arrivalDay}} und {{Attr|departureDay}}.}}<br>
# {{Deu|Durch Aufteilen des Zuglaufs in {{TT:Tag|trainPart}}s vor und nach Mitternacht sowie Wechsel der {{TT:Tag|operatingPeriodRef}}-Referenz zwischen diesen Zugteilen…}}<br>
+
# {{Deu|Durch Aufteilen des Zuglaufs in {{TT:Tag|trainPart}}s vor und nach Mitternacht sowie Wechsel der {{TT:Tag|operatingPeriodRef}}-Referenz zwischen diesen Zugteilen und durch um einen Tag verschobene Angabe der Verkehrstage der nach Mitternacht gültigen {{TT:Tag|operatingPeriod}}.}}
:* {{Deu|a) …und Verwenden des Attributs {{Attr|dayOffset}} {{Intro|2.2}} der nach Mitternacht gültigen {{TT:Tag|operatingPeriod}},}}<br>
+
:* {{Deu|b) …und durch um einen Tag verschobene Angabe der Verkehrstage der nach Mitternacht gültigen {{TT:Tag|operatingPeriod}}.}}<br>
+
  
{{Deu|Möglichkeit 1 ist die regulär vorgesehene für Mitternachtsübergänge innerhalb eines in railML abgebildeten Zuglaufs. Es ist ausdrücklich nicht vorgesehen, einen Zuglauf nur wegen des Mitternachtsübergangs in {{TT:Tag|trainPart}}s aufzuteilen. Möglichkeit 2a kommt dennoch in besonderen des Mitternachtsübergangs vor einem (hier betrachteten) Zuglauf in Betracht. Möglichkeit 2b soll vermieden werden.
+
{{Deu|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:}}
}}
+
* {{Deu|Es ist ausdrücklich nicht vorgesehen, einen Zuglauf nur wegen des Mitternachtsübergangs in {{TT:Tag|trainPart}}s aufzuteilen.}}
 +
* {{Deu|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.}}
 +
* {{Deu|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“).}}
  
=== Midnight overruns inside the current train's route / {{Deu|Mitternachtsübergänge innerhalb des abgebildeten Zuglaufs}}===
+
=== Indicating Midnight overruns using the attributes arrivalDay and departureDay / {{Deu|Abbildung von Mitternachtsübergängen mit Hilfe der Attribute arrivalDay und departureDay}}===
  
The attributes {{Attr|arrivalDay}} and {{Attr|departureDay}} are intended for midnight overruns during one train run. They 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.
+
The attributes {{Attr|arrivalDay}} and {{Attr|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.
  
 
{{Deu|
 
{{Deu|
Für Mitternachtsübergänge innerhalb eines abgebildeten Zuglaufs sind in railML die Attribute {{Attr|arrivalDay}} und {{Attr|departureDay}} vorgesehen. Sie 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:}}
+
Die Attribute {{Attr|arrivalDay}} und {{Attr|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 / {{Deu|Beispiel 1: Mitternachtsübergang während eines Zwischenaufenthalts}}====
 
==== Example 1: Midnight overruns during an intermediate stop / {{Deu|Beispiel 1: Mitternachtsübergang während eines Zwischenaufenthalts}}====
  
 
<syntaxhighlight lang="xml">
 
<syntaxhighlight lang="xml">
   <ocpTT ocpRef='ocp_DOLB' ocpType='stop'>
+
   <operatingPeriod id='opp_1' name='Mon-Fri' timetablePeriodRef='…'
!--                                           | here midnight overrun  
+
bitMask='011111001111100…00111110'>
!--                                           v  
+
    <operatingDay operatingCode='1111100' />
    <times scope='scheduled' arrival='23:59:49' departure='00:00:19' departureDay='1'/>
+
  </operatingPeriod>
    <sectionTT section='DOLB-DN E' lineRef='ln_80.6212' trackRef='tr_80.6212_2' trackInfo='1'>
+
 
      <runTimes minimalTime='PT48S' operationalReserve='PT1S'/>
+
  <trainPart id='tp_1_of_train_1'>
    </sectionTT>
+
    <operatingPeriodRef ref='opp_1'/>
    <stopDescription commercial='true' stopOnRequest='false'>
+
    <ocpsTT>
       <stopTimes minimalTime='PT30S'/>
+
      <ocpTT ocpRef='ocp_DNKW_A' ocpType='pass'>
     </stopDescription>
+
        <times scope='scheduled' departure='23:55:35'/>
   </ocpTT>
+
      </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>
 
</syntaxhighlight>
 
</syntaxhighlight>
  
All further arrival, departure, and run through times of the train until the end of its route are marked with arrivalDay=1 and departureDay=1.<br>
+
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.<br>
 
+
{{Deu|Alle weiteren Ankunfts-, Abfahrts- und Durchfahrtszeiten des (betrieblichen) Zuges bis zu seinem Laufwegende sind mit arrivalDay<nowiki>=</nowiki>1 und departureDay<nowiki>=</nowiki>1 gekennzeichnet.}}
{{Deu|
+
Alle weiteren Ankunfts-, Abfahrts- und Durchfahrtszeiten des Zuges bis zu seinem Laufwegende sind mit arrivalDay<nowiki>=</nowiki>1 und departureDay<nowiki>=</nowiki>1 gekennzeichnet.
+
}}
+
  
 
==== Example 2: Midnight overrun while in motion / {{Deu|Beispiel 2: Mitternachtsübergang während der Fahrt}}====
 
==== Example 2: Midnight overrun while in motion / {{Deu|Beispiel 2: Mitternachtsübergang während der Fahrt}}====
  
 
<syntaxhighlight lang="xml">
 
<syntaxhighlight lang="xml">
   <ocpTT ocpRef='ocp_DNKW' ocpType='pass'>
+
   <operatingPeriod id='opp_1' name='Mon-Fri' timetablePeriodRef='…'
     <times scope='scheduled' departure='23:55:00'/>
+
bitMask='011111001111100…00111110'>
   </ocpTT>
+
     <operatingDay operatingCode='1111100' />
   <ocpTT ocpRef='ocp_DNKW_A' ocpType='pass'>
+
   </operatingPeriod>
    <times scope='scheduled' departure='23:55:35'/>
+
 
  </ocpTT>
+
   <trainPart id='tp_1_of_train_1'>
  <ocpTT ocpRef='ocp_DNKO' ocpType='stop'>
+
    <operatingPeriodRef ref='opp_1'/>
    <times scope='scheduled' arrival='23:57:53' departure='23:58:23'/>
+
    <ocpsTT>
  </ocpTT>
+
      <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 --
 
!-- here midnight overrun --
  <ocpTT ocpRef='ocp_DWT_N' ocpType='pass'>
+
      <ocpTT ocpRef='ocp_DWT' ocpType='stop'>
    <times scope='scheduled' departure='00:01:25' departureDay='1'/>
+
        <times scope='scheduled' arrival='00:02:17' arrivalDay='1' departure='00:03:00' departureDay='1'/>
  </ocpTT>
+
      </ocpTT>
  <ocpTT ocpRef='ocp_DWT' ocpType='stop'>
+
    <ocpsTT>
    <times scope='scheduled' arrival='00:02:17' arrivalDay='1' departure='00:03:00' departureDay='1'/>
+
   </trainPart>
   </ocpTT>
+
 
</syntaxhighlight>
 
</syntaxhighlight>
  
All further arrival, departure, and run through times of the train until the end of its route are marked with arrivalDay=1 and departureDay=1.<br>
+
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.<br>
 +
{{Deu|Alle weiteren Ankunfts-, Abfahrts- und Durchfahrtszeiten des (betrieblichen) Zuges bis zu seinem Laufwegende sind mit arrivalDay<nowiki>=</nowiki>1 und departureDay<nowiki>=</nowiki>1 gekennzeichnet.}}
  
{{Deu|
+
==== Example 3: Midnight overrun between linked <trainPart>s / {{Deu|Beispiel 3: Mitternachtsübergang zwischen verknüpften <trainParts>}}====
Alle weiteren Ankunfts-, Abfahrts- und Durchfahrtszeiten des Zuges bis zu seinem Laufwegende sind mit arrivalDay<nowiki>=</nowiki>1 und departureDay<nowiki>=</nowiki>1 gekennzeichnet.
+
}}
+
  
==== Reference place for day indexes / midnight overruns / {{Deu|Referenzort der Tages-/Mitternachtszählung}}====
+
<syntaxhighlight lang="xml">
 +
  <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>
 +
</syntaxhighlight>
 +
 
 +
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 {{Attr|arrivalDay}} / {{Attr|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.<br>
 +
 
 +
{{Deu|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 {{Attr|arrivalDay}} / {{Attr|departureDay}} abgebildet. Alle weiteren Ankunfts-, Abfahrts- und Durchfahrtszeiten des (betrieblichen) Zuges bis zu seinem Laufwegende sind mit arrivalDay<nowiki>=</nowiki>1 und departureDay<nowiki>=</nowiki>1 gekennzeichnet.}}
 +
 
 +
=== Reference place for day indexes / midnight overruns / {{Deu|Referenzort der Tages-/Mitternachtszählung}}===
  
 
* It is intended that the arrival/departureDay counting starts with 0 at the first '''departure''' of a '''train'''.<br>
 
* It is intended that the arrival/departureDay counting starts with 0 at the first '''departure''' of a '''train'''.<br>
 
* 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).<br>
 
* 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).<br>
 +
* In case a train did already run over midnight before the first departure in the railML data, this first {{TT:Tag|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.<br>
 
* 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.<br>
 
* 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.<br>
 
* 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.<br>
Line 84: Line 131:
 
* {{Deu|Es ist vorgesehen, dass die Tages- bzw. Mitternachtszählung (arrival/departureDay) an der ersten '''Abfahrt''' eines '''Zuges''' mit 0 beginnt.}}<br>
 
* {{Deu|Es ist vorgesehen, dass die Tages- bzw. Mitternachtszählung (arrival/departureDay) an der ersten '''Abfahrt''' eines '''Zuges''' mit 0 beginnt.}}<br>
 
* {{Deu|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.}}<br>
 
* {{Deu|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.}}<br>
 +
* {{Deu|Sollte der Zug bereits vor dem ersten abgebildeten Abfahrtsbahnhof – quasi „im Ausland“ – über Mitternacht gefahren sein, darf diese erste {{TT:Tag|ocpTT}} einen Tagesindex (arrival/departureDay) >0 aufweisen.}}
 
* {{Deu|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.}}<br>
 
* {{Deu|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.}}<br>
 
* {{Deu|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.}}<br>
 
* {{Deu|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.}}<br>
Line 107: Line 155:
 
</nowiki>}}
 
</nowiki>}}
  
==== Meaning of the day counting / midnight overruns / {{Deu|Bedeutung der Tages-/Mitternachtszählung}}====
+
=== Meaning of the day counting / midnight overruns / {{Deu|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).<br>
 
* 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).<br>
Line 118: Line 166:
 
* {{Deu|Es kann beliebig viele Kombinationen aus Verkehrstage-Angabe (operatingPeriod) und Tagesindex (arrival/departureDay) geben, die inhaltlich das gleiche bedeuten.<br>}}
 
* {{Deu|Es kann beliebig viele Kombinationen aus Verkehrstage-Angabe (operatingPeriod) und Tagesindex (arrival/departureDay) geben, die inhaltlich das gleiche bedeuten.<br>}}
 
* {{Deu|Das schreibende Programm ist frei in der Wahl der Kombination, diese kann auch „unterwegs“ wechseln.<br>}}
 
* {{Deu|Das schreibende Programm ist frei in der Wahl der Kombination, diese kann auch „unterwegs“ wechseln.<br>}}
 
=== Midnight overruns outside the current train’s route ===
 
 
Normally it is intended – for several applications even necessary – that a train starts with arrival/departureDay counting from 0 from the first departure actually given (in the railML data).
 
 
Therefore, it is no more possible to use departureDay >0 in case a train did already run over midnight before the first departure (in the railML data). So, it would only be possible to describe the operating days shifted by the days the train run over midnight before (which is possibility 2b in the list at the beginning).
 
 
This solution is explicitly not wanted because of the following reasons (inter alia):<br>
 
* 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.<br>
 
* 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.<br>
 
 
Because of these reasons, the attribute {{TT:Tag|operatingPeriod}}.{{Attr|dayOffset}} has been introduced from railML 2.2 onwards.
 
 
<syntaxhighlight lang="xml">
 
  <operatingPeriod id='opp_1' name='daily' description='runs daily' timetablePeriodRef='ttp_2020_21'
 
      bitMask='111…111'>
 
    <operatingDay operatingCode='1111111' startDate='2020-12-13' endDate='2021-12-11'/>
 
  </operatingPeriod>
 
  <operatingPeriod id='opp_2' name='daily +1' description='runs daily after midnight' timetablePeriodRef='ttp_2020_21'
 
      bitMask='111…111'
 
      dayOffset='1'>
 
    <operatingDay operatingCode='1111111' startDate='2020-12-13' endDate='2021-12-11'/>
 
  </operatingPeriod>
 
</syntaxhighlight>
 
 
The bit mask of the <operatingPeriod>s with dayOffset≠0 is not to be shifted, i.e. it is identical to the case dayOffset=0.
 
 
Basically, there is the possibility (which is principally equal) in such cases to start with arrival/departureDay>0 instead of dayOffset>0 even at the first <ocpTT> of a train. A reading software should be able to parse both versions. The version with dayOffset>0 is intended for cases where departureDay=0 is enforced by external reasons. However, this is also the recommendation of the railML consortium.
 
 
=== {{Deu|Mitternachtsübergänge außerhalb des abgebildeten Zuglaufs}} ===
 
 
{{Deu|<nowiki>In der Regel ist es beabsichtigt – bei einigen Anwendungen auch von außen her erforderlich – dass ein Zug mit Tageszählung =0 beginnt, d. h. dass sich die Verkehrstage, mit denen er identifiziert wird, auf den ersten abgebildeten Abfahrtsbahnhof beziehen.</nowiki>}}
 
 
{{Deu|Sollte der Zug bereits vor dem ersten abgebildeten Abfahrtsbahnhof – quasi „im Ausland“ – über Mitternacht gefahren sein, besteht damit nicht mehr die Möglichkeit, mit Tagesindex (arrival/departureDay) >0 am ersten abgebildeten Bahnhof zu beginnen.}}
 
 
{{Deu|Damit bliebe dann nur noch die Möglichkeit (eingangs dieses Kapitels mit 2b bezeichnet), die Verkehrstage um die Anzahl Tage versetzt anzugeben, wie oft der Zug zuvor über Mitternacht gefahren ist. Diese Lösung ist jedoch ausdrücklich nicht gewollt u. a. aus folgenden Gründen:}}<br>
 
* {{Deu|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.}}<br>
 
* {{Deu|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“).}}<br>
 
 
{{Deu|Aus diesen Gründen wird mit railML 2.2 neu das Attribut {{Attr|dayOffset}} im Element {{TT:Tag|operatingPeriod}} eingeführt:}}
 
 
<syntaxhighlight lang="xml">
 
  <operatingPeriod id='opp_1' name='täglich' description='verkehrt täglich' timetablePeriodRef='ttp_2020_21'
 
      bitMask='111…111'>
 
    <operatingDay operatingCode='1111111' startDate='2020-12-13' endDate='2021-12-11'/>
 
  </operatingPeriod>
 
  <operatingPeriod id='opp_2' name='täglich +1' description=' verkehrt täglich nach Mitternacht' timetablePeriodRef='ttp_2020_21'
 
      bitMask='111…111'
 
      dayOffset='1'>
 
    <operatingDay operatingCode='1111111' startDate='2020-12-13' endDate='2021-12-11'/>
 
  </operatingPeriod>
 
</syntaxhighlight>
 
 
{{Deu|<nowiki>Die Bitmaske der mit dayOffset≠0 anzugebenden operatingPeriods ist nicht verschoben darzustellen, d. h. die Bitmaske ist identisch wie beim Fall dayOffset=0.</nowiki>}}
 
 
{{Deu|<nowiki>Grundsätzlich besteht die an sich gleichwertige Möglichkeit, in den betreffenden Fällen anstatt dayOffset>0 weiterhin mit arrival/departureDay>0 auch am ersten Bahnhof zu beginnen. Ein lesendes Programm sollte beide Varianten verarbeiten können. Die Variante mit dayOffset>0 ist vorgesehen für Fälle, in denen departureDay=0 am ersten Bahnhof aus externen Gründen erzwungen werden muss. Letzteres ist allerdings auch die Empfehlung des railML-Konsortiums.</nowiki>}}
 
 
=== Summary: Combinded example with arrival/departureDay and <dayOffset> / {{Deu|Zusammenfassendes Beispiel}}===
 
 
The aim of the following example is to show the two general possibilities of “coaction” of {{Attr|arrival/departureDay}} and {{Attr|dayOffset}} in context.
 
 
Please note that both a and b describe ''the same train'' in content. Both <trainPart>s sequentially define the train: <trainPart> “tp_1_of_train_1” from A to C, <trainPart> “tp_2_of_train_1” from C to E.
 
 
{{Deu|Das folgende Beispiel soll die beiden grundsätzlichen Möglichkeiten des Zusammenspiels zwischen den Attributen {{Attr|arrival/departureDay}} und {{Attr|dayOffset}} verdeutlichen.}}
 
 
{{Deu|Bitte beachten Sie, dass a und b jeweils inhaltlich ''den gleichen Zug'' beschreiben. Beide Zugteile bilden jeweils sequentiell zusammengesetzt den Zug: <trainPart> “tp_1_of_train_1” von A bis C, <trainPart> “tp_2_of_train_1” von C bis E.}}
 
 
==== a) First with one {{TT:Tag|operatingPeriod}} only ====
 
 
<syntaxhighlight lang="xml">
 
<trainPart id='tp_1_of_train_1'>
 
  <operatingPeriodRef ref='opp_1'/>
 
  <ocpsTT>
 
    <ocpTT ocpRef='ocp_A' ocpType='begin'>
 
      <times scope='scheduled' departure='23:45:18' departureDay='0'/>
 
    </ocpTT>
 
    …
 
!-- here midnight overrun --!
 
    <ocpTT ocpRef='ocp_C' ocpType='end'>
 
      <times scope='scheduled' arrival='00:30:40' arrivalDay='1'/>
 
    </ocpTT>
 
  </ocpsTT>
 
</trainPart>
 
 
<trainPart id='tp_2_of_train_1'>
 
  <operatingPeriodRef ref='opp_1'/>
 
  <ocpsTT>
 
    <ocpTT ocpRef='ocp_C' ocpType='begin'>
 
      <times scope='scheduled' departure='00:31:18' departureDay='1'/>
 
    </ocpTT>
 
    …
 
    <ocpTT ocpRef='ocp_E' ocpType='end'>
 
      <times scope='scheduled' arrival='00:45:40' arrivalDay='1'/>
 
    </ocpTT>
 
  </ocpsTT>
 
</trainPart>
 
 
<operatingPeriod id='opp_1' name='Mon-Fri' timetablePeriodRef='…'
 
bitMask='011111001111100…00111110'>
 
    <operatingDay operatingCode='1111100' />
 
</operatingPeriod>
 
 
</syntaxhighlight>
 
 
 
The midnight overrun is expressed by the attributes {{Attr|arrival/departureDay}} only. There is only one {{TT:Tag|operatingPeriod}} necessary for this example, the attribute {{Attr|dayOffset}} is not used.
 
 
{{Deu|Der Mitternachtsübergang wird nur durch die Attribute {{Attr|arrival/departureDay}} ausgedrückt. Es ist nur ein Element {{TT:Tag|operatingPeriod}} notwendig für dieses Beispiel; das Attribut {{Attr|dayOffset}} wird nicht verwendet.}}
 
 
==== b) With two {{TT:Tag|operatingPeriod}}s and the attribute {{Attr|dayOffset}} ====
 
 
<syntaxhighlight lang="xml">
 
<trainPart id='tp_1_of_train_1'>
 
  <operatingPeriodRef ref='opp_1'/>
 
  <ocpsTT>
 
    <ocpTT ocpRef='ocp_A' ocpType='begin'>
 
      <times scope='scheduled' departure='23:45:18' departureDay='0'/>
 
    </ocpTT>
 
    …
 
!-- here midnight overrun --!
 
    <ocpTT ocpRef='ocp_C' ocpType='end'>
 
      <times scope='scheduled' arrival='00:30:40' arrivalDay='1'/>
 
    </ocpTT>
 
  </ocpsTT>
 
</trainPart>
 
 
<trainPart id='tp_2_of_train_1'>
 
  <operatingPeriodRef ref='opp_2'/>
 
  <ocpsTT>
 
    <ocpTT ocpRef='ocp_C' ocpType='begin'>
 
      <times scope='scheduled' departure='00:31:18' departureDay='0'/>
 
    </ocpTT>
 
    …
 
    <ocpTT ocpRef='ocp_E' ocpType='end'>
 
      <times scope='scheduled' arrival='00:45:40' arrivalDay='0'/>
 
    </ocpTT>
 
  </ocpsTT>
 
</trainPart>
 
 
<operatingPeriod id='opp_1' name='Mon-Fri' timetablePeriodRef='…'
 
bitMask='011111001111100…00111110'>
 
    <operatingDay operatingCode='1111100' />
 
</operatingPeriod>
 
 
<operatingPeriod id='opp_2' name='Mon-Fri after midnight' timetablePeriodRef='…'
 
bitMask='011111001111100…00111110' dayOffset='1'>
 
    <operatingDay operatingCode='1111100'/>
 
</operatingPeriod>
 
 
</syntaxhighlight>
 
 
 
The deciding difference is: In example b both <trainPart>s start with departureDay='0' whereas in example a the second <trainPart> starts with departureDay='1'.
 
 
{{Deu|<nowiki>Der entscheidende Unterschied ist: In Beispiel b beginnt der zweite <trainPart> mit departureDay='0', während in Beispiel a der zweite <trainPart> mit departureDay='1' beginnt.</nowiki>}}
 

Revision as of 12:14, 17 October 2017

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.

Midnight overrun dayindex backjump.png

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.