Home » railML newsgroups » railml.timetable » Wendevorgaben
| Re: Wendevorgaben [message #717 is a reply to message #707] |
Mon, 04 April 2011 14:49   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Hallo Herr Jobmann und hallo miteinander,
das Interesse an den Wendevorgaben ist für mich durchaus nachvollziehbar.
Wir sollten nur klar unterscheiden (und das ist ja wohl auch so
angesprochen worden) zwischen Soll-Vorgaben und dem oder den konkreten
Umlaufplan/-plänen.
Bei vollständiger Angabe von Wendevorgaben an allen Zügen ließe sich der
Umlaufplan eindeutig rekonstruieren. Es sollte hier aber nicht darum
gehen, eine zweite Möglichkeit zur Umlaufbeschreibung in RailML
einzubringen - Redundanzen sind immer schlecht vor allem für ein lesendes
Programm. Vielmehr sollten es wirklich "Wendevorgaben" im Sinne von
Zwangsübergängen (-> Teilmenge eines Umlaufs) oder vor allem für den Fall,
dass noch gar kein Umlauf besteht, sein.
Ein etwaiger Widerspruch zwischen den Umlauf und Wendevorgabe sollte mit
klarer Priorität versehen sein, vmtl. auf dem Umlauf. Die Wendevorgaben
haben also den Charakter "nice to have".
Solche Wendevorgaben waren unter dem Oberbegriff "fahrplantechnische
Bindungen" bereits vorgesehen. Leider ist dies (wie so vieles) in den
Wirren von RailML 0.9x und der "Verenglischung" untergegangen. Wir finden
die unsterblichen Reste in der fahrplantechnischen Bindungen in trainPart
-> ocpTT -> connections. Dass es hier wirklich um alle fahrplantechnischen
Bindungen und nicht nur um Anschlüsse (wie die Übersetzung suggeriert)
geht, erkennt man am Element "connOperation": Hier gibt es auch
"turnaround", was auf die Wendevorgaben abzielte.
Natürlich sind die alten fahrplantechnischen Bindungen - egal, ob nun
Anschlüsse oder Wendevorgaben - nicht hinreichend (sind sie in RailML nie
gewesen, da vmtl. etwas schwieger-, äh stiefmütterlich behandelt). Vor
allem fehlt eine Möglichkeit, sie verkehrstage- und zugteilabhängig zu
machen. Für Anschlüsse mag es egal (oder selbsterklärend) sein, auf
welchen Zugteil der Anschluss stattfindet; spätestens für Wendevorgaben
ist es nicht mehr egal.
Alternativ würde ich vorschlagen, im Umlauf selbst bei den Übergängen
(Abfolgen) eine Möglichkeit zu schaffen, dort anzugeben, ob der Übergang
aus einer Zwangsbindung heraus festgelegt wurde oder ob er "frei" (z. B.
aus einer Optimierung heraus) entstanden ist. Damit ließen sich die
Wendevorgaben ermitteln durch "scannen" des Umlaufs auf Zwangsbindungen
hin. Als solche Zwangsbindungs-Kennzeichnung würde theoretisch zunächst
ein boolscher Wert reichen, und wir kämen damit zunächst viel einfacher
zum Ziel. (Im Prinzip geht es schon indirekt durch die Zusammenfassung von
blockParts zu blocks, allerdings ist dies nicht zwangsläufig auf
Zwangsübergänge beschränkt.)
Fazit (mein Vorschlag):
- Ausbau des connection-Elements auf die Möglichkeit, die
fahrplantechnische Bindung etwas exakter zu formulieren (z. B. explizit
Zwangsübergang) und sie verkehrstage- und zugteilabhängig machen (Aufnahme
von operatingPeriodRef und trainPartRef)
- Aufnahme eines boolschen Werts bei den connections zur Kennzeichnung
von Übergängen im Umlauf, die auf Grund von Zwangsbindungen entstanden
sind.
- Da wir eine (im Prinzip derzeit schon bestehende) Redundanz haben:
Beschreibung der Priorität, dass im Zweifelsfall der konkrete Umlauf
(circulation) Vorrang vor der Wendevorgabe (connection) hat und die
Wendevorgabe mehr so ein Sollwert sein soll...
Viele Grüße,
Dirk Bräuer.
---
Am 16.03.2011, 08:37 Uhr, schrieb Christoph Jobmann
<christophjobmann(at)deutschebahncom>:
> Hallo miteinander,
>
> ich hatte im Rahmen des gestrigen Treffens in Innsbruck angemerkt, dass
> Interesse besteht, Wendevorgaben in RailML abbilden zu können. Zunächst
> möchte ich kurz ausführen, was ich mir darunter vorstelle:
>
> In Einzelfällen kann es angebracht sein, für bestimmte Fahrten die
> jeweils nachfolgende Fahrt bereits als Bestandteil des Fahrplans (nicht
> des Umlaufplans) zu übergeben. Ein auf Basis solch eines Fahrplans
> erstellter Umlaufplan sollte solch eine Vorgabe dann natürlich auch
> berücksichtigen. In diesem Zusammenhang ist - je nach Situation - mal
> von
> einer Durchbindung, mal von einer Zwangsbindung oder auch einer
> Wendevorgabe die Rede.
>
> Nach einer kurzen Diskussion kamen wir zu dem Schluss, dass dies am
> ehesten im Einklang mit dem timetable-Teilschema zu lösen ist, indem
> jene
> Elemente verwendet werden, die für die Abbildung von Umläufen
> vorgesehen
> sind - auch wenn de facto noch kein (vollständiger) Umlauf vorliegt.
>
> Ein Kritikpunkt an dieser Vorgehensweise war zunächst noch, dass diese
> Vorgaben nicht mehr erkennbar wären, wenn für diesen Fahrplan ein
> Umlaufplan erstellt und wieder exportiert würde. Die "fixed"-Attribute
> der Elemente "blockPart" und "block" sehen zwar vielversprechend aus,
> können jedoch nicht sinnvoll genutzt werden, da die zu fixierenden
> Entitäten die Übergänge sind - für welche aber keine konkreten
> Objekte
> vorliegen.
>
> Für diese Problemstellung habe ich schließlich eine Lösung gefunden -
> und bitte hiermit um Rückmeldung, ob sie für brauchbar gehalten wird.
>
> Diese Lösung stelle ich mir folgendermaßen vor:
> Es wird ein neuer Typ "tRosteringScope" eingeführt, welcher als Vorgabe
> die Werte "timetable" oder "schedule" annehmen kann.
> Weiter erhält das Element "rostering" ein zusätzliches Attribut namens
> "scope", welches den Typ "tRosteringScope" hat.
> Ein "rostering"-Element mit "scope=timetable" würde dann Wendevorgaben /
> Zwangs- / Durchbindungen beschreiben. Dabei würden vermutlich nicht alle
> Elemente zum Einsatz kommen: "circulations" und "circulation" würde
> besipielsweise nicht benötigt.
> Ein "rostering"-Element mit "scope=schedule" würde - wie bisher - einen
> Umlaufplan abbilden.
>
> Für Rückmeldungen jeglicher Art bin ich dankbar.
>
> Folgende Punkte habe ich dabei noch bewusst offen gelassen:
> - Wie sind Zwangsbindungen anzulegen, die über die Grenze eines
> "block"-Elements hinausgehen? [ Vorschlag: für "scope=timetable" kann
> die
> Länge eines "block" von der Länge für "scope=schedule" abweichen. ]
> - Ist für jede Zwangsbindung ein eigenes "rostering"-Element anzulegen,
> oder können/sollten alle in einem untergebracht werden? [ Vorschlag: Ein
> "rostering"-Element pro Zwangsbindung ]
>
> Viele Grüße
> Christoph Jobmann
>
> DB Mobility Logistics AG
>
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
|
|
|
|
Current Time: Fri May 17 01:25:46 CEST 2024
|
Members
Search
Help
Login
Home
