Re: offene Diskusionspunkte (Fahrzeugidentitaet ueber Zugabschnitte, abweichende Laufwege, ocps) [message #706 is a reply to message #705] |
Fri, 11 March 2011 05:55 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to previous message](/forum/theme/default/images/down.png) |
Joachim Rubröder railML
Messages: 0 Registered: November 2019
|
|
|
|
Hallo Simon,
hier einige erste Anmerkungen zu Deinen Diskussionspunkten:
1, Darstellung der Identität der Fahrzeuge über mehrere Zugabschnitte
So es um Verkehrliche Aspekte geht (z.B. Sitzplatzbuchungen oder
Fahrgastinformation) ist aus Sicht railML die Bildung von commercial
trains der richtige Ansatz.
Wenn Du diese Variante nicht nützen willst, da es Dir um betriebliche
Aspekte und um Leerzüge geht, so bleibt meiner Meinung als saubere
Lösung nur die Bildung von Umläufen.
Die Nutzung des connection-Elements für Durchläufe ist eher eine
Krücke, die wir mit der Version 2.0 gerade beseitigen wollten. Dann schon
lieber ein neues Element für diesen Zweck schaffen.
Einen Einfluss hat aber auch die Art, wie die Formations gebildet werden.
Wenn jeder physische Zugteil eine eigene Formation bekommt, ist die
Durchbindung klar ersichtlich.
2, Darstellung von tageweise abweichenden Laufwegen
Wir waren uns beim letzten Meeting glaube ich einig, dass die
DB-Modellierung mit Ergänzungsfahrplänen nicht der laut railML
schöneren Modellierung mit kompletten Zugläufen entspricht. Trotzdem
muss man die DB-Modellierung aus Sicht railML auch als alternative
gültige Modellierungsvariante zulassen.
3, Sematik des <ocp> bzw. der Wertebereich von
ocp.propOperational.operationalType
Bei den ocp handelt es sich meist um Betriebsstellen, deren Typen
natürlich von Land zu Land leicht differieren. Meist handelt es sich aber
doch um etwa die gleichen Typen (station, juction, blockSignal, ...). Mit
der Nutzung der bestehenden Typen (so identifizierbar) und der
Möglichkeit der ' other:enumeration' für weitere Typen (nicht
identifizierbar) sollten die Bedürfnisse abgedeckt sein, oder?
Ich bin gespannt, was die anderen railML-Nutzer für eine Meinung bei
diesen Diskussionspunkten vertreten und bin gerne bereit, den Konsenz dann
ins Schema aufzunehmen.
Viele Grüsse,
Joachim Rubröder
--
----== posted via PHP Headliner ==----
|
|
|