Home » railML newsgroups » railml.timetable » [railML3] Type of train (goods/passenger)
| [railML3] Type of train (goods/passenger) [message #2927] |
Mon, 28 February 2022 14:22  |
Milan Wölke
Messages: 139
Registered: April 2007
|
Senior Member |
|
|
Hi all,
the timetable developer group recently discussed how to encode the train type, i.e. how to say that it is a passenger train or a goods train. In order to do that we decided to provide an enumeration to the OperationalTrainSection. This enum would have 2 values: passenger and goods. However it would be an extendable enumeration. We decided to keep it that simple because we found that once you start extending this enumeration, its really hard to say where to stop. For example one could also include a construction train, but would a train that consists of only a single locomotive be too much already. As railML3 development follows the requirements of use case definitions and the use cases for timetable (traffic management and passenger information) only require distinguishing freight from passenger trains, we kept it at that.
It should be noted that the information if the train is empty or not can be modelled in a different manner independently of the question of train types.
The current modelling restricts a train to one train type per section of its path. However since it is specified at the OperationalTrainSection, the train can belong to different train types in different parts of its path.
What does the community think about this? Should we add more enumeration values as they are required in a TMS you know? If so, which ones? Should it be possible for a train to belong to more than one train type at the same time?
Any feedback as always is highly welcome.
Thanks in advance.
--------------------------
die Timetable Developer Group hat kürzlich darüber diskutiert, wie man den Zugtyp kodieren kann, d.h. wie man sagen kann, dass es sich um einen Personenzug oder einen Güterzug handelt. Um das zu tun, haben wir beschlossen, eine Enumeration für die OperationalTrainSection bereitzustellen. Diese Aufzählung würde 2 Werte haben: Personen- und Güterverkehr. Die Enumeration wäre jedoch erweiterbar. Wir haben uns entschieden, es so einfach zu halten, weil wir festgestellt haben, dass es wirklich schwer ist, zu sagen, wo man aufhören soll, wenn man einmal anfängt, diese Enumeration zu erweitern. Man könnte zum Beispiel auch einen Bauzug einbeziehen, aber ein Zug, der nur aus einer einzigen Lokomotive besteht, wäre schon zu viel. Da die railML3-Entwicklung den Anforderungen der Use-Case-Definitionen folgt und die Use-Cases für den Fahrplan (Traffic Management und Fahrgastinformation) nur die Unterscheidung von Güter- und Personenzügen erfordern, haben wir es zunächst dabei belassen.
Es sei darauf hingewiesen, dass die Information, ob der Zug leer ist oder nicht, unabhängig von der Frage der Zugtypen auf andere Weise modelliert werden kann.
Die derzeitige Modellierung beschränkt einen Zug auf eine Zugart pro Abschnitt seiner Strecke. Da dies jedoch in der OperationalTrainSection festgelegt ist, kann der Zug in verschiedenen Abschnitten seiner Strecke verschiedenen Zugtypen angehören.
Was denkt die Community hierüber? Sollten wir weitere Enumeration-Werte hinzufügen, wie sie in einem TMS erforderlich sind, wie Sie wissen? Wenn ja, welche? Sollte es möglich sein, dass ein Zug gleichzeitig zu mehr als einer Zugart gehört?
Jede Rückmeldung ist wie immer sehr willkommen.
Vielen Dank im Voraus.
Mit freundlichen Grüßen, Milan
Best regards, Milan
Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] Type of train (goods/passenger) [message #2930 is a reply to message #2927] |
Wed, 02 March 2022 13:08  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Hallo Milan,
aus unserer Sicht trifft eine Beschränkung auf Nur-Güter- und Nur-Personenzüge auf keine Begeisterung, da sie Mehraufwand auslöst.
Dazu muss ich vorausschicken, dass wir railML bisher nicht streng nach Use-Cases verwenden können, sondern immer wieder auch ein allgemeiner Datenexport im Fokus steht. Das mag mit einer besonderen Stellung zu tun haben, die FBS als recht intensive Planungssoftware "am Anfang der Datenkette" hat - es wird sehr viel exportiert, fast nichts importiert. Wir können jedenfalls nicht erzwingen, dass unsere Exporte nur nach Use-Case verwendet werden bzw. müssten einen allgemeinen Use-Case anbieten; alles andere wäre Realitätsverweigerung und würde nur dazu führen, dass vermeintliches Nicht-Funktionieren wieder zu mehr Supportaufwand führt und auch ein schlechtes Licht auf railML fällt.
Vor diesem Hintergrund ist es für uns erfahrungsgemäß das Wichtigste, Voll- und Leerzüge korrekt trennen zu können. Insbesondere Reisezug-Leerzüge müssen als solche eindeutig identifiziert werden können (sind für Umlauf, Statistik, Trassenbestellungen etc. unverzichtbar, dürfen aber in der Fahrgastinformation nicht erscheinen).
Aus dieser Sicht würden wir mindestens die Arten
Reisezug-Vollzug,
Reisezug-Leerzug,
Güterzug,
Tfz.-Leerfahrt
und alle Kombinationen daraus benötigen.
Ein auch nur vorübergehendes Nicht-Unterstützen einer der Kombinationen stellt uns vor den Mehraufwand, beim Export irgendwie mit den Fällen umgehen zu müssen, die nun einmal theoretisch auftreten können und nicht unterstützt werden: Der Programmierer muss dann entweder eine Fehlermeldung mit Verweigerung des Exports oder ein Überführen in den nächst-verfügbaren unterstützten Fall programmieren. Das ist Mehraufwand, und wenn er nur vorübergehend ist, ist er besonders schwer kommerziell abbildbar. Ein vorübergehendes Nicht-Unterstützen von Güterzügen oder Tfz-Leerfahrten würde bedeuten, dass wir solche Fahrten beim Export erst wieder verbieten müssten mit dem entsprechenden Mehraufwand (Fehlermeldungen in alle Sprachen des GUI übersetzen...). Da der Vergleichsmaßstab für unsere Anwender immer das relativ etablierte railML 2.x ist, können wir uns ein sehr eingeschränktes railML 3 praktisch nicht leisten.
Dass Reisezug/Güterzug und Vollzug/Leerzug an unterschiedlichen Stellen definiert werden, sehe ich nicht als Problem an. Und ja, die Vollzug-/Leerzug-Unterscheidung ist fließend, ein Reisezug kann auch nur teilweise abgesperrt sein. Im Prinzip muss die Absperrung und die Sitzplatzanzahl wieder "wagenscharf" gehen. In diesem Sinne braucht es keine explizite Leerreisezug-Einstufung - ein Leerreisezug ist einer, bei dem kein Sitzplatz freigegeben ist. Es ist halt nur wichtig, relativ leicht einen komplett abgesperrten Reisezug (Leerreisezug) identifizieren zu können, da solche Züge oft auch Betriebsstellen anfahren, die keine Bahnsteige/IBNR/Fahrgastinformation usw. haben und dadurch schnell Importfehler auslösen, wenn sie nicht als Leerreisezüge identifiziert werden.
> ...dass es sich um einen Personenzug oder einen Güterzug handelt.
> ... Diese Aufzählung würde 2 Werte haben: Personen- und Güterverkehr.
Vorsicht: "Zug" und "Verkehr" ist nicht dasselbe. Ein Leerreisezug ist ein Reisezug, aber kein Reiseverkehr. Wenn Ihr das so definiert, muss jedem klar sein (und bitte auch im Englischen klarstellen), ob ein Leerreisezug trotzdem als Reisezug zu kennzeichnen ist (weil es nur nach der Wagenart und nicht nach der Freigabe geht) oder ob er nicht als solcher zu kennzeichnen ist (weil es nur nach Verkehrsart geht).
Und damit kommen wir zu den Kombinationen: Mit einer klaren Definition kommst Du nicht umhin, auch klarzustellen, wie mit gemischten Zügen umzugehen ist. Ja, die gibt es auch heute noch und das nicht zu selten. Eine Definition wie: "Ein Zug ist ein Reisezug, wenn er überwiegend aus Reisezugwagen besteht" wirft nur wieder unangenehme Diskussionen auf wie: "Und was ist bei 50:50?" oder ob ein Post- oder Autotransportwagen als Reisezugwagen zählt (Stichwort Nachtzüge mit Autotransportwagen). Bitte nicht sowas machen!
Ich denke, hier sollten alle Kombinationen zugelassen werden, da diese Informationen sehr allgemeingültig sind, deren Use-Cases mindestens absehbar sind und wir keinen so offensichtlichen und leicht vermeidbaren vorübergehenden Mehraufwand wegen noch-nicht wahrgenommener Use-Cases erzeugen wollen. Und ja, das ist eine relative Meinung und ich halte es trotzdem für richtig, nach Use-Cases vorzugehen. Nur eben wie üblich mit Kompromissen und nicht sklavisch.
Viele Grüße,
Dirk.
|
|
|
|
| Re: Re: [railML3] Type of train (goods/passenger) [message #2931 is a reply to message #2930] |
Thu, 03 March 2022 15:27 |
Milan Wölke
Messages: 139
Registered: April 2007
|
Senior Member |
|
|
Hallo Dirk,
danke zunächst für dein ausführliches Feedback.
Wenn ich dich richtig verstehe, plädierst du dafür auch eine reine Triebfahrzeugfahrt in die Enumeration aufzunehmen - werde ich in der nächsten Entwicklerrunde vorschlagen. Ich wäre eher zuversichtlich, dass wir das hinzufügen, wenn es benötigt wird.
Deine Rückmeldung hat mich auch nochmal dahingehend zum Nachdenken gebracht, dass man mglw. die Festlegung, um welche Art von Zug es sich handelt, näher an der Definition, ob es sich um einen Leerzug handelt oder nicht, anbringen sollte, also mglw. auch an der Kategorie.
Quote:Im Prinzip muss die Absperrung und die Sitzplatzanzahl wieder "wagenscharf" gehen
Auf was beziehst du dich hiermit? In railML 2 war es über formationTT möglich die Zahl der Sitzplätze o.ä. am trainPart festzulegen. Dies ist bisher noch nicht in der railML 3 Modellierung berücksichtigt worden. Wie auch in railML 2 kann allerdings auch weiterhin in Rollingstock pro Wagen erfasst werden, welche Menge an Sitzplätzen vorhanden ist. Hattest du das gemeint, oder beziehst du dich auf eine andere Modellierung von railML2?
Best regards, Milan
Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] Type of train (goods/passenger) [message #2940 is a reply to message #2931] |
Tue, 08 March 2022 12:27 |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Hallo Milan,
>> Im Prinzip muss die Absperrung und die Sitzplatzanzahl wieder "wagenscharf" gehen
> Auf was beziehst du dich hiermit?
Ja, wie vermutet auf die Möglichkeit, die Sitzplatzanzahl einer <formation> am <trainPart> überschreiben zu können.
- Wo eine <formation> definiert wird, weiß man noch nicht, ob und wieviele der physisch vorhandene Sitzplätze abgesperrt bzw. freigegeben sind.
- Es ist nicht gewollt und unpraktikabel, für ein und denselben Wagenzug mehrere <formation>s anzulegen mit jeder möglichen Kombination aus abgesperrten und freigegebenen Sitzplätzen.
(Das "unpraktikabel" bezieht sich hier insbesondere auf Umlaufpläne, von denen eine umlaufende Wagengruppe ja idealer Weise auch als eine <formation> referenziert wird.)
- Folglich ist es wieder notwendig, die Sitzplatzanzahl einer <formation> am <trainPart> hinsichtlich freigegeben und abgesperrt zu konkretisieren = zu überschreiben.
- Das entspricht dem ebenso (insb. für Güterzüge notwendigen) möglichen Konkretisieren der Masse einer <formation> am <trainPart> durch @timetableLoad und ggf. Überschreiben von @weight...
- ...sowie dem ebenso möglichen Überschreiben der Höchstgeschwindigkeit einer <formation> am <trainPart> (die Formation kann in einzelnen Zügen bewusst langsamer eingeplant sein als technisch möglich
(wieder typisch für Güterzüge, die oft nur mit 80 oder 90 km/h geplant werden, obwohl sie technisch 100 oder 120 km/h fahren könnten).
- Ein "wagenscharfes" Absperren kann man nun erreichen, wenn man einzelne Wagen in je einen <trainPart> packt und dann dessen Sitzplatzanzahl überschreibt. Diese Möglichkeit (ggf. abgestuft in Wagengruppen) ist wichtig für Wagenstandsanzeiger und für Fälle, in denen nur der freigegebene Teil der Zugbildung an den Bahnsteig passt und ausgedrückt werden soll, ob der oder die abgesperrten Wagen vorn oder hinten im Zug laufen.
Das Überschreiben der Sitzplatzanzahl am Zugteil ist in railML2.x eine Notwendigkeit für solche Anwendungsfälle wie "Platzkm-Statistik", "Auslastungsprognose", "Aufgabenträger-Abrechnung", die einen guten Teil unserer Exporte ausmachen.
Viele Grüße,
Dirk.
|
|
|
|
| Re: [railML3] Type of train (goods/passenger) [message #2941 is a reply to message #2940] |
Tue, 08 March 2022 13:52 |
Milan Wölke
Messages: 139
Registered: April 2007
|
Senior Member |
|
|
Hallo Dirk,
aus meiner Sicht sollte der größte Teil dessen was du forderst schon jetzt unterstützt sein. Am <operationalTrainSectionPart> (beschreibt einen Zugteil, also eine Teilformation, eines Zuges) kann eine <formationInformation> angegeben werden. Hier können neben einer konkreten Formation auch Eigenschaften des Zuges beschrieben werden, etwa verfügbare Facilities. Damit sollte auch abbildbar sein, dass ein Wagen verschlossen ist. Die Facilities unterscheiden sich soweit ich das sehe nicht von denen aus railML2 und auch die referenzierung aus dem <operationalTrainSectionPart> ist vergleichbar mit der aus railML2.
Siehe dazu auch diese beiden Diagramme aus der aktuellen Modellierung (handelt sich um eine Beta, kann also noch geändert werden):
https:// forum.railml.org/userfiles/2022-03-08_railml_railml3-typeoft rain1.png
https:// forum.railml.org/userfiles/2022-03-08_railml_railml3-typeoft rain2.png
Was allerdings noch fehlt, und diesen Teil würde ich mal mitnehmen - vielen Dank für den Input -, ist, dass an dieser Stelle auch fahrdynamische Eckdaten angegeben werden können sollten.
Best regards, Milan
Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Goto Forum:
Current Time: Fri Apr 26 16:27:12 CEST 2024
|
Members
Search
Help
Login
Home
