| Re: Explizite Kennzeichnung von gelöschten Zügen und Zugausfällen [message #926 is a reply to message #925] |
Wed, 27 February 2013 11:18   |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
Hallo Christian,
interessanter Punkt. Da hat railML noch Lücken.
Ich denke, man sollte trennen, ob man
a) Informationen aus der dispositiven Welt, oder
b) Änderungen eines Planes
übertragen will
"Zugausfall" würde ich a) zuordnen und hier eine Lösung anstreben, die
auch Verspätungsinformationen, Ersatzzüge usw. umfasst, vgl. auch die
Diskussion news://news.railml.org:119/k4uoii$m50$1(at)sifaivifhgde.
b) wäre für uns ebenfalls interessant: das importierende System liest
Fahrplaninformationen und erstellt eine darauf basierende Dienstplanung.
Jetzt ändert sich der Fahrplan (Fahrten gelöscht, ergänzt, verschoben,
Laufweg geändert, Formation geändert...) und entsprechend müssen die
Dienstpläne angepasst werden, wobei man so wenig wie möglich neu machen
will.
Gruß Andreas
Am 26.02.2013 19:06, schrieb Christian Wermelinger:
> Hallo zusammen
>
> Aktuell müssen beim Import von Zügen Annahmen getroffen werden. Hierzu
> ein Beispiel:
> 1. Initialer Import von Zug 1234 über RailML-Schnittstelle. Resultat: Zug
> 1234 ist im Zielsystem
> vorhanden.
> 2. Anschliessend wird ein weiterer RailML-Import gestartet (Zug 1234 ist
> nicht mehr in der RailML-
> Importdatei einhalten).
> Was nun? Soll der Zug gelöscht oder als annulliert gekennzeichnet werden?
> RailML liefert
> diesbezüglich keine expliziten Informationen.
>
> Soweit mir bekannt ist, erlaubt es RailML nicht, ungültige Züge (welche
> z.B. zu einem früheren
> Zeitpunkt irrtümlicherweise ins Zielsystem importiert wurden) explizit
> als 'inaktiv' (bzw. gelöscht)
> zu kennzeichnen. Weiter vermisse ich die Möglichkeit, Teile eines Zuges
> (trainParts) explizit als
> '(Teil-)Ausfall' zu kennzeichnen ohne das dafür zwingend eine neue
> Verkehrsperiode angelegt
> werden muss. In beiden Fällen wäre es zudem wünschenswert, bei Bedarf
> eine Begründung
> erfassen zu können.
>
> Folgend versuche ich einen möglichen Lösungsansatz zu skizzieren.
>
> <railml>
> <train>
> <!-- Use-Case: Annulation technischer Art (optional) -->
> <disabled timestamp="2013-02-25T10:07:52,553">
> <!-- optional -->
> <reason code="INVALID_EXPORT" label="Ungültiger Export"
> remarks="Ungültiger
> Zug. Wurde am 1.2.2013 irrtümlicherwise exportiert.">
> </disabled>
> </train>
>
> <trainPart>
> <operatingPeriodRef ref="op_123"></operatingPeriodRef>
> <!-- Use-Case: Fachlich getriebener (Teil-)ausfall eines Zuges
> (optional) -->
> <cancellation timestamp="2013-02-25T10:07:52,553">
> <!-- schränkt die in 'trainPart\operatingPeriodRef' referenzierte
> Verkehrsperiode
> weiter ein (Bsp. Teilausfall) -->
> <restriction>
> <!--xsd:choice: restrictionOperatingPeriod ODER restrictionTimeSpan-->
> <restrictionOperatingPeriod ref="op_456"></restrictionOperatingPeriod>
> <restrictionTimeSpan endDate="2013-06-01" startDate="2012-07-15"/>
> </restriction>
> <!-- optional -->
> <reason code="CONSTRUCTION_AREA" label="Baustelle" remarks="Baustelle
> auf
> Strecke A-Z im Zeitraum vom 1.6.2013 bis 15.7.2013">
> </cancellation>
> </trainPart>
> </railml>
>
> 'disabled' und 'cancellation' wurden bewusst als Elemente modelliert, da
> damit Erweiterbarkeit
> gegeben ist. Dies ist z.B. beim heute verwendeten Attribut
> 'trainPart@processStatus' nicht der Fall
> (abgesehen davon, dass die Aufzählung meines Erachtens in sich nicht
> konsistent ist).
>
> Wie erwähnt handelt es sich hierbei nur um ein Vorschlag.
> Verbesserungsvorschläge und
> Ergänzungen sind sehr willkommen.
>
> Viele Grüsse,
> Chris
>
|
|
|
|
Members
Search
Help
Login
Home
