Difference between revisions of "Dev:Midnight overrun"

From wiki.railML.org
Jump to: navigation, search
[checked revision][checked revision]
(Reference place for day indexes / midnight overruns / {{Deu|Referenzort der Tages-/Mitternachtszählung}})
m (correction of spelling errors)
Line 111: Line 111:
 
* 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>
 
* 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 is an unlimited number of combinations of <operatingPeriod> and arrival/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>
  
Line 179: Line 179:
 
The aim of the following example is to show the two general possibilities of “coaction” of {{Attr|arrival/departureDay}} and {{Attr|dayOffset}} in context.
 
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 not 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.
+
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|Das folgende Beispiel soll die beiden grundsätzlichen Möglichkeiten des Zusammenspiels zwischen den Attributen {{Attr|arrival/departureDay}} und {{Attr|dayOffset}} verdeutlichen.}}

Revision as of 10:26, 9 June 2017

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

General / Allgemeines

There are several 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…
  • a) …and using the attribute dayOffset (introduced with version 2.2) at the <operatingPeriod> after midnight,
  • b) …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. It is explicitly not wanted to break a train’s run into <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.

Es gibt mehrere 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…
  • a) …und Verwenden des Attributs dayOffset (introduced with version 2.2) der nach Mitternacht gültigen <operatingPeriod>,
  • b) …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. Es ist ausdrücklich nicht vorgesehen, einen Zuglauf nur wegen des Mitternachtsübergangs in <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 / Mitternachtsübergänge innerhalb des abgebildeten Zuglaufs

The attributes arrivalDay and 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.

Für Mitternachtsübergänge innerhalb eines abgebildeten Zuglaufs sind in railML die Attribute arrivalDay und 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:

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

  <ocpTT ocpRef='ocp_DOLB' ocpType='stop'>
!--                                            | here midnight overrun 
!--                                            v 
    <times scope='scheduled' arrival='23:59:49' departure='00:00:19' departureDay='1'/>
    <sectionTT section='DOLB-DN E' lineRef='ln_80.6212' trackRef='tr_80.6212_2' trackInfo='1'>
      <runTimes minimalTime='PT48S' operationalReserve='PT1S'/>
    </sectionTT>
    <stopDescription commercial='true' stopOnRequest='false'>
      <stopTimes minimalTime='PT30S'/>
    </stopDescription>
  </ocpTT>

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.

Alle weiteren Ankunfts-, Abfahrts- und Durchfahrtszeiten des 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

  <ocpTT ocpRef='ocp_DNKW' ocpType='pass'>
    <times scope='scheduled' departure='23:55:00'/>
  </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_N' ocpType='pass'>
    <times scope='scheduled' departure='00:01:25' 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>

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.

Alle weiteren Ankunfts-, Abfahrts- und Durchfahrtszeiten des 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).
  • 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.
  • 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.

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):

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

Because of these reasons, the attribute <operatingPeriod>.dayOffset has been introduced from railML 2.2 onwards.

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

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.

Mitternachtsübergänge außerhalb des abgebildeten Zuglaufs

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.

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.

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:

  • 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“).

Aus diesen Gründen wird mit railML 2.2 neu das Attribut dayOffset im Element <operatingPeriod> eingeführt:

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

Die Bitmaske der mit dayOffset≠0 anzugebenden operatingPeriods ist nicht verschoben darzustellen, d. h. die Bitmaske ist identisch wie beim Fall dayOffset=0.

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.

Summary: Combinded example with arrival/departureDay and <dayOffset> / Zusammenfassendes Beispiel

The aim of the following example is to show the two general possibilities of “coaction” of arrival/departureDay and 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.

Das folgende Beispiel soll die beiden grundsätzlichen Möglichkeiten des Zusammenspiels zwischen den Attributen arrival/departureDay und dayOffset verdeutlichen.

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 <operatingPeriod> only

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


The midnight overrun is expressed by the attributes arrival/departureDay only. There is only one <operatingPeriod> necessary for this example, the attribute dayOffset is not used.

Der Mitternachtsübergang wird nur durch die Attribute arrival/departureDay ausgedrückt. Es ist nur ein Element <operatingPeriod> notwendig für dieses Beispiel; das Attribut dayOffset wird nicht verwendet.

b) With two <operatingPeriod>s and the attribute dayOffset

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


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

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.