Home » railML newsgroups » railml.timetable » offene Diskusionspunkte (Fahrzeugidentität über Zugabschnitte, abweichende Laufwege, ocps)
| Re: offene Diskusionspunkte (Fahrzeugidentitaet ueber Zugabschnitte, abweichende Laufwege, ocps) [message #718 is a reply to message #706] |
Mon, 04 April 2011 15:48   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Hallo Simon und Joachim,
> 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.
Ich stimme Joachim hier uneingeschränkt zu.
> 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.
Umläufe sind indirekt eine Alternative; allerdings möchte ich anmerken,
dass meinem Verständnis nach "commercialTrains" nicht auf "öffentliche"
Züge beschränkt gedacht war. Vielmehr bilden wir auch für Leerzüge und
-zugteile commercialTrains - überhaupt kann sich alles, was in der
RailML-Datei so rumfährt, sowohl als operational- als auch als
commercialTrain vorkommen. (In unseren RailML-Exporten kommen tatsächlich
alle Züge doppelt - je einmal als commercial und einmal als operational -
vor, auch die Leerzüge.)
Eine Abgrenzung von "öffentlichen" Zügen ist ohnehin schwer möglich - sind
Güterzüge öffentlich? Was ist mit von einer Firma bestellten
Sonderfahrten, in denen dann durchaus Reisende - Firmenkunden - mitfahren?
Ich will damit sagen, dass es m. E. ohnehin Willkür wäre, für welche Züge
"commercialTrains" gebildet werden, wenn sie nicht für alle Züge gebildet
würden.
Vielmehr sollte der Umstand, ob ein Zug dem Reiseverkehr dient, über die
Eigenschaft timetable -> category -> trainUsage = passenger (und ggf.
deadRun) seiner Zuggattung abgebildet werden.
> 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.
Zustimmung.
> 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.
Dies ist ja auch gegeben - die DB-Modellierung kann rekonstruiert werden,
indem die scope-Ausprägungen in "Art des Ergänzungsfahrplans" (der DB)
umgerechnet wird (1:1-Zuordnung). Was fehlt (@Joachim: hatte ich schon mal
beantragt, ist aber m. E. nicht dringlich) ist die lfd. Nr. des
Ergänzungsfahrplans (der DB), für die es keine Entsprechung in RailML gibt
und ohne die eine 100%ige Rekonstruktion in Extremfällen nicht möglich ist.
Meinem Verständnis nach geht es bei Simons Vorschlag im Prinzip "nur" um
die Frage, ob alle Alternativfahrpläne (DB: "Ergänzungsfahrpläne")
zusammen mit dem Stammzuglauf eine explizite Gruppe (Element-Ebene im
RailML-Sinne) bilden oder ob sich der Zusammenhang nur implizit
erschließt. Nach derzeitigem RailML-Modell geht es nur implizit - alle
Züge mit gleicher Zugnummer bilden die Gruppe, den Stammzuglauf erkennt
man am scope=primary. Simon wünschte sich eine explizite Gruppierung, z.
B. dass die Alternativ-/Ergänzungsfahrpläne eine Untergruppe oder
gemeinsame Gruppe mit dem Stammzuglauf bilden.
Dagegen sprechen (ich versuche mal aus meiner Sicht zusammenzufassen)
a) dass es eine sehr starke und womöglich nicht allgemeingültige Bindung
an das DB-Modell wäre. Im internationalen Vergleich ist das DB-Modell bei
weitem nicht unumstritten - ganz im Gegenteil. Schon in Österreich
funktioniert es nicht mehr, und auch in Deutschland war es früher anders
(Parallelläufe mit gleicher Zugnummer waren möglich, die es jetzt nicht
mehr sind). Insofern sollten wir in RailML kein womöglich zu
einschränkendes Modell wählen (z. B. können im Ausland immer noch
Parallelläufe zulässig sein).
b) dass es nun schon einmal die Abbildungsmöglichkeit mit scope in RailML
2 gibt und Redundanzen schlecht sind, weil ein lesendes Programm dann den
doppelten Aufwand hätte. Selbst wenn sich herausstellte, dass die
bisherige Modellierung in RailML von der Mehrheit als schlechter empfunden
wird als die DB-Modellierung, könnten wir es nur schwer korrigieren, ohne
die Abwärtskompatibilität zu brechen.
Ich bin mir bewusst, dass (a) kein Argument für oder gegen eine explizite
oder implizite Gruppierung der Alternativfahrpläne ist - man könnte auch
eine allgemeingültige explizite Gruppierung aufstellen. Ich fürchte daher,
dass (b) jetzt das entscheidende Argument gegen eine zweite Möglichkeit
ist.
> 3, Sematik des <ocp> bzw. der Wertebereich von
> ocp.propOperational.operationalType
> Bei den ocp handelt es sich meist um Betriebsstellen...
Ich möchte noch anmerken, dass m. E. der Begriff ocp im Deutschen
Fachwortschatz am besten durch "Fahrzeitmesspunkt" wiedergegeben wird. Ein
Fahrzeitmesspunkt kann, muss aber keine Betriebsstelle sein - es kann z.
B. auch ein Stellwerk, Halteplatz oder anderer Bahnhofsteil sein. Früher
konnte jedes Stellwerk, für das ein eigener Fahrplanauszug (BFO) erstellt
wurde, ein Fahrzeitmesspunkt sein. Fahrzeitmesspunkte sind (in
Deutschland) die senkrechten Linien im klassischen Bildfahrplan.
Beispielsweise waren die Stellwerke Leipzig Hbf B10, B21 und B26 eigene
Fahrzeitmesspunkte, aber keine Betriebsstellen (sondern Bahnhofsteile von
Leipzig Hbf). Sie haben eigene Fahrplanauszüge (BFO'en) erhalten, da bei
ihnen nur jeweils etwa 1/3 der Züge vorbeikam wie an der Bahnhofshalle.
Ich empfehle daher, als deutschen Begriff für ocp "Fahrzeitmesspunkt" zu
verwenden.
Viele Grüße,
Dirk.
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
|
|
|
|
Current Time: Thu May 16 00:45:15 CEST 2024
|
Members
Search
Help
Login
Home
