Home » railML newsgroups » railml.timetable » joining and splitting of trains
joining and splitting of trains [message #701] Mon, 04 October 2010 12:34 Go to next message
Christoph.Jobmann is currently offline  Christoph.Jobmann
Messages: 12
Registered: October 2010
Junior Member
Greetings,

lately I was asked if and how it was possible to express the planned
spliting and / or joining of trains in railML2.0. After having a few
closer looks at the html documentation and the wiki the element
TT:connection looked nice.
What confuses me at this point is the observation that it expects a
mandatory trainRef as attribute. I can understand this is required for the
conOperation values 'isExpectedBy' and 'isWaitingFor', but for the values
'join' and 'split' it would seem more straightforward to apply a
trainPartRef as attribute, wouldn't it?
Using a trainRef at this point makes it - at least in my eyes - neccessary
to add a backward connection from the train that the connection is to be
established to since it would not always be obvious which parts of the
trains should be connected to each other.

Even with this trick there still seems to be a flaw about multiple trains
joining and splitting which seems to require evaluating additional
information like positions of trainPartRefs in trains and direction
changes.

Am I missing something? Or would an additional (optional) Attribute
trainPartRef for the element TT:Connection be useful?

Best regards
Christoph Jobmann

--
----== posted via PHP Headliner ==----
Re: joining and splitting of trains [message #702 is a reply to message #701] Wed, 20 October 2010 08:18 Go to previous message
Christoph.Jobmann is currently offline  Christoph.Jobmann
Messages: 12
Registered: October 2010
Junior Member
Greetings again,

during yesterday's meeting of the railml.org initiative I was able to
discuss the topic issued earlier. I came to the conclusion that the
element connection should not be used for splitting and joining of trains.
Personally I will consider the attribute values 'join' and 'split' for the
attribute 'conOperation' as deprecrecated.
As stated in Mr. Rubröder's example for the CityNightLine, additional
trains with type 'commercial' shall be used to model joining and splitting
of trains.

It was also pointed out that there is need to keep track of the identity
of a vehicle during its course. In particular it has to be clear if
vehicles which are added (or removed) during the train course are coupled
at the from or at the rear of the train.
Since not all planning system are able to supply this kind of information
a way has to be found which is able to transport as much information as
possible without losing compatibility.
In my eyes, if used properly, the trains of type 'commercial' can supply
this kind of information - even if there is no explicit splitting or
joining train given.

Within the next days I will supply a small toy example which shall point
out a few possible problems and at the same time offer a solution.

Best regards
Christoph Jobmann

------------------------------

Guten Tag,

im Rahmen des getrigen Treffens der railML.org-Initiative hatte ich unter
anderem die Gelegenheit, über das unten angeführte Thema zu sprechen.
Ich bin zu dem Schluss gekommen, dass das Element 'connection' nicht für
Koppeln bzw. Flügeln verwendet werden sollte. Ich persönlich betrachte
die Attibutwerte 'join' und 'split' für das Attribut 'conOperation' als
veraltet.
Wie Herr Rübröder bereits in seinem Beispiel zum CityNightLine
dargestellt hat, sollten für die Abbildung von Koppeln bzw. Flügeln
zusätzliche train-Elemente mit type-Attributwert 'commercial' verwendet
werden, welche den kompletten Zuglauf der einzelnen Zugteile beschreiben.

Im Rahmen der gestrigen Gespräche wurde auch angesprochen, dass es für
einige Planungssysteme notwendig ist, die Identität eines Fahrzeugs im
Zuglauf nachverfolgen zu können. Insbesondere sollte es klar abbildbar
sein, ob ein das An- oder Abkuppeln eines Fahrzeugs vorne oder hinten
vorgenommen wird, oder ob vielleicht sogar ein Fahrzeugaustausch
vorgenommen wird.
Da diese Information jedoch nicht für alle Planungssysteme gleichermaßen
relevant bzw. lieferbar ist, sollte ein Weg gefunden werden, auf dem so
viel Information wie möglich geliefert bzw. übernommen werden kann, ohne
die Kompatibilität einzuschränken.
Meiner Meinung nach kann diese Information - sofern richtig eingesetzt -
durch train-Elemente von Typ 'commercial' sogar dann übermitteln, wenn
laut Fahrplan noch kein Koppel- bzw. Flügelzug vorgesehen ist; in diesem
Fall wäre aus betrieblicher Sicht von Stärken bzw. Schwächen die Rede,
das Fahrzeug soll beispielsweise als Verstärker aus einer Abstellanlage
bereitgestellt werden.

Ich werde innerhalb der nächsten Tage ein kleines Beispiel erarbeiten,
welches hoffentlich geeignet ist, die beschriebene Problematik zu
verdeutlichen und gleichzeitig eine akzeptable Lösung anbietet.

--
----== posted via PHP Headliner ==----
Previous Topic: Propagate 'any' attributes
Next Topic: country code for trains
Goto Forum:
  


Current Time: Fri Mar 29 00:18:53 CET 2024