Home » railML newsgroups » railml.timetable » Explizite Kennzeichnung von gelöschten Zügen und Zugausfällen
Explizite Kennzeichnung von gelöschten Zügen und Zugausfällen [message #925] Tue, 26 February 2013 19:06 Go to next message
christian.wermelinger is currently offline  christian.wermelinger
Messages: 4
Registered: February 2013
Junior Member
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

--
----== posted via PHP Headliner ==----
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 Go to previous messageGo to next message
Andreas Tanner is currently offline  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
>
Re: Explizite Kennzeichnung von gelöschten Zügen und Zugausfällen [message #935 is a reply to message #926] Tue, 12 March 2013 19:23 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Hallo Christian, Andreas und alle Mitlesenden,

mit den „Änderungsinformationen“ oder „Historie“ im Allgemeinen ist das
eine schon mehrfach andiskutierte Sache in RailML.

Bisher war die Philosophie in RailML so, dass eine RailML-Datei nur einen
aktuellen Datenstand absolut und vollständig abbildet: Sie bezieht sich
nicht auf einen früheren Datenstand. Wenn sich Daten geändert haben,
musste man alles mit RailML neu übertragen, auch das, was sich nicht
geändert hat.

Zum Ausfall gekennzeichnete Züge sind nun eine besondere Form von
„Änderungsinformationen“: Die Datei bezieht sich damit zumindest formell
auf einen früheren Stand, nämlich den, zu dem der Zug noch nicht ausfallen
sollte. Das ganze wird deutlich, wenn man bedenkt, dass ein Zug mehrfach
ein- und ausgelegt werden könnte, d. h. erst soll er fahren, dann wieder
nicht, dann doch usw. Und das in unterschiedlicher Abfolge für jeden
möglichen Verkehrstag des Zuges.

Es ist mir klar, dass man konkret den Ausfall eines Zuges nicht so
„bürokratisch“ sehen muss: Einfach wäre es vielleicht, eine
operatingPeriodRef bzw. Verkehrstage-Bitmaske zu ergänzen, die aussagt,
wann der Zug abweichend von der eigentlichen (bisher einzigen)
operatingPeriodRef _nicht_ verkehrt - also an denen er irgendwann in der
Vergangenheit mal verkehren sollte und nach aktuellem Erkenntnisstand mal
jemand entschieden hat, dass er nicht verkehren soll.

Ich möchte nur darauf hinweisen, dass wir damit ein kleines Fässchen
aufmachen, bei dem sich vielleicht herausstellt, dass es so schnell keinen
Boden hat: Wenn wir einmal mit „Änderungsinformationen“ anfangen, werden
wir sie vmtl. so schnell nicht wieder los. Der Anwender kennt ja den
Werdegang von RailML nicht und akzeptiert auch nicht unbedingt einen
willkürlichen Zwischenstand. Es könnte daher sinnvoll sein „wenn schon,
dann richtig“, also quasi bei _jedem_ Element in RailML (per Vererbung)
solche Informationen wie „Datensatz/Element gültig von ... bis ...“
einzuführen. Dann kann man „genau genommen genau“ erkennen, ob ein Element
- auch Zug, Zugteil usw. - noch „gültig“ ist und von wann bis wann das
jemand mal so geplant hatte.

Auch diese vermeintliche „Ideallösung“ wäre u. U. noch nicht der Boden des
Fasses, wenn man bedenkt, dass im Falle von Zügen eventuell noch wichtig
sein könnte, auf welcher Planungsebene er ein- und ausgelegt wurde. War er
schon beim Infrastrukturbetreiber bestellt und muss daher abbestellt
werden? Oder war es „nur so eine Idee“, die zu keinem Zeitpunkt
offiziellen Status erlangte? Und das nach Verkehrstagen unterschieden: Zug
ist im Juli bis September bestellt worden, im Juli soll er immer noch
fahren, im August ist er bereits abbestellt, im September ist er noch
abzubestellen...

- - -
Letztendlich kann man es auch anders aufrollen: Bei Datenübertragung in
einem komplexen Prozess muss üblicher Weise irgendwo ein Änderungsabgleich
stattfinden. Dies kann beim Export _vor_ RailML stattfinden - RailML
überträgt dann Änderungsinformationen und bezieht sich auf einen früheren
Export - oder es kann beim Import _nach_ RailML stattfinden, d. h. beim
„mergen“ (=soll ein Anglizismus sein - bitte englisch „auslesen“) der
RailML-Daten mit den aktuell im System vorhandenen Daten.

Es scheint, dass beide Wege gleichwertig sind. Die bisherige
RailML-Philosophie war „keine Änderungsinformationen“, d. h. „mergen“ beim
Einlesen. Das Einlesen ist ohnehin ein komplexerer Prozess als das
Rausschreiben, wegen der zusätzlich notwendigen Datenintegritätsprüfungen.

Zu bedenken ist immer auch, dass u. U. verschiedene Datenquellen in
Betracht kommen: Ein „mergen“ beim Einlesen kann auch Daten
zusammenführen, die aus verschiedenen Quellen kommen. Ein Änderungsexport
hingegen würde sich immer auf die zuvor aus dem eigenen System
exportierten Daten beziehen, d. h. hier ist im Gesamtprozess kein
Informationsgewinn möglich.

Wir (iRFP) haben uns dieser Lesart angepasst, d. h. wir können beim
Einlesen „mergen“, können aber derzeit keinen Änderungsexport anbieten.
Wir würden aus Aufwandsgründen in absehbarer Zeit nicht beides anbieten,
zumal wie gesagt derzeit kein Mehrwert erkennbar ist. Insofern würde ich
das von unserer Seite erst einmal zurückhaltend betrachten wollen.

Ich verstehe, dass die Situation vielleicht anders aussieht, wenn zwei
nicht gleichwertige Systeme Daten austauschen - d. h. wenn beim Einlesen
aus irgendwelchen Gründen weniger Prozesskapazität vorliegt als beim
Rausschreiben. Das wäre dann aber vielleicht ein Fall, der nicht mehr im
allgemeingültigen RailML auftauchen muss - eher ein individueller Aufsatz
oder eine bilaterale Lösung.

Viele Grüße,
Dirk.
Re: Explizite Kennzeichnung von gelöschten Zügen und Zugausfällen [message #946 is a reply to message #935] Mon, 16 September 2013 17:09 Go to previous messageGo to next message
christian.wermelinger is currently offline  christian.wermelinger
Messages: 4
Registered: February 2013
Junior Member
Hallo zusammen

Erstmal ein Dankeschön an Andreas und Dirk für den wertvollen Input.

Andreas Tanner wrote:
> Ich denke, man sollte trennen, ob man
> a) Informationen aus der dispositiven Welt, oder
> b) Änderungen eines Planes

Andreas' Vorschlag, Informationen aus der dispositiven Welt und
Planänderungen konsequent zu trennen, erachte ich als sinnvoll.
Grundsätzlich muss ich jedoch Dirk beipflichten.

> Bisher war die Philosophie in RailML so, dass eine RailML-Datei nur einen
> aktuellen Datenstand absolut und vollständig abbildet: Sie bezieht sich
> nicht auf einen früheren Datenstand.

Meines Erachtens sollte an dieser Philosophie festgehalten werden.

> Ich möchte nur darauf hinweisen, dass wir damit ein kleines Fässchen
> aufmachen, bei dem sich vielleicht herausstellt, dass es so schnell keinen
> Boden hat: Wenn wir einmal mit „Änderungsinformationen“ anfangen,
werden
> wir sie vmtl. so schnell nicht wieder los.

Ich denke dass wir mit der von mir vorgeschlagenen Änderung nicht nur ein
kleines Fässchen, sondern ein ziemlich grosses Fass aufmachen würden!
Dirk ist ja bereits auf mögliche Konsequenzen eingegangen.

> Es könnte daher sinnvoll sein „wenn schon,
> dann richtig“, also quasi bei _jedem_ Element in RailML (per Vererbung)
> solche Informationen wie „Datensatz/Element gültig von ... bis ...“
> einzuführen.

Von einer halbfertigen, nicht zu Ende gedachten Lösung profitiert
schlussendlich niemand. Andererseits führt der Einsatz zeitabhängiger
Attribute zu einer stark erhöhten Komplexität und bläht die Daten
weiter auf. Dies bringt insbesondere dann keinen Mehrwert, wenn dieser
Komplexitätsgrad gar nicht gefordert ist (z.B. weil das Zielsystem gar
keine Historie bzw. zeitabhängigen Attribute kennt oder benötigt).

> Letztendlich kann man es auch anders aufrollen: Bei Datenübertragung in
> einem komplexen Prozess muss üblicher Weise irgendwo ein Änderungsabgleich

> stattfinden. Dies kann beim Export _vor_ RailML stattfinden - RailML
> überträgt dann Änderungsinformationen und bezieht sich auf einen
früheren
> Export - oder es kann beim Import _nach_ RailML stattfinden, d. h. beim
> „mergen“ (=soll ein Anglizismus sein - bitte englisch „auslesen“)
der
> RailML-Daten mit den aktuell im System vorhandenen Daten.
>
> Es scheint, dass beide Wege gleichwertig sind. Die bisherige
> RailML-Philosophie war „keine Änderungsinformationen“, d. h.
„mergen“ beim
> Einlesen.

Wie bereits erwähnt, erachte ich es als sinvoll weiterhin an der
aktuellen RailML-Philosophie festzuhalten und Änderungen beim Import bzw.
„mergen“ zu erfassen.

Wir handeln dies nun auch so. Beim Import von Fahrplänen wird der bereits
im System vorhandene Datenbestand mit den zu importierenden RailML-Daten
abgeglichen. Für den Datenabgleich bieten wir folgende Import-Optionen an:
1. neue Züge importieren: ja/nein
2. bestehende Züge aktualisieren: ja/nein
3. nicht mehr vorhanden Züge löschen: ja/nein

Damit sind für uns zumindest die wichtigsten Use-Cases im Zusammenhang
mit Planänderungen abgedeckt.

Viele Grüsse,
Christian



Dirk Bräuer wrote:
>
> Hallo Christian, Andreas und alle Mitlesenden,
>
> mit den „Änderungsinformationen“ oder „Historie“ im Allgemeinen ist
das
> eine schon mehrfach andiskutierte Sache in RailML.
>
> Bisher war die Philosophie in RailML so, dass eine RailML-Datei nur einen
> aktuellen Datenstand absolut und vollständig abbildet: Sie bezieht sich
> nicht auf einen früheren Datenstand. Wenn sich Daten geändert haben,
> musste man alles mit RailML neu übertragen, auch das, was sich nicht
> geändert hat.
>
> Zum Ausfall gekennzeichnete Züge sind nun eine besondere Form von
> „Änderungsinformationen“: Die Datei bezieht sich damit zumindest
formell
> auf einen früheren Stand, nämlich den, zu dem der Zug noch nicht ausfallen

> sollte. Das ganze wird deutlich, wenn man bedenkt, dass ein Zug mehrfach
> ein- und ausgelegt werden könnte, d. h. erst soll er fahren, dann wieder
> nicht, dann doch usw. Und das in unterschiedlicher Abfolge für jeden
> möglichen Verkehrstag des Zuges.
>
> Es ist mir klar, dass man konkret den Ausfall eines Zuges nicht so
> „bürokratisch“ sehen muss: Einfach wäre es vielleicht, eine
> operatingPeriodRef bzw. Verkehrstage-Bitmaske zu ergänzen, die aussagt,
> wann der Zug abweichend von der eigentlichen (bisher einzigen)
> operatingPeriodRef _nicht_ verkehrt - also an denen er irgendwann in der
> Vergangenheit mal verkehren sollte und nach aktuellem Erkenntnisstand mal
> jemand entschieden hat, dass er nicht verkehren soll.
>
> Ich möchte nur darauf hinweisen, dass wir damit ein kleines Fässchen
> aufmachen, bei dem sich vielleicht herausstellt, dass es so schnell keinen
> Boden hat: Wenn wir einmal mit „Änderungsinformationen“ anfangen,
werden
> wir sie vmtl. so schnell nicht wieder los. Der Anwender kennt ja den
> Werdegang von RailML nicht und akzeptiert auch nicht unbedingt einen
> willkürlichen Zwischenstand. Es könnte daher sinnvoll sein „wenn schon,
> dann richtig“, also quasi bei _jedem_ Element in RailML (per Vererbung)
> solche Informationen wie „Datensatz/Element gültig von ... bis ...“
> einzuführen. Dann kann man „genau genommen genau“ erkennen, ob ein
Element
> - auch Zug, Zugteil usw. - noch „gültig“ ist und von wann bis wann das
> jemand mal so geplant hatte.
>
> Auch diese vermeintliche „Ideallösung“ wäre u. U. noch nicht der Boden
des
> Fasses, wenn man bedenkt, dass im Falle von Zügen eventuell noch wichtig
> sein könnte, auf welcher Planungsebene er ein- und ausgelegt wurde. War er
> schon beim Infrastrukturbetreiber bestellt und muss daher abbestellt
> werden? Oder war es „nur so eine Idee“, die zu keinem Zeitpunkt
> offiziellen Status erlangte? Und das nach Verkehrstagen unterschieden: Zug
> ist im Juli bis September bestellt worden, im Juli soll er immer noch
> fahren, im August ist er bereits abbestellt, im September ist er noch
> abzubestellen...
>
> - - -
> Letztendlich kann man es auch anders aufrollen: Bei Datenübertragung in
> einem komplexen Prozess muss üblicher Weise irgendwo ein Änderungsabgleich

> stattfinden. Dies kann beim Export _vor_ RailML stattfinden - RailML
> überträgt dann Änderungsinformationen und bezieht sich auf einen
früheren
> Export - oder es kann beim Import _nach_ RailML stattfinden, d. h. beim
> „mergen“ (=soll ein Anglizismus sein - bitte englisch „auslesen“)
der
> RailML-Daten mit den aktuell im System vorhandenen Daten.
>
> Es scheint, dass beide Wege gleichwertig sind. Die bisherige
> RailML-Philosophie war „keine Änderungsinformationen“, d. h.
„mergen“ beim
> Einlesen. Das Einlesen ist ohnehin ein komplexerer Prozess als das
> Rausschreiben, wegen der zusätzlich notwendigen Datenintegritätsprüfungen.
>
> Zu bedenken ist immer auch, dass u. U. verschiedene Datenquellen in
> Betracht kommen: Ein „mergen“ beim Einlesen kann auch Daten
> zusammenführen, die aus verschiedenen Quellen kommen. Ein Änderungsexport
> hingegen würde sich immer auf die zuvor aus dem eigenen System
> exportierten Daten beziehen, d. h. hier ist im Gesamtprozess kein
> Informationsgewinn möglich.
>
> Wir (iRFP) haben uns dieser Lesart angepasst, d. h. wir können beim
> Einlesen „mergen“, können aber derzeit keinen Änderungsexport
anbieten.
> Wir würden aus Aufwandsgründen in absehbarer Zeit nicht beides anbieten,
> zumal wie gesagt derzeit kein Mehrwert erkennbar ist. Insofern würde ich
> das von unserer Seite erst einmal zurückhaltend betrachten wollen.
>
> Ich verstehe, dass die Situation vielleicht anders aussieht, wenn zwei
> nicht gleichwertige Systeme Daten austauschen - d. h. wenn beim Einlesen
> aus irgendwelchen Gründen weniger Prozesskapazität vorliegt als beim
> Rausschreiben. Das wäre dann aber vielleicht ein Fall, der nicht mehr im
> allgemeingültigen RailML auftauchen muss - eher ein individueller Aufsatz
> oder eine bilaterale Lösung.
>
> Viele Grüße,
> Dirk.
>
>



--
----== posted via PHP Headliner ==----
Re: Explizite Kennzeichnung von gelöschten Zügen und Zugausfällen [message #947 is a reply to message #946] Tue, 24 September 2013 11:00 Go to previous messageGo to next message
Andreas Tanner is currently offline  Andreas Tanner
Messages: 52
Registered: March 2012
Member
Hallo allerseits,

auf der vergangenen railML-Konferenz habe ich einen Vortrag zum Thema
gehalten:
http://documents.railml.org/events/slides/2013-09-18_ivu_tan ner-differentialdataexchange.pdf.

Ich würde gern mit einer Gruppe von Interessierten eine
Standarderweiterung erarbeiten, die die angefragten Anwendungsfälle abdeckt.

Gruß Andreas

Am 16.09.2013 17:09, schrieb Christian Wermelinger:
> Hallo zusammen
>
> Erstmal ein Dankeschön an Andreas und Dirk für den wertvollen Input.
>
> Andreas Tanner wrote:
>> Ich denke, man sollte trennen, ob man
>> a) Informationen aus der dispositiven Welt, oder
>> b) Änderungen eines Planes
>
> Andreas' Vorschlag, Informationen aus der dispositiven Welt und
> Planänderungen konsequent zu trennen, erachte ich als sinnvoll.
> Grundsätzlich muss ich jedoch Dirk beipflichten.
>
>> Bisher war die Philosophie in RailML so, dass eine RailML-Datei nur einen
>> aktuellen Datenstand absolut und vollständig abbildet: Sie bezieht sich
>> nicht auf einen früheren Datenstand.
>
> Meines Erachtens sollte an dieser Philosophie festgehalten werden.
>
>> Ich möchte nur darauf hinweisen, dass wir damit ein kleines Fässchen
>> aufmachen, bei dem sich vielleicht herausstellt, dass es so schnell keinen
>> Boden hat: Wenn wir einmal mit „Änderungsinformationen“ anfangen,
> werden
>> wir sie vmtl. so schnell nicht wieder los.
>
> Ich denke dass wir mit der von mir vorgeschlagenen Änderung nicht nur ein
> kleines Fässchen, sondern ein ziemlich grosses Fass aufmachen würden!
> Dirk ist ja bereits auf mögliche Konsequenzen eingegangen.
>
>> Es könnte daher sinnvoll sein „wenn schon,
>> dann richtig“, also quasi bei _jedem_ Element in RailML (per Vererbung)
>> solche Informationen wie „Datensatz/Element gültig von ... bis ...“
>> einzuführen.
>
> Von einer halbfertigen, nicht zu Ende gedachten Lösung profitiert
> schlussendlich niemand. Andererseits führt der Einsatz zeitabhängiger
> Attribute zu einer stark erhöhten Komplexität und bläht die Daten
> weiter auf. Dies bringt insbesondere dann keinen Mehrwert, wenn dieser
> Komplexitätsgrad gar nicht gefordert ist (z.B. weil das Zielsystem gar
> keine Historie bzw. zeitabhängigen Attribute kennt oder benötigt).
>
>> Letztendlich kann man es auch anders aufrollen: Bei Datenübertragung in
>> einem komplexen Prozess muss üblicher Weise irgendwo ein Änderungsabgleich
>
>> stattfinden. Dies kann beim Export _vor_ RailML stattfinden - RailML
>> überträgt dann Änderungsinformationen und bezieht sich auf einen
> früheren
>> Export - oder es kann beim Import _nach_ RailML stattfinden, d. h. beim
>> „mergen“ (=soll ein Anglizismus sein - bitte englisch „auslesen“)
> der
>> RailML-Daten mit den aktuell im System vorhandenen Daten.
>>
>> Es scheint, dass beide Wege gleichwertig sind. Die bisherige
>> RailML-Philosophie war „keine Änderungsinformationen“, d. h.
> „mergen“ beim
>> Einlesen.
>
> Wie bereits erwähnt, erachte ich es als sinvoll weiterhin an der
> aktuellen RailML-Philosophie festzuhalten und Änderungen beim Import bzw.
> „mergen“ zu erfassen.
>
> Wir handeln dies nun auch so. Beim Import von Fahrplänen wird der bereits
> im System vorhandene Datenbestand mit den zu importierenden RailML-Daten
> abgeglichen. Für den Datenabgleich bieten wir folgende Import-Optionen an:
> 1. neue Züge importieren: ja/nein
> 2. bestehende Züge aktualisieren: ja/nein
> 3. nicht mehr vorhanden Züge löschen: ja/nein
>
> Damit sind für uns zumindest die wichtigsten Use-Cases im Zusammenhang
> mit Planänderungen abgedeckt.
>
> Viele Grüsse,
> Christian
>
>
>
> Dirk Bräuer wrote:
>>
>> Hallo Christian, Andreas und alle Mitlesenden,
>>
>> mit den „Änderungsinformationen“ oder „Historie“ im Allgemeinen ist
> das
>> eine schon mehrfach andiskutierte Sache in RailML.
>>
>> Bisher war die Philosophie in RailML so, dass eine RailML-Datei nur einen
>> aktuellen Datenstand absolut und vollständig abbildet: Sie bezieht sich
>> nicht auf einen früheren Datenstand. Wenn sich Daten geändert haben,
>> musste man alles mit RailML neu übertragen, auch das, was sich nicht
>> geändert hat.
>>
>> Zum Ausfall gekennzeichnete Züge sind nun eine besondere Form von
>> „Änderungsinformationen“: Die Datei bezieht sich damit zumindest
> formell
>> auf einen früheren Stand, nämlich den, zu dem der Zug noch nicht ausfallen
>
>> sollte. Das ganze wird deutlich, wenn man bedenkt, dass ein Zug mehrfach
>> ein- und ausgelegt werden könnte, d. h. erst soll er fahren, dann wieder
>> nicht, dann doch usw. Und das in unterschiedlicher Abfolge für jeden
>> möglichen Verkehrstag des Zuges.
>>
>> Es ist mir klar, dass man konkret den Ausfall eines Zuges nicht so
>> „bürokratisch“ sehen muss: Einfach wäre es vielleicht, eine
>> operatingPeriodRef bzw. Verkehrstage-Bitmaske zu ergänzen, die aussagt,
>> wann der Zug abweichend von der eigentlichen (bisher einzigen)
>> operatingPeriodRef _nicht_ verkehrt - also an denen er irgendwann in der
>> Vergangenheit mal verkehren sollte und nach aktuellem Erkenntnisstand mal
>> jemand entschieden hat, dass er nicht verkehren soll.
>>
>> Ich möchte nur darauf hinweisen, dass wir damit ein kleines Fässchen
>> aufmachen, bei dem sich vielleicht herausstellt, dass es so schnell keinen
>> Boden hat: Wenn wir einmal mit „Änderungsinformationen“ anfangen,
> werden
>> wir sie vmtl. so schnell nicht wieder los. Der Anwender kennt ja den
>> Werdegang von RailML nicht und akzeptiert auch nicht unbedingt einen
>> willkürlichen Zwischenstand. Es könnte daher sinnvoll sein „wenn schon,
>> dann richtig“, also quasi bei _jedem_ Element in RailML (per Vererbung)
>> solche Informationen wie „Datensatz/Element gültig von ... bis ...“
>> einzuführen. Dann kann man „genau genommen genau“ erkennen, ob ein
> Element
>> - auch Zug, Zugteil usw. - noch „gültig“ ist und von wann bis wann das
>> jemand mal so geplant hatte.
>>
>> Auch diese vermeintliche „Ideallösung“ wäre u. U. noch nicht der Boden
> des
>> Fasses, wenn man bedenkt, dass im Falle von Zügen eventuell noch wichtig
>> sein könnte, auf welcher Planungsebene er ein- und ausgelegt wurde. War er
>> schon beim Infrastrukturbetreiber bestellt und muss daher abbestellt
>> werden? Oder war es „nur so eine Idee“, die zu keinem Zeitpunkt
>> offiziellen Status erlangte? Und das nach Verkehrstagen unterschieden: Zug
>> ist im Juli bis September bestellt worden, im Juli soll er immer noch
>> fahren, im August ist er bereits abbestellt, im September ist er noch
>> abzubestellen...
>>
>> - - -
>> Letztendlich kann man es auch anders aufrollen: Bei Datenübertragung in
>> einem komplexen Prozess muss üblicher Weise irgendwo ein Änderungsabgleich
>
>> stattfinden. Dies kann beim Export _vor_ RailML stattfinden - RailML
>> überträgt dann Änderungsinformationen und bezieht sich auf einen
> früheren
>> Export - oder es kann beim Import _nach_ RailML stattfinden, d. h. beim
>> „mergen“ (=soll ein Anglizismus sein - bitte englisch „auslesen“)
> der
>> RailML-Daten mit den aktuell im System vorhandenen Daten.
>>
>> Es scheint, dass beide Wege gleichwertig sind. Die bisherige
>> RailML-Philosophie war „keine Änderungsinformationen“, d. h.
> „mergen“ beim
>> Einlesen. Das Einlesen ist ohnehin ein komplexerer Prozess als das
>> Rausschreiben, wegen der zusätzlich notwendigen Datenintegritätsprüfungen.
>>
>> Zu bedenken ist immer auch, dass u. U. verschiedene Datenquellen in
>> Betracht kommen: Ein „mergen“ beim Einlesen kann auch Daten
>> zusammenführen, die aus verschiedenen Quellen kommen. Ein Änderungsexport
>> hingegen würde sich immer auf die zuvor aus dem eigenen System
>> exportierten Daten beziehen, d. h. hier ist im Gesamtprozess kein
>> Informationsgewinn möglich.
>>
>> Wir (iRFP) haben uns dieser Lesart angepasst, d. h. wir können beim
>> Einlesen „mergen“, können aber derzeit keinen Änderungsexport
> anbieten.
>> Wir würden aus Aufwandsgründen in absehbarer Zeit nicht beides anbieten,
>> zumal wie gesagt derzeit kein Mehrwert erkennbar ist. Insofern würde ich
>> das von unserer Seite erst einmal zurückhaltend betrachten wollen.
>>
>> Ich verstehe, dass die Situation vielleicht anders aussieht, wenn zwei
>> nicht gleichwertige Systeme Daten austauschen - d. h. wenn beim Einlesen
>> aus irgendwelchen Gründen weniger Prozesskapazität vorliegt als beim
>> Rausschreiben. Das wäre dann aber vielleicht ein Fall, der nicht mehr im
>> allgemeingültigen RailML auftauchen muss - eher ein individueller Aufsatz
>> oder eine bilaterale Lösung.
>>
>> Viele Grüße,
>> Dirk.
>>
>>
>
>
>
Explizite Kennzeichnung von gelöschten Zügen und Zugausfällen, Tickets #188 und #247 [message #1298 is a reply to message #946] Fri, 18 September 2015 10:14 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Hallo allerseits,

Ticket #247 wurde als für railML 2.3 geschlossen und das damit
zusammenhängende Problem damit als gelöst deklariert.

Wir haben in den letzten Jahren schon oft über die Problematik
"Änderungsübertragung vs. Gesamtübertragung" und damit im Zusammenhang
stehende Aspekte gesprochen. Bisher war die dabei unter’m Strich
herauskommende Lesart immer "erfordert weitgehendere Lösungen, die erst
mit 3.x und Refactoring möglich werden", u. a. nachzulesen beim
Diskussions-Thread 26.02.2013..24.09.2013 [1].

Insofern sollte Einigkeit darüber bestehen, dass die Schließung von
Ticket #247 bei Weitem keine Lösung ist, sondern eher ein Provisorium,
über das man geteilter Meinung sein kann. Möglicherweise wäre hier eine
Verwendung von any-Attributen die bessere Wahl gewesen, um auszudrücken,
dass ein allgemeingültiger railML-Konsens noch nicht erreicht ist.

Ich möchte anregen, beim Ticket #247 einen Querverweis auf Ticket #188
(gleiches Thema bei railML 3.0) anzubringen und zu vermerken, dass es
sich um eine provisorische, nicht allgemeingültige Lösung handelt.

Viele Grüße,
Dirk Bräuer.

[1] news://news.railml.org:119/l176vg$tbv$1(at)sifaivifhgde

P.S.:
Gleichzeitig sollte für das provisorische "Löschkennzeichen" eines
<trainPart>s von railML 2.3 im Wiki durch den Einführer oder Koordinator
festgehalten werden,
a) ob ein <trainPart> mit "Löschkennzeichen" immer an allen seinen
Verkehrstagen auf seinem gesamten Laufweg ausfällt und er demzufolge
keine /operatingPerodRef/ und keine <ocpTT>s haben darf bzw. dass diese
zu ignorieren sind oder
b) ob ein <trainPart> mit "Löschkennzeichen" nur an dem konkret
genannten Laufweg und Verkehrstagen ausfällt, d. h. eventuell im
Zielsystem existierende weitere Verkehrstage / Laufwegteile unverändert
erhalten bleiben.

Da im Ticket #247 schon erwähnt, dass die Bezugsbasis in railML derzeit
nicht definiert ist, sollte es auf (a) hinauslaufen (was hiermit als
mein konkreter Vorschlag gelten kann).

Wenn wir das undefiniert belassen, werden wir ein großes Problem auf die
Praxis abwälzen mit der Folge, dass die meisten Anwendungen das
"Löschkennzeichen" ablehnen oder ignorieren. Dieses Dilemma verdeutlicht
schon etwas, wo das Unbefriedigende an der 2.3er Lösung liegt.
Re: Explizite Kennzeichnung von gelöschten Zügen und Zugausfällen, Tickets #188 und #247 [message #1303 is a reply to message #1298] Tue, 29 September 2015 13:34 Go to previous message
Philip Wobst is currently offline  Philip Wobst
Messages: 47
Registered: November 2013
Location: Hanover, Germany
Member
Hallo Dirk,

danke für die Rückmeldung - dein Einwand ist durchaus gerechtfertigt.
Das Ticket #247 entspricht nicht der tatsächlich durchgeführten Änderung
in 2.3.
Ich möchte vorschlagen, dass ich dies entsprechend aktualisiere und dann
hier im Forum um Rückmeldung bitte.

EN: There has been a discussion regarding the TRAC ticket #247 changes
for railML 2.3. The ticket will be updated to better show the actual
changes (also in English) so that feedback can be given in the forum.

Best regards /Gruß aus Hannover,

Philip Wobst

Am 18.09.2015 um 10:14 schrieb Dirk Bräuer:
> Hallo allerseits,
>
> Ticket #247 wurde als für railML 2.3 geschlossen und das damit
> zusammenhängende Problem damit als gelöst deklariert.
>
> Wir haben in den letzten Jahren schon oft über die Problematik
> "Änderungsübertragung vs. Gesamtübertragung" und damit im Zusammenhang
> stehende Aspekte gesprochen. Bisher war die dabei unter’m Strich
> herauskommende Lesart immer "erfordert weitgehendere Lösungen, die erst
> mit 3.x und Refactoring möglich werden", u. a. nachzulesen beim
> Diskussions-Thread 26.02.2013..24.09.2013 [1].
>
> Insofern sollte Einigkeit darüber bestehen, dass die Schließung von
> Ticket #247 bei Weitem keine Lösung ist, sondern eher ein Provisorium,
> über das man geteilter Meinung sein kann. Möglicherweise wäre hier eine
> Verwendung von any-Attributen die bessere Wahl gewesen, um auszudrücken,
> dass ein allgemeingültiger railML-Konsens noch nicht erreicht ist.
>
> Ich möchte anregen, beim Ticket #247 einen Querverweis auf Ticket #188
> (gleiches Thema bei railML 3.0) anzubringen und zu vermerken, dass es
> sich um eine provisorische, nicht allgemeingültige Lösung handelt.
>
> Viele Grüße,
> Dirk Bräuer.
>
> [1] news://news.railml.org:119/l176vg$tbv$1(at)sifaivifhgde
>
> P.S.:
> Gleichzeitig sollte für das provisorische "Löschkennzeichen" eines
> <trainPart>s von railML 2.3 im Wiki durch den Einführer oder Koordinator
> festgehalten werden,
> a) ob ein <trainPart> mit "Löschkennzeichen" immer an allen seinen
> Verkehrstagen auf seinem gesamten Laufweg ausfällt und er demzufolge
> keine /operatingPerodRef/ und keine <ocpTT>s haben darf bzw. dass diese
> zu ignorieren sind oder
> b) ob ein <trainPart> mit "Löschkennzeichen" nur an dem konkret
> genannten Laufweg und Verkehrstagen ausfällt, d. h. eventuell im
> Zielsystem existierende weitere Verkehrstage / Laufwegteile unverändert
> erhalten bleiben.
>
> Da im Ticket #247 schon erwähnt, dass die Bezugsbasis in railML derzeit
> nicht definiert ist, sollte es auf (a) hinauslaufen (was hiermit als
> mein konkreter Vorschlag gelten kann).
>
> Wenn wir das undefiniert belassen, werden wir ein großes Problem auf die
> Praxis abwälzen mit der Folge, dass die meisten Anwendungen das
> "Löschkennzeichen" ablehnen oder ignorieren. Dieses Dilemma verdeutlicht
> schon etwas, wo das Unbefriedigende an der 2.3er Lösung liegt.
Previous Topic: Missing 'any' attributes/elements
Next Topic: Protokoll Treffen 2015-0619 Berlin
Goto Forum:
  


Current Time: Thu Mar 28 20:36:07 CET 2024