Home » railML newsgroups » railml.timetable » Extension suggestion for alternativeSectionTT (railML2, railML2.5, railML3 dev suggestion, nor:alternativeSectionTT)
Extension suggestion for alternativeSectionTT [message #2337] |
Thu, 20 February 2020 13:03 ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Torben Brand
Messages: 162 Registered: March 2016
|
Senior Member |
|
|
Dear TT community,
For the use case TT:LongTermStrategicTimetabling, TT:ATimetableForACompetition, TT:SlotOrdering we would like to indicate the alternative paths to be available for a train or pattern/template train of a train group to be used if the planned path is not available. This being in a simulation, short term scheduling, dispatching decisions or data preparation for long term planning.
We suggest adding an extension in railML2.4 for Norwegian sector purposes, and if the community thinks this is beneficial to add the new element in railML2.5.
The proposed solution is to copy the element <sectionTT> with all attributes and sub elements, with the new name <nor:alternativeSectionTT>. Placement would be parallel to <sectionTT under <ocpTT>.
We will add one extra attribute @rank to indicate the rank between the different elemnts, if more than one <nor:alternativeSectionTT>.
For info on @rank see separate forum posting: https://www.railml.org/forum/index.php?t=msg&th=691& goto=2332&#msg_2332
nor:alternativeSectionTT@rank has a semantic constraint of the value 2 or higher. This as <sectionTT> is always @rank="1".
What does the community think?
[Updated on: Thu, 20 February 2020 13:06] Report message to a moderator
|
|
|
Re: Extension suggestion for alternativeSectionTT [message #2388 is a reply to message #2337] |
Tue, 10 March 2020 15:14 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Milan Wölke
Messages: 143 Registered: April 2007
|
Senior Member |
|
|
Hi Torben,
thanks for your input. I have put this topic on the agenda for the next TT developer group telco. One question in advance though, why create a new element for this at all. Shouldnt it already be enough to change the cardinalities of sectionTT and extend it with the priority. Like this we dont need the semantic constraint and it should still be semantically clear.
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: Extension suggestion for alternativeSectionTT [message #2391 is a reply to message #2388] |
Tue, 10 March 2020 17:10 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Dirk Bräuer
Messages: 311 Registered: August 2008
|
Senior Member |
|
|
Dear Torben,
from a general railML view, I would not be happy with your suggestion to encode alternative paths at a <trainPart>. The original idea of a <trainPart> was that it should be the elementary, most little and impartible part of a train. With that reason, we already denied requests of making other attributes of <trainPart> divisible like formation or load. We should write that we should be consequent here...
So, I would expect hat for an alternative path, the <train> must be copied and the options connected with @trainNumber, @additionalTrainNumber and @scope should be used to encode two <train> elements as alternatives (same train number, different scope and/or different additionalTrainNumber).
Everything else leads to (even more) "uncontrolled growth".
I know, live is full of compromises and for the certain Norwegian use case, your suggestion may be easier and more direct. So please understand my post rather as a remark in general, a warning, but no decision on your case - this would be up to the community and the coordinators.
Only to avoid misunderstandings:
With "alternative paths" you mean just the route of the train (way along the network) but no different arrival/departure/run times? If you only copy the element <sectionTT>, you would not be able to encode different arrival/departure/run times. This is also a general problem I see, because the background you mention ("if the planned path is not available") may concern the route as well as the times! So, to encode alternative paths in general railML, I would expect being able for alternative routes as well as alternative times.
Best regards,
Dirk.
|
|
|
Re: Extension suggestion for alternativeSectionTT [message #2471 is a reply to message #2391] |
Fri, 26 June 2020 12:27 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Milan Wölke
Messages: 143 Registered: April 2007
|
Senior Member |
|
|
A ticket for modelling the requirement described here as part of railML 2.5 has been created at https://trac.railml.org/ticket/381.
The ticket is a reminder in the tracking system so this requirement is not forgotten wen finalizing railML 2.5. The actual modelling however still needs to be discussed.
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: Extension suggestion for alternativeSectionTT [message #2479 is a reply to message #2391] |
Wed, 01 July 2020 15:14 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Torben Brand
Messages: 162 Registered: March 2016
|
Senior Member |
|
|
Dear Dirk and TT development group,
I will explain our UC in more detail for better understanding. We want to describe the n alternate path(s) of a train. With the path we mean the route of the train/ the way along the network (also as explained in this forum posting: https://www.railml.org/forum/index.php?t=msg&th=710& start=0&). The alternative path(s) is only "minor" different to the primary path in relation to run time calculation. Usually (secondary) track 2 instead of (main) track 1 on a crossing loop. So that different arrival/departure/run times can be neglected. We would also primarily use the feature in trainParts forming the extension nor:patternTrains (norwegian extension documented on www.jernbanedirektoratet.no/railML)), that do not have any times (do not use <times>).
As we are also concerned with "uncontrolled growth" we think that the solution suggested by Milan is the easiest (increase the multiplicity/cardinality to "n" and add @priority to <sectionTT> in railML 2.5. This would bloat the xml way less than having to create a new copy of the trainPart and train with only minor changes to the orriginal.
We could also not use the attribute @scope today as it only allows a "secondary" path and not "n" paths.
We welcome a discussion about the correct use of train@scope as we know it has been used somewhat differently as described in the wiki/in this forum posting. We think that the correct focus here is, as described in the wiki, is the train@scope is a separate slot allocation (DE:Trasse). For the solution with alternative sectionTTs this is within the same slot (order/allocation).
To describe it in a different (and maybe more precise way). alternativeSectionTT has the same order of OCPs (as it only has one trainpart). Different to train@scope which has different ocps, or a shorter length of ocps between the two alternative trains/trainparts.
[Updated on: Thu, 02 July 2020 10:36] Report message to a moderator
|
|
|
Re: Extension suggestion for alternativeSectionTT [message #2481 is a reply to message #2479] |
Thu, 02 July 2020 11:29 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Dirk Bräuer
Messages: 311 Registered: August 2008
|
Senior Member |
|
|
Dear Torben,
I understand your point and I agree that multiple <sectionTT> would be an easy solution.
But
- With multiple <sectionTT>s, you could encode different tracks between two stations. That's not the example you described, as far as I understand.
- If you want to encode different tracks within one station, you would need different <ocpTT>s, I think.
- If so (multiple <sectionTT>s and/or <ocpTT>s will be allowed), I would expect that they should have disjunctive operating days. That may not be necessary in your UC, but it is surely a much more common need for a "minor deviance" of a slot.
- May be @priority can be introduced additionally to operating days. The @priority would clarify what should happen in case the operating days are not disjunctive.
> So that different arrival/departure/run times can be neglected.
That may be so in your UC but it is surely not so in general. I think railML should first orientate on general context, not on special cases at the first place.
> The alternative path(s) is only "minor" different to the
> primary path in relation to run time calculation.
Surely you are aware that there is no hard border between a "minor" difference and a major. It would rather be a grey zone in between. And that's the point where I am really concerned about multiple <sectionTT>s and/or <ocpTT>s.
Currently, one can encode all deviations ("minor" and major) of a train path by copying it. With your extension, there would be two option for the same purpose. That would make import harder (since both options should be understood) and leads to wild growth.
So, for the sake of consequence, I still have to say: A <trainPart> is designed to be the elementary, atomic and impartible part of a train. If we weaken this here today, we can hardly deny to weaken it again tomorrow there and so on...
> We could also not use the attribute @scope today as it only
> allows a "secondary" path and not "n" paths.
That's a misunderstanding. The official primary key is of a train in railML is @trainNumber+@scope+@additionalTrainNumber. So, there can be "n" paths with the same @trainNumber and @scope=primary, they only need to be counted by @additionalTrainNumber=1, 2, 3... and so on.
And more, you do actually _not_ need to copy/repeat all the <trainPart> if you only want to encode a "minor" deviation in one <sectionTT> or <ocpTT>: You could use @scope=secondaryInner and only repeat the "inner" (minor) part of the path which deviates from the primary. Again, you could do that "n" different times by using @additionalTrainNumber=1, 2, 3...
That's the "official" way to do it now and that's why I say there would be a redundancy if you allow one more other way. However, I am no big friend of the current model, but I think that more important than that is consequence and less effort on import.
Best regards,
Dirk.
---
Am 01.07.2020 um 15:14 schrieb Torben Brand:
> Dear Dirk and TT development group,
>
> I will explain our UC in more detail for better
> understanding. We want to describe the n alternate path(s)
> of a train. With the path we mean the route of the train/
> the way along the network (also as explained in this forum
> posting:
> https://www.railml.org/forum/index.php?t=msg&th=710& start=0&).
> The alternative path(s) is only "minor" different to the
> primary path in relation to run time calculation. Usually
> (secondary) track 2 instead of (main) track 1 on a crossing
> loop. So that different arrival/departure/run times can be
> neglected. We would also primarily use the feature in
> trainParts forming the extension nor:patternTrains
> (norwegian extension documented on
> www.jernbanedirektoratet.no/railML)), that do not have any
> times (do not use <times>).
> As we are also concerned with "uncontrolled growth" we think
> that the solution suggested by Milan is the easiest
> (increase the multiplicity/cardinality to "n" and add
> @priority to <sectionTT> in railML 2.5. This would bloat the
> xml way less than having to create a new copy of the
> trainPart and train with only minor changes to the
> orriginal.
>
> We could also not use the attribute @scope today as it only
> allows a "secondary" path and not "n" paths.
>
> We welcome a discussion about the correct use of train@scope
> as we know it has been used somewhat differently as
> described in the wiki/in this forum posting. We think that
> the correct focus here is, as described in the wiki, is the
> train@scope is a separate slot allocation (DE:Trasse). For
> the solution with alternative sectionTTs this is within the
> same slot (order/allocation).
|
|
|
|
|
Re: Extension suggestion for alternativeSectionTT [message #2544 is a reply to message #2521] |
Tue, 06 October 2020 12:41 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Milan Wölke
Messages: 143 Registered: April 2007
|
Senior Member |
|
|
Hi Jörg,
thanks for your suggestion. I think for railML 3 this approach is something to be considered. However since the requirement is focussed on railML 2.5 I am afraid we need to go for a different solution.
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: Extension suggestion for alternativeSectionTT [message #2545 is a reply to message #2544] |
Tue, 06 October 2020 12:49 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Milan Wölke
Messages: 143 Registered: April 2007
|
Senior Member |
|
|
Hi all,
to keep you guys posted, this topic has been discussed in the last timetable developer telco. We decided to introduce a new element for the <ocpTT> named <alternativeSectionsTT>. Starting with railML 2.5 it will be possible to define alternative routes between the current and the following ocp along with a priority to help deciding which to choose if the default one specified as before with <sectionTT> does not seem appropriate anymore in operation. The idea here is that an alternative route does not impact the arrival and departure times of the followup stop.
The changes have been commited to the repository and can be viewed in the railML 2.5 development branch available here (https://svn.railml.org/railML2/branches/railML2.5-dev/).
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: Extension suggestion for alternativeSectionTT [message #2548 is a reply to message #2545] |
Fri, 09 October 2020 15:33 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) |
Dirk Bräuer
Messages: 311 Registered: August 2008
|
Senior Member |
|
|
Dear Milan,
we are by far not happy about this decision. We see raised effort on import and the danger for uncontrolled growth due to the overlay of this and other solutions how to encode certain situations.
If railML introduces this <alternativeSectionsTT>, I expect a clear rule when and for what to use it on export. I see many potential alternative routes which could be exported and we must avoid misunderstandings. For instance, in Germany, it is common that nearly all trains can use the opposite track (of a double-track line) without a change of timetable as well as all compatible other tracks in a station. When I export a railML file, shall I encode
a) all technological possible alternative routes as <alternativeSectionsTT>? (Means: nearly all opposite tracks?)
b) all alternative routes which can be used with the same schedule or run times?
c) all possible alternative routes which are allowed without a change of timetable? (Means also some deviations in junction areas?)
d) ... what else is the purpose of <alternativeSectionsTT>?
Best regards,
Dirk.
|
|
|
Goto Forum:
Current Time: Sun Sep 01 02:58:36 CEST 2024
|