Dev:Midnight overrun: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
[unchecked revision][checked revision]
(page newly created for examples for midnight overruns following trac ticket #138)
 
m (nur Syntax, Rechtschreibung und Interpunktion korrigiert (nowiki-Markierungen im Deutschen verhinderten Attr|-Auflösungen))
(15 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== Midnight overruns in RailML / {{Deu| Abbildung von Mitternachtsübergängen in RailML}}==
This article explains, how to handle midnight overruns within the timetable subschema.
 
{{deu|Dieser Artikel erklärt dem Umgang mit Mitternachtsübergängen im Timetable-Subschema.}}
== Midnight overruns in railML / {{Deu| Abbildung von Mitternachtsübergängen in railML}}==
=== General / {{Deu|Allgemeines}}===
=== General / {{Deu|Allgemeines}}===


There are several possibilities to indicate midnight overruns correctly in RailML:<br>
Midnight overruns in general have two aspects to be considered:
# Using the attributes {{Attr|arrivalDay}} and {{Attr|departureDay}}<br>
* 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.
# 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>
* arrivals/departures of a {{TT:Tag|trainPart}} after midnight will take place on a different day than before midnight related to its {{TT:Tag|operatingPeriod}}. Since there is only one {{TT:Tag|operatingPeriod}} per {{TT:Tag|trainPart}}, there has to be a means to determine the actual days, when a {{TT:Tag|trainPart}} arrives/departs at a certain {{TT:Tag|ocpTT}}.
:* a) …and using the attribute {{Attr|dayOffset}} {{Intro|2.2}} at the {{TT:Tag|operatingPeriod}} after midnight,<br>
:* b) …and using an {{TT:Tag|operatingPeriod}} after midnight which is ‘shifted’ by one day.<br>
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.
 
{{Deu|
Es gibt mehrere Möglichkeiten, Mitternachtsübergänge in RailML korrekt abzubilden:}}<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|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.
}}


=== Midnight overruns inside the current train's route / {{Deu|Mitternachtsübergänge innerhalb des abgebildeten Zuglaufs}}===
It is not intended to split the train’s run into a {{TT:Tag|trainPart}} before and another after midnight and to create separate {{TT:Tag|operatingPeriod}}s for both. Instead of that, the different operating days of the {{TT:Tag|trainPart}} before and after midnight are expressed using different values for the attributes {{Attr|arrivalDay}} and {{Attr|departureDay}}. These attributes represent the day offset of the arrival/departure of a {{TT:Tag|trainPart}}'s {{TT:Tag|ocpTT}} in respect of its {{TT:Tag|operatingPeriod}}. For operational trains ({{TT:Tag|train}} with {{Attr|type}}<nowiki>=</nowiki>'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.


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.
{{Deu|Mitternachtsübergänge im Allgemeinen weisen zwei zu betrachtende Aspekte auf:}}
* {{Deu|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.}}
* {{Deu|Ankünfte/Abfahrten eines {{TT:Tag|trainPart}}s nach Mitternacht finden an einem anderen Tag statt als vor Mitternacht bezogen auf die {{TT:Tag|operatingPeriod}}. Da nur eine {{TT:Tag|operatingPeriod}} pro {{TT:Tag|trainPart}} existiert, sind zusätzliche Mittel notwendig, um die tatsächlichen Tage zu bestimmen, an denen ein {{TT:Tag|trainPart}} an einer {{TT:Tag|ocpTT}} ankommt bzw. abfährt.}}


{{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:
Es ist nicht vorgesehen, den Zuglauf in einen {{TT:Tag|trainPart}} vor und einen nach Mitternacht zu teilen und für beide individuelle {{TT:Tag|operatingPeriod}}s zu erzeugen. Stattdessen werden die unterschiedlichen Verkehrstage des {{TT:Tag|trainPart}}s vor und nach Mitternacht durch unterschiedliche Werte in den Attributen {{Attr|arrivalDay}} and {{Attr|departureDay}} abgebildet. Diese Attribute drücken die Verschiebung des Tages der Ankünfte/Abfahrten eines {{TT:Tag|trainPart}}s an einer bestimmten {{TT:Tag|ocpTT}} in Bezug auf seine {{TT:Tag|operatingPeriod}} aus. Für betriebliche Züge ({{TT:Tag|train}} mit {{Attr|type}}<nowiki>=</nowiki>'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 / {{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 {{Attr|arrivalDay}}=1 and {{Attr|departureDay}}=1. Although the <operatingPeriod> states, that the <trainPart> runs from Monday to Friday, the actual operating periods of the arrivals/departures with an {{Attr|arrivalDay}}/{{Attr|departureDay}}<nowiki>=</nowiki>1 have to be interpreted as shifted by 1 day, i.e. as "Tuesday to Saturday"


{{Deu|
{{Deu|Alle weiteren Ankunfts-, Abfahrts- und Durchfahrtszeiten des (betrieblichen) Zuges bis zu seinem Laufwegende sind mit {{Attr|arrivalDay}}<nowiki>=</nowiki>1 und {{Attr|departureDay}}<nowiki>=</nowiki>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 {{Attr|arrivalDay}}/{{Attr|departureDay}}<nowiki>=</nowiki>1 als um einen Tag verschoben, d.h. als "Dienstag-Samstag" interpretiert werden.}}
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 --
      <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>
 
All further arrival, departure, and run through times of the (operational) train until the end of its route are marked with {{Attr|arrivalDay}}=1 and {{Attr|departureDay}}=1.<br>
{{Deu|Alle weiteren Ankunfts-, Abfahrts- und Durchfahrtszeiten des (betrieblichen) Zuges bis zu seinem Laufwegende sind mit {{Attr|arrivalDay}}<nowiki>=</nowiki>1 und {{Attr|departureDay}}<nowiki>=</nowiki>1 gekennzeichnet.}}
 
==== Example 3: Midnight overrun between linked <trainPart>s / {{Deu|Beispiel 3: Mitternachtsübergang zwischen verknüpften <trainPart>s}}====
 
<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 --
!-- here midnight overrun --
   <ocpTT ocpRef='ocp_DWT_N' ocpType='pass'>
   <trainPart id='tp_2_of_train_1'>
    <times scope='scheduled' departure='00:01:25' departureDay='1'/>
    <operatingPeriodRef ref='opp_1'/>
  </ocpTT>
    <ocpsTT>
  <ocpTT ocpRef='ocp_DWT' ocpType='stop'>
      <ocpTT ocpRef='ocp_DNKO' ocpType='stop'>
    <times scope='scheduled' arrival='00:02:17' arrivalDay='1' departure='00:03:00' departureDay='1'/>
        <times scope='scheduled' departure='00:00:19' departureDay='1'/>
   </ocpTT>
      </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>
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 {{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 {{Attr|arrivalDay}}=1 and {{Attr|departureDay}}=1.<br>


{{Deu|
{{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 nur 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 {{Attr|arrivalDay}}<nowiki>=</nowiki>1 und {{Attr|departureDay}}<nowiki>=</nowiki>1 gekennzeichnet.}}
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}}====
=== 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 {{Attr|arrivalDay}}/{{Attr|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>
* 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>
* In case a train did already run over midnight before the first departure in the railML data, its first {{TT:Tag|ocpTT}} may have an {{Attr|arrivalDay}}/{{Attr|departureDay}}>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.<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 <trainPart>s 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 {{Attr|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>


* {{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 ({{Attr|arrivalDay}}/{{Attr|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 ({{Attr|arrivalDay}}/{{Attr|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 (insbesondere kommerzielle, d. h. <train>s mit {{Attr|type}}&#61;'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.}}<br>


[[Datei:midnight_overrun_dayindex_backjump.png]]
[[file: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’.
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’.


''<nowiki>*</nowiki> ‘Normally’ as there wouldn’t be an apparent change of operating day if the trains would operate daily.''
''<nowiki>*</nowiki> ‘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.
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 {{Attr|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 {{Attr|departureDay}}=0 already happens after midnight, hence the back-jump.


{{Deu|<nowiki>
{{Deu|
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’.
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 ({{Attr|arrivalDay}}<nowiki>=</nowiki>1 auf {{Attr|departureDay}}<nowiki>=</nowiki>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’.
</nowiki>}}
}}


{{Deu|''<nowiki>
{{Deu|''<nowiki>
Line 104: Line 143:
</nowiki>''}}
</nowiki>''}}


{{Deu|<nowiki>
{{Deu|
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.
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 {{Attr|arrivalDay}}/{{Attr|departureDay}}-Angaben auf die Amsterdamer Abfahrt, und er kommt in Warschau mit {{Attr|arrivalDay}}<nowiki>=</nowiki>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 {{Attr|departureDay}}<nowiki>=</nowiki>0 liegt bereits nach Mitternacht, daher der Rücksprung.
</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.<br>
* The operating day reference (<operatingPeriodRef>) cannot be interpreted alone. This is only possible by including the corresponding day index ({{Attr|arrivalDay}}/{{Attr|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 ({{Attr|arrivalDay}}/{{Attr|departureDay}} + dayIndex).<br>
* 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.
* 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 are any numbers of combinations of <operatingPeriod> and arrival/departureDay which are semantically identical, e. g. they effectively describe the same days.<br>
* There may be an unlimited number of combinations of <operatingPeriod> and {{Attr|arrivalDay}}/{{Attr|departureDay}} which are semantically identical, i. e. they effectively describe the same days.<br>
* A writing software is free to choose any combination; it can even change the combination inside one train.<br>
* A writing software is free to choose any combination; it can even change the combination inside one train.<br>


* {{Deu|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 Tagesindex verschieben.<br>}}
* {{Deu|Die Verkehrstage-Angabe (<operatingPeriod>) ist allein nicht interpretierbar, sondern immer nur im Zusammenhang mit dem jeweiligen Tagesindex ({{Attr|arrivalDay}}/{{Attr|departureDay}}). Um festzustellen, wann ein Zug tatsächlich fährt, muss man z. B. die Bitmaske um die Anzahl Stellen aus ({{Attr|arrivalDay}}/{{Attr|departureDay}}+ dayIndex) verschieben.<br>}}
* {{Deu|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.<br>}}
* {{Deu|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.<br>}}
* {{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 ({{Attr|arrivalDay}}/{{Attr|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 ===
=== Why not use shifted/rotated <operatingPeriod>s / {{Deu| Warum rotierte/verschobene <operatingPeriods> nicht verwendet werden sollten}} ===


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).
In the introduction of this page it was recommended to use the day offset attributes {{Attr|arrivalDay}}/{{Attr|departureDay}} instead of individuelly shifted <operatingPeriod>s for <trainPart>s before and after midnight. Reasons for this recommendation are:


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).
* 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>.{{Attr|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.


This solution is explicitly not wanted because of the following reasons (inter alia):<br>
{{Deu|In der Einleitung dieser Seite wurde empfohlen, die Offset-Attribute {{Attr|arrivalDay}}/{{Attr|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:}}
* 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.
* {{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>.{{Attr|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 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“).}}


<syntaxhighlight lang="xml">
[1] {{external|http://www.irfp.de/download/railml_beispiel_verkehrstage.pdf|Weitere Informationen und RailML-Beispiel zu Verkehrstagen|type=PDF|comment=185 kByte}}
  <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>I. d. R. 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>}}
[2] [[Dev:Examples for a non-zero operating day offset at the first ocpTT of a train run|Examples for a non-zero operating day offset at the first ocpTT of a train run]]


{{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>}}
[[category:Timetable Concept]]

Revision as of 11:07, 19 June 2018

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.

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 ‘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 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.

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