| Re: Wendevorgaben [message #720 is a reply to message #717] |
Wed, 06 April 2011 05:01  |
Christoph.Jobmann
Messages: 12
Registered: October 2010
|
Junior Member |
|
|
Hallo Herr Bräuer und weitere Mitlesende,
ich hielt es zunächst auch für die naheliegenste Lösung, das
connection-Element zu nutzen, was aber beim Treffen in Innsbruck
weitgehend abgelehnt wurde. Die Variante der rosterings mit scope
timetable wurde als sauberer im Sinne von railML gehalten und daher auch
durch Herrn Rubröder umgesetzt.
Den vorgeschlagenen Ausbau des connection-Elements halte ich damit nicht
für zielführend. Hinzu kommt, dass ich den Nutzen des vorgeschlagenen
boolschen Attributs zur Identifikation von durch Zwangsbindung vorgegebene
Ãbergänge nicht nachvollziehen kann: Entweder es gibt für einen
Ãbergang eine entsprechende conntion oder eben nicht.
Interessant finde ich jedoch den Punkt der Priorität für Wendevogaben:
Tatsächlich ist es Bestandteil unserer Optimierung, dass grundsätzlich
eine Wende vorgegeben werden kann, die jedoch nicht zwangsläufig
eingehalten werden muss. Ob bzw. wie eine entsprechende Information jedoch
übergeben werden sollte ist mir zunächst nicht klar, da wir
beipsielsweise mit "Modellkosten pro nicht umgesetzter Zwangsbindung"
arbeiten und nicht mit Prioritäten, weshalb ich eine entsprechende
Erweiterung vermutlich nicht für 2.1 für sinnvoll halte.
Viele GrüÃe
Christoph Jobmann
Dirk Bräuer wrote:
>
> 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.
--
----== posted via PHP Headliner ==----
|
|
|
|
Members
Search
Help
Login
Home
