Dev:Reversing trains and formations
Reversing trains and formations
In the <timetable> scheme, there are two attributes concerning the turn of the running direction of a train, train part and/or formation: <ocpTT>.trainReverse and <formationTT>.orientationReversed. They seam to be redundant and may possibly be mixed. This shall try to explain the difference of both:
Concerning the meaning of <ocpTT>.trainReverse
It simply tells that the train(part) changes the direction - no matter whether the formation changes, reverses or neither of both.
trainReverse with change of formation = e. g. running around with the engine trainReverse with reversing of formation = train(part) of several MUs or push-pull train trainReverse with neither of them = train(part) consists of a single vehicle (MU or engine)
This information is mainly intended for passenger information (systems) which sometimes print a sign like <-> to notify the passenger where the running direction of the train changes.
Concerning the meaning of <formationTT>.orientationReversed
It has nothing to do with a train changing the running direction. It simply shall avoid the necessity to create each formation two times for both orientations. A train does not need to change its running direction for <formationTT>.orientationReversed:
Let’s say a train with the formation
- 1. propelling control car
- 2. 2nd class carriage
- 3. 1st class carriage
- 4. engine
runs all day between Airport and a place called Pirna and vice versa. For the one direction the <formation> is fine, but for the other direction the formation would have to be created a second time:
- 1. engine
- 2. 1st class carriage
- 3. 2nd class carriage
- 4. propelling control car
To avoid this, the attribute <formationTT>.orientationReversed can be used at every second train.
Please note: None of the trains do ever change their running direction during a single run - as in practice between Airport and Pirna. ("I suppose you know the location.")
So far, no need to use <formationTT>.orientationReversed at a formation consisting of one vehicle only. This would have been paradox since one cannot change the order of a list containing only one element.
One should be aware that <ocpTT>.trainReverse semantically applies to the whole train while <formationTT>.orientationReversed applies to the formation of one <trainPart> only. So, there is another way to change the orientation of the formation of a whole train without <formationTT>.orientationReversed: Each vehicle forms its own <trainPart>, may be due to different operating days or so.
<train> <trainPartSequence> <trainPartRef ref=’TP1.1’ position=’1’> <trainPartRef ref=’TP2.1’ position=’2’> <trainPartRef ref=’TP3.1’ position=’3’> </trainPartSequence> <trainPartSequence> <trainPartRef ref=’TP3.2’ position=’1’> <trainPartRef ref=’TP2.2’ position=’2’> <trainPartRef ref=’TP1.2’ position=’3’> </trainPartSequence> </train>
(This refers to the current situation in RailML until before version 2.2. It may change in future.)
1) A formation running in one direction (“forward”) without reversing:
2) A formation of several vehicles running in the other direction (“backward”) without reversing:
3) A formation of several vehicles reverses direction without ‘running around’ of the engine:
4) A formation of several vehicles reverses direction with ‘running around’ of the engine:
- <ocpTT>.trainReverse: shall be used
- <formationTT>.orientationReversed: cannot be used since the formation changes
To avoid no. #4, the engine may be put in an own <trainPart> so that #4 becomes “two times #3”. This reduces the total number of necessary formations by trend but it increases the total number of train parts. (Since a train part normally has more overhead than a formation, it may be better to handle rather more formations than more train parts.)
- It is currently not defined "which way around" is the "normal" order of a formation and which is the "reverse" order of a formation. It is not enforced to define the engine as the first vehicle of a formation. Even for a formation which is used always in the same direction, it is up to the RailML writing software either to define it in one or the other orientation and possibly never use it without <formationTT>.orientationReversed set to 'true'. So, the defined orientation of a formation (given in the RailML file) may be the first which occurs or the one which is mainly used or the one of which somebody thought that it may be the mainly used or none of that...
- You should always treat the vehicle with the lowest orderNumber in a formation being the first vehicle in running direction (at the front of the train) and the vehicle with the highest orderNumber as the last one (at rear of the train) - except if <formationTT>.orientationReversed is set to 'true' which of course makes it the other way 'round.
- It is currently not 'forbidden' to use <formationTT>.orientationReversed with formation of one single vehicle. For some special cases it is the only way to define the running direction of one single vehicle. This could possibly apply e. g. to seat reservation: Whether certain seats are facing running direction or backwards. One could imagine a tramway operating between two terminal loops. If the tramway consists of one single bi-directional vehicle, the attribute orientationReversed is the only possibility to describe whether the tramway uses the terminal loops to turn around or just reverses.