These: Das Aufteilen eines großen RailML-Netzes auf mehrere kleinere RailML-Netze darf zu keinem Verlust an Informationen führen. [message #719] |
Mon, 04 April 2011 16:42 |
Dirk Bräuer
Messages: 313 Registered: August 2008
|
Senior Member |
|
|
Hallo Joachim und liebe Mitlesenden,
ich bin etwas verwundert über Deine Änderung, die Ausprägungen "begin" und
"end" aus trainPart -> ocpTT -> ocpType für veraltet zu erklären.
Unter'm Strich sollte es möglich sein, die Ankunftszeiten von
Zügen/Zugteilen aus dem "Ausland" (im RailML-Sinne: von außerhalb des
Geltungsbereichs der RailML-Datei) sowie die Abfahrtszeiten in das
dementsprechende "Ausland" anzugeben.
Wenn ein Zug durchfahrend in das Netz einbricht (kein Halt an der
Grenzbetriebsstelle), dann habe ich zwangsläufig auch die Ankunftszeit
(=Durchfahrtszeit) aus dem Ausland. Dann sollte man konsequenter Weise
auch zulassen, dass man bei an der Grenzbetriebsstelle haltenden Zügen
eine Ankunftszeit angeben kann (sinngemäß Abfahrtszeit beim "Ausbrechen").
Zudem hat das Ganze oft auch statistische Relevanz: Sofern man die Summe
der Aufenthaltszeiten berechnen muss (zu welchem Zweck auch immer - kommt
bei uns oft vor), dann müssen die Aufenthalte an den Grenzbetriebsstellen
auch in das eine oder andere Netz hineingerechnet werden - sie dürfen
nicht "unter den Tisch fallen". Die Regel ist dann z. B. so, dass
Aufenthalte am Ende des Zuglaufs zum betrachteten Netz dazugehören, die am
Anfang nicht (=gehören zum vorherigen Netz).
Beispiel: Wenn ein Zug Prag - Linz für 10 min in Summerau
(österreichisch-tschechische Grenze) steht, dann müssen diese 10 min
irgendwo erfasst werden. Es darf nicht sein, dass sie weder in einer
tschechischen noch in einer österreichischen RailML-Datei enthalten wären.
Oder, allgemeingültiger ausgedrückt: Das Aufteilen eines großen
RailML-Netzes auf mehrere kleinere RailML-Netze darf zu keinem Verlust an
Informationen führen.
--
Nun könnte man das durchaus allein aus dem Vorhandensein von Ankunfts-
und/oder Abfahrtszeit ableiten, d. h. alle solche Halte haben type=stop,
aber bei manchen fehlt Ankunfts- und/oder Abfahrtszeit (bei den ehemaligen
begin/end). Ich halte das nicht für glücklich, da es uneindeutig werden
kann bei Definition von "Trassenzeitspannen" (Zeitbereich, in dem ein Zug
kommen kann). Vielmehr sollte doch eigentlich erzwungen werden, dass bei
"stop" immer beide Zeiten angegeben sein müssen, bei "begin" und "end"
jedoch nicht.
Können wir insofern nochmal verhandeln darüber, ob die beiden wirklich
"veraltet" sein müssen? Ich fühle mich auch so schon ziemlich alt... ;-)
Dirk.
---
Dear Joachim and all "listeners",
I am a little bit confused about Joachims change to declare the patterns
"begin" and "end" of trainPart -> ocpTT -> ocpType as deprecated.
At least it should be possible to specify the arrival time of a
train/trainPart from a "foreign country" (in the meaning of RailML: from
outside the territory of application of the RailML file) and the
corresponding departure time.
If a train enters a network passing through (w/o stop at the border
station) there is necessarily the arrival (=running through) time from
outside. Therefore, it would only be consistent to allow to specify the
arrival time when a train is stopping at the border station.
Also, sometimes (in our world: often) it is necessary to include the
stopping times at every station (e. g. to calculate a sum of stopping
times for, say, statistic reasons). A stopping time at a border station
has to consist to either network; it is not to "fall in-between".
Normally, a stopping time at the end of a trains route is defined to
belong to the current network, that at the beginning of a trains route not
(belonging to the previous network).
Or, more general: Splitting of a larger RailML network (file) into several
smaller RailML networks (files) shall not lead to a loss of any
information.
Well, all this can clearly be done w/o "begin" and "end" - by declaring or
dropping of arrival and/or departure times. But I think this may be a
little bit more confusing (when taking into account that here may be other
reasons to drop an arrival or departure time at an intermediate station
where the train does not begin or end). In my opinion, it is easier and
more clear to have an clear connection between the type of stop and the
availability of arrival/departure times.
Therefore, I apply for allowing "begin" and "end" further in future and
not to declare them as deprecated.
With best regards,
Dirk.
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
|
|
|