| TT:007 - stop on request for passenger trains only? [message #2404] |
Fri, 20 March 2020 12:05  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear community,
in "our guidelines on semantic constraints" it is written "please discuss it in the forum". Therefore, I want to note that I have an objection
concerning Proposed Semantic Constraint "TT:007" at [1]:
> A stop on request is a traffic stop. A train will only stop at a stop on request stop when stopping is requested by passengers, regardless if its passengers aboard the train or waiting at the station.
This proposed statement assumes that a stop on request must be linked with passengers and therefore, cannot happen at non-passenger trains. I think this is too much restrictive. I would not limit stops on request to passengers only.
I can easily imagine a local freight train which is scheduled to pick up / set down wagons at an immediate stations. Not at each station on each operating day there will be an actual demand. So why should the train stop at each station on each operating day?
In my opinion, the term "stop on request" tells the reader that a scheduled stop can be omitted without a timetable change. Vice versa, if a scheduled stop which is not "on request" shall be omitted, there would be a new/changed timetable necessary.
The main difference between passenger and freight stops on request is: A stop on request for passenger trains is typically very short; the train path after that stop is varied not very much (possibly only within the amount of run time supplements), so the train is still more or less "in time". A stop on request of a freight train can hardly be short so in case it is omitted, the train will significantly fall out of its timetable.
So the question for us in railML is: Do we want to force freight trains to get a new timetable in case of omitted stops because otherwise, they would fall significantly (too much for the railML community) out of schedule?
In my opinion: No. Freight trains already run very often very much out of schedule. We should accept that as a matter of fact and not interfere into practice here. So if the community follows my recommendation, I would suggest that the above mentioned statement is alter to:
> A stop on request is a traffic stop. A train will only stop at a stop on request stop when stopping is requested by traffic. The stop can be omitted without a further notice and without a change of timetable. In case of passenger trains, this is regardless of passengers aboard the train or waiting at the station.
Best regards,
Dirk.
[1] https://wiki2.railml.org/index.php?title=TT:stopDescription
|
|
|
|
| [railml2] Re: TT:007 - stop on request for passenger trains only? [message #2406 is a reply to message #2404] |
Mon, 23 March 2020 19:33  |
Milan Wölke
Messages: 139
Registered: April 2007
|
Senior Member |
|
|
Hi Dirk,
thanks for noticing that. From my point of view you are 100% correct. The documentation is driven too much by the view of systems mainly working with passenger trains. I will propose to accept your proposed wording into the description of the semantic constraint at the next developer telco.
Thanks again.
Best regards, Milan
Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
[Updated on: Mon, 23 March 2020 19:34] Report message to a moderator |
|
|
|
|
|
| Re: Semantic constraint TT:007 Mehrere Betriebshalt-HaltegruÌnde usw. [message #2419 is a reply to message #2417] |
Tue, 14 April 2020 20:10 |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Sehr geehrte Frau Jost,
ich denke, hier muss es sich um ein Missverständnis handeln. In dem Forumspost ging es lediglich darum, ob Bedarfshalte auf Reisezüge beschränkt sind oder auch bei Nicht-Reisezügen (insbesondere Güterzügen) vorkommen können. Es wurde bislang auch keine Entscheidung gefällt.
Die Angabe mehrerer Haltegründe pro Halt betrifft m. E. das Unter-Element <stopDescription>.<stopActivities>. Hier kann man selbstverständlich mehrere Haltegründe (<stopActivity>-Elemente) aufzählen, u. a. auch <stopActivitiy type="crewChange">.
Bitte verwechseln Sie nicht Halteart (<stopDescription>@ocpType/@commercial) und Haltegründe (<stopDescription>.<stopActivities>). Die Halteart "commercial" ist als boolescher Wert definiert und kann daher nur disjunkt einen Verkehrshalt oder Betriebshalt codieren. Dies ist als eine Art aggregierte Zusammenfassung der Haltegründe zu verstehen: Aus der Kombination der Haltegründe folgt, ob die Halteart Verkehrshalt oder Betriebshalt ist. Diese Halteart ist brachenüblich, also ein Zugeständnis an "state of the art", hat aber rein innerbetriebliche Hintergründe der Verkehrsunternehmen und sollte hier nicht überbewertet werden. Sie steht im Rahmen der Semantic Constraints hier auch nicht zur Diskussion, da die Struktur bereits in allen railML 2.x-Versionen so besteht. Ich empfehle, die Aufzählung der Haltegründe zu verwenden.
Mit freundlichen Grüßen,
Dirk Bräuer.
|
|
|
|
Members
Search
Help
Login
Home
