Home » railML newsgroups » railml.timetable » These: Das Aufteilen eines großen RailML-Netzes auf mehrere kleinere RailML-Netze darf zu keinem Verlust an Informationen führen.
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 Go to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
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/
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 Go to previous message
Joachim Rubröder railML is currently offline  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 ==----
Previous Topic: Wendevorgaben
Next Topic: RailML semantics, nextdeparture, recurringschedule
Goto Forum:
  


Current Time: Thu Mar 28 23:21:56 CET 2024