The correct use of trackRef under sectionTT [message #2336] |
Wed, 19 February 2020 15:42 ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Torben Brand
Messages: 161 Registered: March 2016
|
Senior Member |
|
|
Dear TT community,
We would like to ask for an unambiguous definition of the path of a sectionTT with precise start and end points.
Jernbanedirektoratet would like to suggest the following, based on which aggregation level you are using in your TT/IS model:
Network
In the seldom case that there exist two lines between two OCP's with no intermediate OCP in between, use @lineRef or describe the path for human interpretation in @section and do not use <trackRef>.
Macroscopic
For a macroscopic model with only a main track with or without station tracks there is no alternate path to choose from. So, do not use <sectionTT> as it does not give any added value.
Microscopic
For a microscopic model use <trackRef> for all tracks forming the path from the start position of the current <OcpTT>
Microscopic without stop positions
Here the tracks containing the <crossSection> elements form the start (from and including) and end (to and including) tracks to be referenced.
In the illustrated example bellow the tracks to be referenced are:
OCPTT@ocpRef="A" with sectionTT/trackRef@ref to the tracks tr1,tr3,tr6 and tr8
OCPTT@ocpRef="B" with sectionTT/trackRef@ref to the tracks tr8,tr10,tr9,tr12 and tr14
Microscopic with stop positions
Here the tracks containing the referenced infrastrucutre object referenced from <stopDescription> forms the start (from and including) and end (to and including) tracks to be referenced.
In the illustrated example bellow the tracks to be referenced are:
OCPTT@ocpRef="A" with sectionTT/trackRef@ref to the tracks tr3,tr6, tr8, tr10 and tr9
OCPTT@ocpRef="B" with sectionTT/trackRef@ref to the tracks tr9,tr12, tr14 and tr16
Illustration
![https://1drv.ms/u/s!Ar_YbBaAx1YzkUbErNZahbNiRZ_-?e=WxpClV](https://1drv.ms/u/s!Ar_YbBaAx1YzkUbErNZahbNiRZ_-?e=WxpClV)
What does the community think?
PS. I've also linked to the PDF in case the image gets broken... (attachments are also not possible in the forum)
https://1drv.ms/b/s!Ar_YbBaAx1YzkUdsGhnkwrTXEWHR?e=pkNuQG
|
|
|
Re: The correct use of trackRef under sectionTT [message #2376 is a reply to message #2336] |
Mon, 09 March 2020 12:20 ![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 Torben,
> For a macroscopic model with only a main track with or without station tracks there is no alternate path to choose from. So, do not use <sectionTT> as it does not give any added value.
I don't agree. We still use <sectionTT> in a macroscopic model
- to encode the line in case of parallel lines (attribute @lineRef),
- to encode the line-side track in case of double-track lines (sub-element <trackRef>),
- to encode the run times (sub-element <runTimes>),
- to encode the run time supplement (attribute @percentageSupplement)
and more.
> In the seldom case that there exist two lines between two
> OCP's with no intermediate OCP in between...
This is by far not a seldom case in Germany and other countries. How many examples should I describe...? ;-)
> ...unambiguous definition of the path of a sectionTT...
I am afraid I doubt that there will be an unambiguous definition by railML in general since we've learned the definition of what is a "station" is highly controversial. May be we can clarify it by some use cases of railML, ok.
For instance, in your example sketch, I see the following possibilities:
a) No description of the route in station B in a macroscopic model (as you mentioned it),
b) Station B is split into several (two) <ocp>s for timetabling,
c) Encode the detailed way through station B by using a route identification at <ocpTT>.@trackInfo.
Solution (b) may sound strange, but this is a very common solution for that problem for instance in Germany and other countries.
I want to point out that, in my opinion,
- <sectionTT>.<trackRef> is only intended to encode the track _between_ stations (<ocp>s) - not the tracks inside stations. That's why it is located at <sectionTT> - everything at <sectionTT> should concern the section between stations (<ocp>s).
- the route inside stations (<ocp>s) must be described, if necessary, by other attributes or elements - for instance <ocpTT>.@trackInfo or some more precise, standardised solution of future railML.
Best regards,
Dirk.
|
|
|