Home » railML newsgroups » railml.timetable » Explizite Kennzeichnung von gelöschten Zügen und Zugausfällen
| 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   |
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.
>>
>>
>
>
>
|
|
|
|
Current Time: Tue May 07 06:51:26 CEST 2024
|
Members
Search
Help
Login
Home
