Dev:Examples for a non-zero operating day offset at the first ocpTT of a train run: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
(Import)
 
Line 1: Line 1:
'''Anwendungsfälle für departureDay<>0 an der ersten <ocpTT> eines Zuglaufs'''
'''Anwendungsfälle für departureDay<>0 an der ersten <ocpTT> eines Zuglaufs'''
==Laufweg des Zuges ist nicht vollständig in der railML-Datei abgebildet==
==Laufweg des Zuges ist nicht vollständig in der railML-Datei abgebildet==
Ist ein Zug nicht mit seinem gesamten Laufweg in der railML-Datei enthalten und weist er vor dem „Eintritt“ in das Netz der railML-Datei bereits einen Mitternachtsübergang auf, so muss entweder seine <operatingPeriod> rotiert bzw. verschoben werden oder er hat an seiner ersten <ocpTT> einen arrivalDay/departureDay von 1.
Ist ein Zug nicht mit seinem gesamten Laufweg in der railML-Datei enthalten und weist er vor dem „Eintritt“ in das Netz der railML-Datei bereits einen Mitternachtsübergang auf, so muss entweder seine {{TT:Tag|operatingPeriod}} rotiert bzw. verschoben werden oder er hat an seiner ersten {{TT:Tag|ocpTT}} einen arrivalDay/departureDay von 1.
<syntaxhighlight lang=xml>
<syntaxhighlight lang=xml>
<operatingPeriod id="opp0" bitMask="0111110..0111110" name="Montag-Freitag" />
<operatingPeriod id="opp0" bitMask="0111110..0111110" name="Montag-Freitag" />
Line 17: Line 17:
</trainPart>
</trainPart>
</syntaxhighlight>
</syntaxhighlight>
Der Zug beginnt bereits außerhalb der Infrastruktur der railML-Datei jeweils an den Verkehrstagen „Montag-Freitag“. Da er vor dem Eintritt in die Infrastruktur der railML-Datei bereits einmal über Mitternacht verkehrt ist, haben alle sein <ocpTT>-Elemente ein arrivalDay / departureDay von 1, d.h. an diesen Betriebsstellen kommt der Zug tatsächlich jeweils am Folgetag von Montag-Freitag vorbei, also Dienstag-Samstag.  
Der Zug beginnt bereits außerhalb der Infrastruktur der railML-Datei jeweils an den Verkehrstagen „Montag-Freitag“. Da er vor dem Eintritt in die Infrastruktur der railML-Datei bereits einmal über Mitternacht verkehrt ist, haben alle sein {{TT:Tag|ocpTT}}-Elemente ein arrivalDay / departureDay von 1, d.h. an diesen Betriebsstellen kommt der Zug tatsächlich jeweils am Folgetag von Montag-Freitag vorbei, also Dienstag-Samstag.
 
==Synchronisation von Flügelzügen vor und nach Mitternacht==
==Synchronisation von Flügelzügen vor und nach Mitternacht==
Gegeben ist ein Konstrukt aus 2 Flügelzügen, deren Zugteile wie folgt zu betrieblichen Zügen verknüpft sind:
Gegeben ist ein Konstrukt aus 2 Flügelzügen, deren Zugteile wie folgt zu betrieblichen Zügen verknüpft sind:

Revision as of 15:56, 17 May 2018

Anwendungsfälle für departureDay<>0 an der ersten <ocpTT> eines Zuglaufs

Laufweg des Zuges ist nicht vollständig in der railML-Datei abgebildet

Ist ein Zug nicht mit seinem gesamten Laufweg in der railML-Datei enthalten und weist er vor dem „Eintritt“ in das Netz der railML-Datei bereits einen Mitternachtsübergang auf, so muss entweder seine <operatingPeriod> rotiert bzw. verschoben werden oder er hat an seiner ersten <ocpTT> einen arrivalDay/departureDay von 1.

<operatingPeriod id="opp0" bitMask="0111110..0111110" name="Montag-Freitag" />

<trainPart id="tp1">
	<operatingPeriodRef ref="opp0"/>
	<ocpsTT>
		<ocpTT ocpRef="ocp1" sequence="1" ocpType="stop">
			<times scope="scheduled" arrivalDay="1" arrival="02:00:00" departureDay="1" departure="02:15:00"/>
		</ocpTT>
		<ocpTT ocpRef="ocp2" sequence="2" ocpType="stop">
			<times scope="scheduled" arrivalDay="1" arrival="02:30:00"/>
		</ocpTT>
	</ocpsTT>
</trainPart>

Der Zug beginnt bereits außerhalb der Infrastruktur der railML-Datei jeweils an den Verkehrstagen „Montag-Freitag“. Da er vor dem Eintritt in die Infrastruktur der railML-Datei bereits einmal über Mitternacht verkehrt ist, haben alle sein <ocpTT>-Elemente ein arrivalDay / departureDay von 1, d.h. an diesen Betriebsstellen kommt der Zug tatsächlich jeweils am Folgetag von Montag-Freitag vorbei, also Dienstag-Samstag.

Synchronisation von Flügelzügen vor und nach Mitternacht

Gegeben ist ein Konstrukt aus 2 Flügelzügen, deren Zugteile wie folgt zu betrieblichen Zügen verknüpft sind:

Abbildung in railML mit 2 betrieblichen Zügen: Bf_A – Bf_C – Bf_D (blau) Bf_B – Bf_C (rot) Die Fahrzeuge des Zugteiles “tp1_1” von Zug 1 sollen in Bf_C auf den Zug 2 umgekuppelt werden und von dort aus als Zugteil „tp1_2“ (ohne Verkehrstagewechsel) weiterlaufen.

<train trainNumber="1" type="operational">
	<!-- Von  Bf_B nach Bf_C -->
	<trainPartSequence sequence="1">
		<trainPartRef ref="tp1_1"/>
	</trainPartSequence>
</train>

<train trainNumber="2" type="operational">
	<!-- Von Bf_A nach Bf_C -->
	<trainPartSequence sequence="1">
		<trainPartRef ref="tp2_1"/>
	</trainPartSequence>
	<!-- Von Bf_C nach Bf_D -->
	<trainPartSequence sequence="2">
		<trainPartRef ref="tp2_2" position="1"/>
		<trainPartRef ref="tp1_2" position="2"/>
	</trainPartSequence>
</train>

Zug 2 (Zugteil tp2_1 von Bf_A nach Bf_C) hat die Verkehrstage „Montag-Freitag“ und fährt bereits vor seiner Vereinigung mit Zug 1 in Bf_C einmal über Mitternacht. Da in Bf_C keine Wechsel der Verkehrstage geplant ist, haben die Zugteile tp2_2 und tp1_2 nach ihrer Vereinigung weiterhin die Verkehrstage „Montag-Freitag“ und an ihrer ersten <ocpTT> einen departureDay=1. Damit die Zugteile an Bf_C ohne „übrig bleibende“ Verkehrstage aneinanderpassen, bleiben für die Verkehrstage des Zugteils tp1_1 zwei gültige Möglichkeiten: Ebenfalls Verkehrstage „Montag-Freitag“ und departureDay=“1“ (wie tp1_2) oder Verkehrstage „Dienstag-Samstag“ und departureDay=“0“ („shiften“ der <operatingPeriod> um einen Tag nach „hinten“) Die Abbildungsvariante 1 führt daher ebenfalls zu einem departureDay>0 an der ersten <ocpTT> des Zuglaufs.

Erster Zug des Fahrplanjahrs vor Mitternacht

Durch die Angabe eines Wertes <> 0 für arrivalDay / departureDay können auch Verkehrstage-Informationen für Züge außerhalb der eigentlichen Fahrplanperiode (timetablePeriod) angegeben werden. Denkbar wäre z.B. ein Zug, der kurz vor Mitternacht beginnt und am ersten Tag der Fahrplanperiode bereits vor Mitternacht beginnen soll.

<timetablePeriod id="ttp0" startDate="2020-12-13" endDate="2021-12-11" name="2020/21"/>

<operatingPeriod id="opp0" timetablePeriodRef="ttp0" bitMask="11111...11111" name="täglich"/>

<trainPart id="tp1">
	<operatingPeriodRef ref="op1"/>
	<ocpsTT>
		<!-- Zug soll bereits am "Vorabend" des Fahrplanwechsels, d.h. am 12.12.2020 das erste Mal beginnen. Dies wird durch departureDay="-1" ausgedrückt -->
		<ocpTT ocpRef="ocp1" sequence="1" ocpType="stop">
			<times scope="scheduled" departure="23:55:00" departureDay="-1"/>
		</ocpTT>
		<!-- hier erfolgt Mitternachtsübergang, d.h. arrivalDay/departureDay springt von -1 auf 0 -->
		<ocpTT ocpRef="ocp3" sequence="3" ocpType="stop">
			<times scope="scheduled" arrival="00:01:00" arrivalDay="0" departure="00:02:30" departureDay="0"/>
		</ocpTT>
		<ocpTT ocpRef="ocp4" sequence="4" ocpType="stop">
			<times scope="scheduled" arrival="00:04:00" arrivalDay="0"/>
		</ocpTT>
	</ocpsTT>
</trainPart>

Anmerkung: Bei dieser Abbildung ist der letzte Tag, an dem der Zug in diesem Fahrplanjahr beginnen kann, der 10.12.2021 (vorletzter Tag der Fahrplanperiode), da der Zug nur so oft verkehren kann, wie das Fahrplanjahr Tage aufweist = Länge der Bitmasken.