Dev:Connection between tracks

From wiki.railML.org
Jump to: navigation, search

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

  • modelling of a switch
  • 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.

Modelling of a Switch

A switch is a connection element, which hierarchically belongs to exactly one track. However, it is connected to one more track in form of the switch's branch. The switch is situated along the track via its relative position given by the pos attribute. Following the principle of a classic node-edge-model, the switch should only be situated in the track begin (pos = 0) or in the track end (pos = length of track). Thus, a switch always marks a change of track, no matter if the main or the branching way is chosen. Additionally, it is useful to connect the switch element with that track, from which the switch can be travelled facing (dt. "spitz").

Connections at a Switch

The main track or "through track" (dt. "Stammgleis") of the switch is modelled as a connection element in the begin or end of the track, which refers to a connection element in the begin or end of another track. So, the main track is not included in the list of connections within the switch element, but only the branching tracks are modelled there. Most switches have exactly one branching track, but in case of a three-way-switch, there would be two connection elements in the switch. Considering the connection's attributes orientation and course there are four different combinations possible:

  • Incoming branch from Left
  • Incoming branch from Right
  • Outgoing branch to the Left
  • Outgoing branch to the Right

Incoming Branch

Example 1: Switch incomingLeft.png

Example 2: Switch incomingRight.png

Example 1 and Example 2 show a switch with an incoming branch track: The switch element is situated in the begin of track 1. The main course of the switch continues with the begin of track 2. Track 3 is connected with the branching course, which is of orientation "incoming" from course "left" or "right" related to the orientation of track 1.

The railML® 2.x source code for example 1 looks like this:

 <tracks>
   <track id="1">
     <trackTopology>
       <trackBegin id="tB1">
         <connection id="c12" ref="c21"/>
       </trackBegin>
       <trackEnd id="tE1"> ... </trackEnd>
       <connections>
         <switch id="s1" pos="0">
           <connection id="c13" ref="c31" orientation="incoming" course="left"/>
         </switch>
       </connections>
     </trackTopology>
   </track>
   <track id="2">
     <trackTopology>
       <trackBegin id="tB2">
         <connection id="c21" ref="c12"/>
       </trackBegin>
       <trackEnd id="tE2"> ... </trackEnd>
     </trackTopology>
   </track>
   <track id="3">
     <trackTopology>
       <trackBegin id="tB3">
         <connection id="c31" ref="c13"/>
       </trackBegin>
       <trackEnd id="tE3"> ... </trackEnd>
     </trackTopology>
   </track>
 </tracks>

Outgoing Branch

Example 3: Switch outgoingLeft.png

Example 4: Switch outgoingRight.png

Example 3 and Example 4 depict a switch with an outgoing branch track: The switch element is situated in the end of track 1. From there, the main course of the switch continues with the begin of track 2. Track 3 is connected with the branching track, which is of orientation "outgoing" to the "left" or to the "right" related to the orientation of track 1.

The railML® 2.x source code for example 3 looks like this (where track 1 is supposed to have a length of 999 meters):

 <tracks>
   <track id="1">
     <trackTopology>
       <trackBegin id="tB1"> ... </trackBegin>
       <trackEnd id="tE1">
         <connection id="c12" ref="c21"/>
       </trackEnd>
       <connections>
         <switch id="s1" pos="999">
           <connection id="c13" ref="c31" orientation="outgoing" course="left"/>
         </switch>
       </connections>
     </trackTopology>
   </track>
   <track id="2">
     <trackTopology>
       <trackBegin id="tB2">
         <connection id="c21" ref="c12"/>
       </trackBegin>
       <trackEnd id="tE2"> ... </trackEnd>
     </trackTopology>
   </track>
   <track id="3">
     <trackTopology>
       <trackBegin id="tB3">
         <connection id="c31" ref="c13"/>
       </trackBegin>
       <trackEnd id="tE3"> ... </trackEnd>
     </trackTopology>
   </track>
 </tracks>

Simple Connection Between Two Tracks

Imagine the following scenario, in which the tracks T1 and T2 shall be directly connected with each other (external link; 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 (external link; 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 (external link; 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!