Home » railML newsgroups » railml.timetable » Facultative trains / Bedarfszüge (Clarify handling of facultative trains)
Re: Facultative trains / Bedarfszüge [message #2274 is a reply to message #2243] Wed, 13 November 2019 09:15 Go to previous messageGo to previous message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 59
Registered: March 2015
Member
Hello,

I agree that it is currently not practicable to represent facultative
trains. From my point of view, two solutions are possible:

1) The differentiation between regular and facultative operating days
takes place within the <operatingPeriod>. Since a combination of regular
and facultative operating days can occur (see Philips example "Mo-Fr
runs regularly and on Sa on demand"), all elements of the
<operatingPeriod> would have to be duplicated. In addition, there is a
rule that more than one <operatingDay> element may occur in one
<operatingPeriod>, but only if "startDate" / "endDate" ensures that they
do not overlap. This rule would also have to be abandoned.

2) Separate <operatingPeriods> and correspondingly separate <trainPart>s
are used for regular and facultative operating days. In this case the
<operatingPeriod> would have to get a new attribute "onRequest", the
attribute of the same name on <operatingDay> would be dropped.
Disadvantage would be a certain redundancy, since additional
<trainPart>s have to be created, which will often be identical except
for the <operatingPeriodRef>. But the change effort is clearly smaller,
likewise the comprehensibility of the element <operatingPeriod> becomes
clearly better from my point of view.

Due to the described advantages and disadvantages we would plead for
variant 2.

Best regards
Christian Rößiger

------------------------------------------------------------ ---------
German version:

Hallo,

ich stimme zu, dass die Abbildung von Bedarfszügen derzeit nicht
praktikabel möglich ist. Aus meiner Sicht wären zwei Lösungen denkbar:

1) Die Differenzierung nach regulären und Bedarfs-Verkehrstagen erfolgt
innerhalb der <operatingPeriod>. Da eine Mischung von regulären und
Bedarfs-Verkehrstagen vorkommen kann (siehe Philips Beispiel "verkehrt
Mo-Fr regelmäßig und an Sa nach Bedarf"), müßten alle Elemente der
<operatingPeriod> dupliziert werden. Außerdem besteht bisher die Regel,
dass mehrere <operatingDay> - Elemente in einer <operatingPeriod>
auftreten dürfen, aber nur, wenn via "startDate" / "endDate" sicher
gestellt ist, dass sie sich nicht überlappen. Diese Regel müßte
ebenfalls aufgegeben werden.

2) Es werden für reguläre und Bedarfs-Verkehrstage jeweils eigene
<operatingPeriods> und dementsprechend auch separate <trainPart>s
verwendet. In diesem Fall müßte die <operatingPeriod> ein neues Attribut
"onRequest" erhalten, das gleichnamige Attribut am <operatingDay> würde
entfallen. Nachteil wäre eine gewisse Redundanz, da zusätzliche Zugteile
angelegt werden müssen, die außer der <operatingPeriodRef> oft identisch
sein werden. Dafür ist der Änderungsaufwand deutlich geringer, ebenso
wird aus meiner Sicht die Verständlichkeit des Elements
<operatingPeriod> deutlich besser.

Aufgrund der beschriebenen Vor- und Nachteile würden wir daher für
Variante 2 plädieren.

Viele Grüße
Christian Rößiger

--
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: @onRequest of <operatingDay> to be declared deprecated
Next Topic: Published station track vs actual station track
Goto Forum:
  


Current Time: Fri Mar 29 10:13:33 CET 2024