| Re: These: Das Aufteilen eines großen RailML-Netzes auf mehrere kleinere RailML-Netze darf zu keinem Verlust an Informationen führen. [message #722 is a reply to message #719] |
Wed, 13 April 2011 11:30  |
Joachim Rubröder railML
Messages: 0
Registered: November 2019
|
|
|
|
Hallo Dirk und liebe Mitlesenden,
natürlich gibt es aus dem Ausland "einbrechende" Züge, die will ich auch
gar nicht abschaffen, auch wenn sie an einem Grossteil der Verspätungen
schuld sind. Was mich an den Werten begin/end stört ist die fachliche
Mehrfachnutzung des Feldes ocpType beim trainPart. Gerade wenn der
"Einbruch" als "begin" deklariert wird, kann man nicht gleichzeitig den
Grenzübertritt mit/ohne Halt über stop/pass unterscheiden.
- begin/end im Sinne von Start/Ende des gesamten Zuglaufs gehört
thematisch zum train nicht zum trainPart
- begin/end bezogen auf den trainPart sind unnötig da man sie an der
Reihenfolge erkennt
- begin/end als Kennzeichnung der Grenzbetriebsstelle gehört eher in die
Infrastruktur an den ocp und nicht in den ocpTT
- begin/end als Prüfkriterium, ob hier eine Ankunfts- oder Abfahrtszeit
stehen muss ist eine fachliche Schemaprüfung und gehört daher auch nicht
ins Schema selbst.
Die übertragene Information ist sicher nicht "veraltet", aber die
Ãbertragungsmethode meiner Ansicht nach schon. Ich würde daher dafür
plädieren die beiden Werte weiterhin als Deprecated zu kennzeichnen und
zu diskutieren welche Information sich dahinter verbergen soll und in
welchem Feld man sie künftig überträgt.
Hast Du einen Vorschlag für ein derartiges neues Feld?
Viele Grüsse,
Joachim
--------
Dear Dirk and all,
I apply for keeping "begin" and "end" as deprecated and to discuss the
inteded meaning of theses values. This will lead us to a new field with
dedicated purpose.
Any suggestions?
With best regards,
Joachm
--
----== posted via PHP Headliner ==----
|
|
|
|
Members
Search
Help
Login
Home
