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 #946 is a reply to message #935] |
Mon, 16 September 2013 17:09   |
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 ==----
|
|
|
|
Current Time: Mon Apr 29 23:09:14 CEST 2024
|
Members
Search
Help
Login
Home
