Dev:Connection between tracks: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
m (Template deployed)
Line 181: Line 181:
Therefore, the semantics and the usage of <track> elements has been widened. Tracks can now be used more "intuitively", can be joined directly together, can be used for crossovers, sidings, etc.
Therefore, the semantics and the usage of <track> elements has been widened. Tracks can now be used more "intuitively", can be joined directly together, can be used for crossovers, sidings, etc.


As a consequence, the attribute ''branchDist'' is now '''deprecated''' and is only kept for compatibility reasons. It will be removed in a future version of RailML. Please do not use ''branchDist'' anymore in your implementations!
As a consequence, the attribute ''branchDist'' is {{Depr|2.0}} and is only kept for compatibility reasons. It will be removed in a future version of RailML. Please do not use ''branchDist'' anymore in your implementations!

Revision as of 12:17, 22 November 2011

Introduction

People just starting out with RailML are often puzzled how to store connections between track elements and how to model a simple switch. This page will show some examples and give some explanations on the preferred solutions for these problems. In detail, this page will show

  • the connection between two subsequent tracks
  • the insertion of a switch somewhere on a track
  • a crossover between two parallel tracks

along with fragmentary XML code snippets. In all code fragments, non relevant attributes or elements will be omitted for more clarity. Thus, the the code shown here cannot be directly validated against the XSDs.

Simple Connection Between Two Tracks

Imagine the following scenario, in which the tracks T1 and T2 shall be directly connected with each other (click for graphic). The labels shown the figure have the following meaning:

  • T1 = Track 1
  • T2 = Track 2
  • TE1 = trackEnd of track 1
  • TB2 = trackBegin of track 2
  • C1 = Connection 1 from TE1 to TB2
  • C2 = Connection 2 from TB2 to TE1

The relevant XML code for this example would be:

 <tracks>
   <track id="T1">
     <trackTopology>
       <trackBegin id="TB1"> ... </trackBegin>
       <trackEnd id="TE1">
         <connection id="C1" ref="C2"/>
       </trackEnd>
     </trackTopology>
   </track>
   <track id="T2">
     <trackTopology>
       <trackBegin id="TB2">
         <connection id="C2" ref="C1"/>
       </trackBegin>
       <trackEnd id="TE2"> ... </trackEnd>
     </trackTopology>
   </track>
 </tracks>

The code shows how the end of T1 is connected to the begin of T2 and vice versa. You certainly have noticed that this is a kind of "double linking" which is a possible source for inconsistencies. Therefore, it is crucial to all your XML files that the symmetry between two associated connections is kept. This constraint cannot be automatically checked by XML validators since it is a rule of RailML (the "application layer" on top of XML) and not of XML itself.

Insertion of a Switch

Here a situation is shown in which a second track is connected via a switch somewhere on another track (click for graphic). The labels shown the figure have the following meaning:

  • T1 = track 1
  • T2 = track 2
  • SW1 = switch 1 on track 1
  • TB2 = trackBegin of track 2
  • C1 = Connection 1 from SW1 to TB2
  • C2 = Connection 2 from TB2 to SW1

The relevant XML code for this example would be:

 <tracks>
   <track id="T1">
     <trackTopology>
       <trackBegin> ... </trackBegin>
       <trackEnd/> ... </trackEnd>
       <connections>
         <switch id="SW1" pos="1234">
           <connection id="C1" ref="C2"/>
         </switch>
       </connections>
     </trackTopology>
   </track>
   <track id="T2">
     <trackTopology>
       <trackBegin id="TB2">
         <connection id="C2" ref="C1"/>
       </trackBegin>
       <trackEnd id="TE2"> ... </trackEnd>
     </trackTopology>
   </track>
 </tracks>

Basically, the code shown here works exactly as above for the straight connection of two tracks. The only difference: one of the <connection> tags for the joint has moved from a <trackBegin> / <trackEnd> to a <switch> element. Additionally, the <connection> tag for a switch offers an extended set of attributes to define e. g. the direction of the branch (incoming, outgoing). So the connection element for a switch is slightly more powerful than the connection element of a trackBegin or trackEnd.

Just as above, the connection is made a double link and it is up to the user to care for its consistency.

Crossover Between Two Parallel Tracks

This example shows a typical crossover between two parallel tracks (click for graphic). The figure shows two slightly different versions of how the problem can be solved. But first of all a legend for the labels:

  • T1, T2, T3, T3a, T3b = track identifiers
  • SW1, SW2 = switch identifiers

In contrast to the examples above, the connection identifiers (C1, C2, ...) are not shown here. I guess you already understand the pattern... Oh, and to avoid misunderstandings: the pairs of two adjacent blue circles in the figure do not represent axle counters (as they do in some schematic track layouts). They just show the switches and track nodes where the connection elements are attached.

Variant 1

This is the most obvious implementation. On both tracks, a switch is defined and the interconnection is done via a separate track T3. This approach is more or less a variation of the simple-switch-example above. SW1 and T3 are connected just like in the other example. While the other example did not define the end of the connected track (T2 above, T3 here), we know link the end of T3 to SW2. The principle is identical to the link between SW1 and T3. This concept yields the following code:

 <tracks>
   <track id="T1">
     <trackTopology>
       <trackBegin> ... </trackBegin>
       <trackEnd/> ... </trackEnd>
       <connections>
         <switch id="SW1" pos="1234">
           <connection id="C1" ref="C2"/>
         </switch>
       </connections>
     </trackTopology>
   </track>
   <track id="T2">
     <trackTopology>
       <trackBegin> ... </trackBegin>
       <trackEnd/> ... </trackEnd>
       <connections>
         <switch id="SW2" pos="1294">
           <connection id="C3" ref="C4"/>
         </switch>
       </connections>
     </trackTopology>
   </track>
   <track id="T3">
     <trackTopology>
       <trackBegin id="TB2">
         <connection id="C2" ref="C1"/>
       </trackBegin>
       <trackEnd id="TB2">
         <connection id="C4" ref="C3"/>
       </trackEnd>
     </trackTopology>
   </track>
 </tracks>

Variant 2

In case the two simple switches which make up the crossover shall be modelled separately, it is of course possible to split the joining track T3 into two tracks (e. g. T3a and T3b). Both tracks are directly connected as shown in the first example at the top of this page.

This slightly more complex implementation of a crossover offers no specific advantages from RailML's point of view. But depending on the source data model when exporting to RailML it might be easier to export every simple switch separately (T3a, T3b) instead of creating algorithms for joining the "sub-branches" of every switch into one single track (T3a + T3b --> T3).

A Note on History

In the course of time, the semantics behind RailML's data model changed. RailML started with a <track> being one of possibly multiple tracks of a line. E. g. a double-track line would have been modeled with just two <track> elements:

 o---------T1----------o
 
 
 o---------T2----------o

Direct joints of tracks like

 o---T1---oo---T2---o
 
 
 o--------T3--------o

or the usage of track elements in crossovers like

 o--------T1--------x-----------o
                     o
                      \
                      T3
                        \
                         o
 o--------T2--------------x-----o

were not foreseen.


This has special implications for crossovers. Since originally no separate, connecting track element was allowed, a special attribute called branchDist denoted the length of the connection:

 o--------T1--------x-----------o
                     
                     \ 
            (branchDist = 60 m); no <track>-element here!
                       \  
                         
 o--------T2--------------x-----o

But this special attribute only solved the problem of the missing length information. Other points were still open, especially the modeling of elements along the connecting track (e. g. axle counters, signals, balises). So we soon found out that handling a "connection track" different than an "ordinary track" made no sense and just causes a lot of special cases, exceptions and headache.

Therefore, the semantics and the usage of <track> elements has been widened. Tracks can now be used more "intuitively", can be joined directly together, can be used for crossovers, sidings, etc.

As a consequence, the attribute branchDist is (deprecated with version 2.0) and is only kept for compatibility reasons. It will be removed in a future version of RailML. Please do not use branchDist anymore in your implementations!