Re: Facultative trains / BedarfszuÌge [message #2274 is a reply to message #2243] |
Wed, 13 November 2019 09:15 |
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
|
|
|