| separation of <ocpTT> from <trainPart> - meeting 11.11. [message #952] |
Tue, 19 November 2013 13:07  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
- English summary below -
Hallo allerseits,
Beim Treffen am 11.11. wurde ebenfalls die Frage diskutiert, inwieweit in
Zukunft in RailML die Betriebsstellen- und Zeitenabfolge vom <trainPart>
getrennt werden sollten. Hintergrund ist insbesondere die erhebliche
Redundanz, die sich wiederholende Zeitenabfolge _gekuppelter_ <trainParts>
derzeit bedeutet.
Konkret würde <ocpsTT> mit allen Unter-Elementen vom <trainPart> in eine
neue Struktur umziehen. Als Arbeitstitel für die neue Struktur wurde
<itinerary> vorgeschlagen.
Beim <trainPart> verblieben die elementaren Alleinstellungsmerkmale wie
<formationTT> mit /load/, /length/, <passengerUsage> usw. und
<operatingPeriodRef>.
<itinerary> bzw. <itineraries> würde eine neue Struktur außerhalb der
Hierarchie <train> <trainPartSequence> <trainPart> werden, d. h. ein
Unter-Element von <timetable>. Auf ein <itinerary>-Element würde von einem
<trainPartSequence> aus verwiesen (/itineraryRef/). Der Verweis soll
außerdem einen optionalen Zeitversatz beinhalten können (<itineraryRef
Ref=... timeShift=... />).
Dieser Vorschlag (von Andreas Tanner) fand allgemeine Zustimmung.
Es sei ausdrücklich darauf hingewiesen, dass durch diesen Ansatz zunächst
„nur“ die Redundanz in parallel verketteten (gekuppelt verkehrenden)
<trainParts> reduziert wird. In keiner Weise wird hierdurch die
sequentielle Verkettung (Laufwegabschnitte – <trainPartSequences>)
vermieden. Es wurde ebenfalls der Vorschlag geäußert, den gesamten Laufweg
eines Zuges über alle bisherigen <trainPartSequences> hinweg in einer
geschlossenen Betriebsstellen- und Zeitenabfolge abzubilden. Hierzu wurden
keine Lösungsansätze diskutiert.
Ebenfalls wurde die Frage diskutiert, ob und wie „Mustertrassen“ ohne
konkrete Zeitenabfolge abgebildet werden können. Es bestand Einigkeit,
dass dies ohne Änderungen in RailML möglich ist. Es wären die Attribute
/arrival/ und /departure/ zu vermeiden, sehr wohl aber die Elemente
<ocpTT> (mit /ocpRef/) und <sectionTT> <runTimes> (z. B. mit
/minimalTime/) anzugeben.
Beispiel:
<ocpTT ocpRef='ocp_DRAG' ocpType='pass'>
<sectionTT section='DRAG-DAF' >
<runTimes minimalTime='PT145S' operationalReserve='PT9S' />
</sectionTT>
</ocpTT>
<ocpTT ocpRef='ocp_DAF' ocpType='stop'>
<sectionTT section='DAF-DBZ' >
<runTimes minimalTime='PT422S' operationalReserve='PT37S' />
</sectionTT>
<stopDescription>
<stopTimes minimalTime='PT2M0S'/>
</stopDescription>
</ocpTT>
---
English summary
Dear all,
there was a discussion on a possible separation of the route and times
from a <trainPart> into a new structure, possibly <itinerary>. This is
mainly to avoid the current redundancy when two or more <trainParts> run
coupled in one <trainPartSection>.
All <ocpTT> and its sub-elements would move from <trainPart> to new
<itinerary>.
The new structure <itineraries> would be a outside the current hierarchy
<train> <trainPartSection> <trainPart>, so it would be a sub-structure of
<timetable>.
The cross-link to a <itinerary> would come from <trainPartSection>.
The suggestion (by Andreas Tanner) was mainly appreciated.
If you prefer a full English conversation on this topic, please do not
hesitate to tell us.
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
