Home » railML newsgroups » railml.timetable » separation of <ocpTT> from <trainPart> - meeting 11.11.
| Re: addendum: separation of <ocpTT> from <trainPart> - meeting 11.11. [message #1272 is a reply to message #962] |
Mon, 08 December 2014 13:09  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Lieber Joachim und liebe Mitlesende,
ich möchte zunächst nur zu Protokoll geben, dass der einleitende
Forumseintrag von mir nur eine Art Protokoll des Treffens vom 11.11.2013
sein sollte. Nicht alles davon kann ich auch inhaltlich vertreten.
Daher sehe ich hier auch die Vertreter gefragt, die diese Anträge
inhaltlich eingebracht haben. Inzwischen steht das Thema aber über ein
Jahr ohne weitere Beiträge. Wenn wir die Gelegenheit eines
"refactorings" für 3.0 nutzen wollen, müssen wir uns mal positionieren.
---
Joachim, ich stimme Dir voll zu, dass vieles von dem Beantragten auch
ohne großes "refactoring" quasi auf dem kleinen Dienstweg gelöst werden
könnte, wie beispielsweise durch Erweiterung von <trainGroup>.type.
Einzig die eingangs (meines ursprünglichen Beitrags) erwähnte Redundanz
der Zeitenabfolge _gekuppelter_ Zugteile würde dadurch nicht beseitigt.
Es könnte aber ein durchaus in Frage kommendes (und meiner persönlichen
Meinung nach auch zu begrüßendes) "Minimal-refactoring" sein, wenn man
die Zeitenabfolge etwa in die von Andreas Tanner schon mal
vorgeschlagene <itinaries> auslagerte und den Rest ließe wie es ist.
---
zu /trainNumber/, /scope/, /additionalTrainNumber/:
> Hier stellt sich die Frage, wie das in anderen Ländern gehandhabt wird,
> die nicht zwischen Hauptlauf und Nebenlauf eines Zuges unterscheiden,
> wie es die DB in Deutschland tut.
....
> Wie werden diese Szenarien außerhalb der Deutschen Bahn unterschieden?
Meiner bescheidenen, natürlich nicht vollständigen Erfahrung nach gibt
es diese Phänomene in anderen Ländern so nicht.
Traditionell wird sowieso die Verkehrstageregelung (und die
Fahrplanperiode) in den Primärschlüssel eines Zuges einbezogen (also zum
eindeutigen Identifizieren eines Zuges mitbenutzt). Das hat zwar
Nachteile in der Planungsphase, wenn sich die Verkehrstageregelung eines
Zuges noch ändern kann. Diese Nachteile würden aber railML-seitig durch
eindeutige /code/s oder (zunkünftig eventuell) /UUID/s leicht
beherrschbar sein. Nach der Planungsphase (bei
Fahrplan-Veröffentlichungen usw.) ist die Identifikation über
Verkehrstage aber m. E. überall gelebte Praxis.
Ansonsten: Die anderen mir bekannten Länder/Staatsbahnen behaupten, in
vergleichbaren Fällen einfach eine neue Zugnummer zu vergeben anstatt
sowas wie Hauptlauf und Nebenlauf derselben Zugnummer zu unterscheiden.
Hier kommen wir zu dem allerdings nicht ganz von der Hand zu weisenden
Argument, das die DB Netz AG Europas größtes EIU ist, der damit von
allen als erster die (fünfstelligen) Zugnummern ausgehen. Warum keine
mehr als fünfstelligen Zugnummern verwendet werden... hat wohl mit viel
"alter" Software zu tun, die das nicht verarbeiten und nicht von heute
auf morgen geändert werden kann.
Es ist Fakt, dass die DB Netz AG derzeit noch die Mehrfachverwendung von
Zugnummern praktiziert und von ihren EVUs auch verlangt. Es ist wohl
nicht am railML-Konsortium, das zu werten. Wenn wir es für railML
ausschließen wollen, dann verschließen wir uns de facto vor Anwendungen
mit Kompatibilität zu DB Netz. Wollen wir das?
Gedacht war, dass /trainNumber/, /scope/ und /additionalTrainNumber/ für
sich immer eindeutig sein müssen, was dem DB-Netz-Fall genügt, aber auch
jede Teilmenge zulässt - also keine Verwendung von /scope/ und
/additionalTrainNumber/, womit die /trainNumber/ allein eindeutig zu
sein braucht. Das sollte damit m. E. allen bekannten Fällen genügen. Hat
jemand damit ein Problem?
> Es geht also um Züge, die an verschiedenen Verkehrstagen die gleiche
> Betriebsstellenabfolge zu gleichen Zeiten absolvieren, jedoch an
> ausgewählten Tagen einen Teil der Betriebsstellen weglassen oder darüber
> hinaus etwas weiter verkehren.
Nicht nur. Es geht vor allem auch um Züge, die an allen Tagen die
gleiche Betriebsstellenabfolge absolvieren, aber nicht an allen Tagen im
Detail zu den gleichen Zeiten. Guckst Du hier: [1].
---
> Ein typisches "Änderungsmanagement" ist mit railML derzeit nicht
> vorgesehen. Dieses Thema könnte separat diskutiert werden. Dass dafür
> Bedarf vorhanden ist, wurde schon häufiger signalisiert.
Ich stimme Dir voll zu.
> Verschiedene Planungszustände sind mit dem 'trainGroup' Element und
> 'processStatus' Attribut abbildbar. Jedoch kann damit kein
> "Überschreiben" also Ändern eines Zuges bedient werden.
Ich denke, es sollte eine allgemeingültigere Möglichkeit geschaffen
werden, auch sich potentiell überschreibende Planungszustände abzubilden
- oder weiterhin die Finger davon gelassen werden. Ich bin kein Freund
halber Sachen.
> Als Voraussetzung dafür wäre es hilfreich, die üblichen Planungsabläufe
> mit Zwischenzuständen aufzuzeigen, jedoch nur mit dem
> railML-Export-Gedanken im Hintergrund. Zustände, die nur in einem
> Planungstool bleiben und nicht exportiert werden, sollten nicht beachtet
> werden.
Auch hier stimme ich Dir voll zu: Nicht alles mögliche unterstützen,
sondern nur das Gebrauchte. Ich sehe in den Planungsphasen
(Jahresfahrplan, Gelegenheitsverkehr usw.) prinzipiell das gleiche wie
in sich kurzfristig gegenseitig überschreibenden Phasen (Stichwort Ein-
und Auslegen von Zügen).
Ich würde all das mit "Änderungsmanagement" im weitesten Sinne
überschreiben und mich zum diesem Thema eher zurückhalten, da es
vordringlich von anderer Seite eingebracht wurde.
Danke und viele Grüße,
Dirk.
[1] http://www.irfp.de/download/railml_beispiel_mzl.pdf
|
|
|
|
Current Time: Fri May 03 07:47:35 CEST 2024
|
Members
Search
Help
Login
Home
