| Re: TT:blockPart: Semantic Constraint [message #2889 is a reply to message #2888] |
Fri, 28 January 2022 15:10   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Hallo Patrik,
willkommen im railML-<Timetable>-Forum!
Als traditionell umlaufaffiner Mitwirkender fühle ich mich mit dieser Frage einmal angesprochen.
Zunächst: Das Anliegen und die Beschreibung des Bedarfs sind im Wesentlichen nachvollziehbar, danke für die gute Beschreibung.
> Dies würde für unsere Betriebsfälle, also
> sehr häufige Formationswechsel auf der Strecke, die sich
> auch zeitlich nicht systematisieren lassen (also
> unregelmäßig auftreten)...
Gewünscht ist ein Beschränken des Laufwegs (startOcpRef und endOcpRef) auf einen Teil des Laufwegs des referenzierten <trainPart>s. Ich verstehe nicht, wie in dem Zusammenhang "zeitlich nicht systematisieren lassen" gemeint ist. Der referenzierte <trainPart> hätte an den jeweiligen <ocpTT>s immer planmäßige Ankunfts- und Abfahrtszeiten. Diese Zeiten wäre i. S. des Fahrplans einschl. Umlaufplans ausreichend Systematisierung - mehr ist gar nicht notwendig.
Um Missverständnisse zu vermeiden, daher nochmal die Rückfrage:
a) Wird hier ein Fall beschrieben, in dem der Umlaufplan eine detailliertere Abbildung umfasst als der allgemeinen Fahrplan (<trainPart>s und dessen übergeordnete Elemente)? Das würde bedeuten, dass in der Formation des referenzierten <trainPart>s Fahrzeuge enthalten sind, die im Zug inzwischen gar nicht mehr oder noch nicht mitfahren.
b) Sind sich Umlaufplan und allgemeiner Fahrplan hinsichtlich Abbildungsgenauigkeit einig? Dann sollte das ganze ohne Mehraufwand an <trainPart>s abbildbar sein.
Wenn es sich um (b) handelt - wovon ich ausgehe -, muss tatsächlich jedem Zwischenbahnhof (<ocpTT>), an dem die Umlaufpläne ein An- oder Abhängen von Wagen vorsehen, ein neuer <trainPart> gebildet werden. Das ist logische Konsequenz der gleichen Abbildungsgenauigkeit: Wo unter <rostering> was an- oder abgehangen wird, muss auch unter <trainParts> was an- oder abgehangen werden.
ABER: Es muss nicht für jedes einzelne an- oder abzuhängende Fahrzeug ein neuer <trainPart> gebildet werden! Daher ist es keine Redundanz und m. E. kein signifikanter Mehraufwand gegenüber lang durchgehenden <trainPart>s. Es wird einfach nur ein langer <trainPart> in mehrere kurze, sequentiell verkettete <trainPart>s aufgeteilt - ohne Überlappung, ohne Redundanz.
> Aus diesem Grund wollen wir anfragen, ob dieses Semantic
> Contraints so angepasst werden kann, dass ein trainPart von
> mehreren blockParts (mit verschiedenen Formationen)
> referenziert werden kann, immer unter Berücksichtigung der
> Anforderung, dass der gesamte trainPart von blockParts
> abgedeckt wird.
Dieser Formulierung würde ich voll zustimmen: Ein <trainPart> kann von mehreren <blockPart>s aus verschiedenen Umlaufplänen (<rostering>s) referenziert werden kann, unter den rein semantischen Bedingungen
- dass das oder die Fahrzeuge des Umlaufplans auch in der Formation des <trainPart>s enthalten sind,
- dass möglichst(?) jedes Fahrzeug der Formation des <trainPart>s durch genau einen Umlaufplan erfasst ist.
Wenn also ein <trainPart> folgende Formation hat: "Lok + 2x WagenA + 3x WagenB", dann darf es gern
- einen Umlaufplan für die Lok, einen anderen für "2x WagenA" und einen dritten für "3x WagenB" geben
oder
- einen Umlaufplan für die Lok und einen anderen für "2x WagenA + 3x WagenB" geben
oder
- je einen (insgesamt 6) Umlaufplan für jedes einzelne Fahrzeug im Zug
oder
viele andere mögliche Kombinationen.
Im nächsten Abschnitt (hier: <trainPart>) des Zuges kann die Formation anders aussehen (etwa nur noch "Lok + 2x WagenA + 2x WagenB" = 1x WagenB wurde abgekuppelt) und demzufolge auch die Anzahl Umlaufpläne anders sein, die diesen <trainPart> erfassen.
Hilft das zur Einschätzung der Situation aus Sicht railML weiter?
Falls ich etwas missverstanden oder mit meiner Interpretation der Anforderungen falsch liegen sollte, bitte nochmal melden.
Viele Grüße,
Dirk Bräuer.
|
|
|
|
Members
Search
Help
Login
Home
