Home » railML newsgroups » railml.timetable » TT:007 - stop on request for passenger trains only?
TT:007 - stop on request for passenger trains only? [message #2404] Fri, 20 March 2020 12:05 Go to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 279
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 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 41
Registered: April 2007
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-Haltegründe usw. [message #2417 is a reply to message #2404] Tue, 07 April 2020 19:54 Go to previous messageGo to next message
Heidrun Jost is currently offline  Heidrun Jost
Messages: 19
Registered: September 2006
Junior Member
Guten Abend!

Am 20.03.2020 um 12:05 schrieb Dirk Bräuer:
> 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]:
> [1] https://wiki2.railml.org/index.php?title=TT:stopDescription

Der unter Semantic Constraint "TT:007" beschriebene Typ eines
Verkehrshaltes "stop on request" (Bedarfshalt) kann wie beschrieben
angepasst oder aufgegeben werden.

Jedoch können wir der Einschränkung, daß mehrere Haltearten gleichzeitig
anzugeben nicht vorgesehen sind, nicht zustimmen. Aus Sicht des
Anwendungsfalls Traffic Management System (UC:TT:TrafficManagementPlan)
benötigt Thales (vor allem ab railML3) mehrere Haltegründe parallel.
So sollte die Information, daß sowohl ein Verkehrs- und ein Betriebshalt
geplant sind, auch ausgetauscht werden können. Damit kann beim
operativen Entfall eines Verkehrshaltes trotzdem noch die Information,
daß ein Betriebshalt für Crew-Wechsel o.ä. benötigt wird, beachtet
werden (ähnlich auch Betriebshalt EVU und Betriebshalt EIU).

Wir bitten um Streichung dieser Einschränkung.

Freundliche Grüße,
--
Heidrun Jost
Data Manager
Transportation Systems
Thales Deutschland GmbH

Phone: +49 (0) 30 688306 423
Schützenstr. 25 – 10117 Berlin – Germany
Re: Semantic constraint TT:007 Mehrere Betriebshalt-Haltegründe usw. [message #2419 is a reply to message #2417] Tue, 14 April 2020 20:10 Go to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 279
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.
Previous Topic: Multiple ocpTT within a station
Next Topic: Extensions to railML for passenger information at stations
Goto Forum:
  


Current Time: Sat Jul 04 20:33:22 CEST 2020