| Re: addendum: separation of <ocpTT> from <trainPart> - meeting 11.11. [message #962 is a reply to message #955] |
Fri, 28 March 2014 15:56   |
Joachim Rubröder railML
Messages: 0
Registered: November 2019
|
|
|
|
Hallo Dirk,
Vielen Dank für Deine Zusammenfassung und die hier geordneten Gedanken.
Hier noch ein Kommentar zu Deinem Zusatz.
~~~~~
Short English summary:
The 'trainGroup' element may be used for 'interval' train grouping with
'trainRef' elements. It further helps for grouping of trains with
different 'processStatus' ('planned', 'actual', 'calculated',
'toBeChecked', 'changed', 'imported' und 'other:xxx'). This
'processStatus' attribute is optional for 'trainPart', 'train' and
'trainGroup' elements.
A new attribute 'planningStatus' may be introduced for topics like
âRahmenvertragsperiodeâ, âJahresfahrplanâ,
âGelegenheitsverkehrâ
Which procedures are used by your customers from the very beginning of
timetable construction up to the ad hoc timetable adjustments? Which
intermediate states are transferred to other tools and may require a
clear status definition in railML? This question is regarding the same
train on a certain day.
The same train number is often used for trains, that run on several days
at the same times along the same stations/stops. On some days the train
runs shorter or even longer, but mostly the same stations/stops at the
same times.
How are such trains handled by your customers? Do they get the same
train number? How about the 'additionalTrainNumber'? The concept of
Deutsche Bahn is already integrated with the 'scope' attribute.
The topic "change management" should be discussed separately. The idea is
to export only changed data, not to export the whole train with its
dependencies.
~~~~~
Dirk Bräuer wrote:
> Für das âGruppieren von Zügenâ â also z. B. für ein neues Element
> <trainGroup> â wurden m. E. folgende Instanzen des (bisherigen)
> Elements <train> in Betracht gezogen:
railML hat bereits ein Element 'trainGroup', in dem Züge per 'trainRef'
gruppiert werden können.
http://wiki.railml.org/index.php?title=TT:trainGroup
Möglicherweise könnte die Typisierung ('type' Attribut) erweitert
werden. Derzeit können Taktzüge (type="interval") oder verschiedene
Planungszustände eines Zuges ('processStatus' Attribut) beschrieben
werden.
> 1a) Instanzen des (bisherigen) Elements <train> mit identischem
> Attribut /trainNumber/, die sich hinsichtlich der Verkehrstage
> unterscheiden: Sie haben disjunkte Verkehrstage. Man spricht von
> unterschiedlichen âHauptläufenâ eines Zuges. Sie wären bisher nur an
> dem Attribut /scope/ = âprimaryâ mit unterschiedlicher
> /additionalTrainNumber/ erkennbar.
>
> 1b) Instanzen des (bisherigen) Elements <train> mit identischem
> Attribut /trainNumber/, die unter den Oberbegriff âNebenläufeâ oder
> âErgänzungsfahrpläneâ (DB-Terminologie) fallen. Sie wären bisher nur
> an dem Attribut /scope/ = âsecondary...â erkennbar, ggf. mit
> unterschiedlicher /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.
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. Wie werden diese Szenarien auÃerhalb der
Deutschen Bahn unterschieden?
> 2) Instanzen des (bisherigen) Elements <train> mit identischem
> Attribut /trainNumber/, die unterschiedliche Planungszustände
> repräsentieren und sich daher gegenseitig überschreiben (neuere
> überschreiben ältere).
Verschiedene Planungszustände sind mit dem 'trainGroup' Element und
'processStatus' Attribut abbildbar. Jedoch kann damit kein
"Ãberschreiben" also Ãndern eines Zuges bedient werden. Die möglichen
Werte von 'processStatus' sollten ggf. weiter ergänzt werden. Derzeit
sind 'planned', 'actual', 'calculated', 'toBeChecked', 'changed',
'imported' und 'other:xxx' vorgesehen. Deren gewünschte Verwendung
sollte detaillierter beschrieben werden.
> Unter diese Kategorie fallen ebenfalls Ausfälle und Wieder-Einlegungen
> von Zügen. Im Allgemeinen kann das als âZug-Historieâ bezeichnet
> werden.
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.
> Ebenso fallen hierunter solche Planungszustände wie
> âRahmenvertragsperiodeâ, âJahresfahrplanâ, âGelegenheitsverkehrâ.
Wenn man sich auf einige solcher vertragsmäÃigen Planungszustände
einigen kann, könnten diese im Attribut "processStatus" ergänzt werden.
Vielleicht ist dafür auch ein neues Attribut "planningStatus" sinnvoll.
Es ist sowohl im 'trainPart' als auch in 'train' und 'trainGroup'
verfügbar.
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.
Kind regards,
Joachim
-------------------------------------
Joachim Rubröder
Schema Coordinator: railML.timetable
--
----== posted via PHP Headliner ==----
|
|
|
|
Members
Search
Help
Login
Home
