Dev:Connection between tracks

From railML 2 Wiki
Jump to navigation Jump to 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
  • a crossing of two tracks (simple crossing, simple switch crossing, double switch crossing)

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, except for crossings, 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

Consider examples in which the orientation of the switch is incoming. The "orientation" attribute means the orientation of the switch element relative to the general track direction (aligned with increasing mileage). "Incoming orientation" stands for the case when a track is merging into the principal track, tracks are converging relative to the direction.

Here it is possible that the course of the switch is either "right" or "left". The course of the switch means the relative direction of a converging/diverging track connection facilitated by a switch. The course is always defined relative to the switch element (i.e. to stock rail), regardless of global track direction. The below figure demonstrates the case of the "left" course which means that a switch track is merging from the left or is diverging leftward from the principal track. The arrows denote the direction of the railway track. The green colour highlights the main course of the switch. The orange one highlights the branching course.

Switch incomingLeft.png

The below figure demonstrates the case of the "right" course which means that a switch track is merging from the right or is diverging rightward from the principal track.

Switch incomingRight.png

The switch element is situated at the beginning of track 1. The main course of the switch continues with the beginning of track 2. Track 3 is connected with the branching course, which is of orientation "incoming" from the course "left" or "right" related to the orientation of track 1.

The railML® 2.x source code for the case of "Incoming branch from Left" 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 1

Consider examples in which the orientation of the switch is "outgoing" which stands for the case when a track is splitting out from the principal track, tracks are diverging relative to the direction. Here it is also possible the course of the switch is either "right" or "left". The below figure demonstrates the case of the "left" course for the "outgoing" orientation.

Switch outgoingLeft.png

The below figure demonstrates the case of the "right" course for the "outgoing" orientation.

Switch outgoingRight.png

The switch element is situated at the end of track 1. From there, the main course of the switch continues with the beginning 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 the example of "Outgoing branch to the Left" 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" pos="999">
          <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>


Example 2

be aware of additional constraints
implicit possibility
be aware of additional constraints
  <tracks>
    <track id="tr01">
      <trackTopology>
        <trackBegin id="tb01" pos="0">
          <connection id="ctb01" ref="cte02"/>
        </trackBegin>
        <trackEnd id="te01" pos="999">
          <connection id="cte01" ref="ctb03"/>
        </trackEnd>
        <connections>
          <switch id="sw06" pos="0">
            <connection id="cx01" ref="ctb04" orientation="outgoing" course="left"/> 
            <!-- @passable="true" by default. Here through track 2 changing direction of train movement-->
          </switch>
        <connections>
          <switch id="sw07" pos="999">
            <connection id="cx02" ref="ctb05" orientation="outgoing" course="left"/> 
            <!-- @passable="true" by default. Here right away-->
          </switch>
        </connections>
      </trackTopology>
    </track>
    <track id="tr02">
      <trackTopology>
        <trackBegin id="tb02"> ... </trackBegin>
        <trackEnd id="te02">
          <connection id="cte02" ref="ctb01"/>
        </trackEnd>
      </trackTopology>
    </track>
    <track id="3">
      <trackTopology>
        <trackBegin id="tb03">
          <connection id="ctb03" ref="cte01"/> 
        </trackBegin>
        <trackEnd id="te03"> ... </trackEnd>
      </trackTopology>
    </track>
    <track id="4">
      <trackTopology>
        <trackBegin id="tb04">
          <connection id="ctb04" ref="cx01"/>
        </trackBegin>
        <trackEnd id="te04"> ... </trackEnd>
      </trackTopology>
    </track>
    <track id="5">
      <trackTopology>
        <trackBegin id="tb05">
          <connection id="ctb05" ref="cx02"/>
        </trackBegin>
        <trackEnd id="te05"> ... </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.

Simple connection

The labels shown in 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|comment=click for graphic.

Insertion of a switch

The labels shown in 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|comment=click for graphic.

Crossover

The figure shows one of 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...

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 the railML® 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).

Crossing examples

In this section, we provide the way to model railway crossing. It is based on the previous examples of the switch and crossover yet has some differences, because crossing allows for linking itself with two railway tracks.

Double Switch Crossing

Example of a Double Switch Crossing Scenario 1

DoubleSwitchCrossingScenario1

In this scenario crossing allows the train to go:

- two ways straight across track 1;

- from track 2 to track 3 because they belong to the same crossing and the first is incoming while the other is outgoing or vice versa;

- from track 1 to track 2 through cx01, cte02 connections and crossing x01;

- from track 1 to track 3 through cx02, ct03 connections and crossing x01.

“Double switch crossing scenario 1” is modelled the same way as the single switch but has two connections. That is because the crossing has slip switches that allow going two ways. In that, the slip switch is connected to track 2 and track 3.

See sections “simple connection” and “insertion of a switch” of “Dev:Connection between tracks” page for reference.

The navigability of tr02 and tr03 derived is derived from @orientation of the <connection>'s at the <crossing>. Meaning that one of the crossing tracks is modelled as a combination “incoming left” connection and the “outgoing right” one. See sections “Incoming Branch” and “Incoming Branch” of “Dev:Connection between tracks” page for reference.

Below is the source code of the example.

<?xml version="1.1" encoding="UTF-8"?>
<railml xmlns="https://www.railml.org/schemas/2021" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://www.railml.org/schemas/2021 https://schemas.railml.org/2021/railML-2.5/schema/railML.xsd">
  <infrastructure id="Double_Switch_Crossing_scenario_1">
    <!-- 
    Woraus leitet sich hier die Navigability von tr02 und tr03 ab? Aus der @orientation der <connection>'s am <crossing>!

    From what is the navigability of tr02 and tr03 derived here? From the @orientation of the <connection>'s at the <crossing>!
    -->
    <tracks>
      <track id="tr01">
        <trackTopology>
          <trackBegin id="tb01" pos="0">
            <openEnd id="oe01"></openEnd>
          </trackBegin>
          <trackEnd id="te01" pos="100">
            <openEnd id="oe02"></openEnd>
          </trackEnd>
          <connections>
            <crossing id="x01" pos="50" type="doubleSwitchCrossing">
              <connection id="cx01" ref="cte02" orientation="incoming" course="left"></connection>
              <connection id="cx02" ref="ctb03" orientation="outgoing" course="right"></connection>
            </crossing>
          </connections>
        </trackTopology>
      </track>
      <track id="tr02">
        <trackTopology>
          <trackBegin id="tb02" pos="0">
            <openEnd id="oe03"></openEnd>
          </trackBegin>
          <trackEnd id="te02" pos="40">
            <connection id="cte02" ref="cx01"></connection>
          </trackEnd>
        </trackTopology>
      </track>
      <track id="tr03">
        <trackTopology>
          <trackBegin id="tb03" pos="0">
            <connection id="ctb03" ref="cx02"></connection>
          </trackBegin>
          <trackEnd id="te03" pos="60">
            <openEnd id="oe04"></openEnd>
          </trackEnd>
        </trackTopology>
      </track>
    </tracks>
  </infrastructure>
</railml>

Example of a Double Switch Crossing Scenario 2
be aware of additional constraints

DoubleSwitchCrossingScenario2
be aware of additional constraints

In this scenario crossing allows the train to go:

- two ways straight across track 1 through cte01, ctb02 connections;

- from track 2 to track 3 because they belong to the same crossing and the first is incoming while the other is outgoing or vice versa;

- from track 1 to track 2 through cx01, cte02 connections and crossing x01;

- from track 1 to track 3 through cx02, ct03 connections and crossing x01.

“Double switch crossing scenario 1” is modelled as a combination of a switch and a simple connection. The difference is that the switch has two connections. That is because the crossing has slip switches that allow going two ways. In that, the slip switch is connected to track 2 and track 3.

See sections “simple connection” and “insertion of a switch” of “Dev:Connection between tracks” page for reference.

The navigability of tr02 and tr03 derived is derived from the @orientation of the <connection>'s at the <crossing>. Meaning that one of the tracks of crossing is modelled as a combination “incoming left” connection and the “outgoing right” one. See sections “Incoming Branch” and “Incoming Branch” of the “Dev:Connection between tracks” page for reference.

Below is the source code of the example.

<?xml version="1.1" encoding="UTF-8"?>
<railml xmlns="https://www.railml.org/schemas/2021" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://www.railml.org/schemas/2021 https://schemas.railml.org/2021/railML-2.5/schema/railML.xsd">
  <infrastructure id="Double_Switch_Crossing_scenario_2">
    <!-- 
    Woraus leitet sich hier die Navigability von tr03 und tr04 ab? Aus der @orientation der <connection>'s am <crossing>!

    From what is the navigability of tr03 and tr04 derived here? From the @orientation of the <connection>'s at the <crossing>!
    -->
    <tracks>
      <track id="tr01">
        <trackTopology>
          <trackBegin id="tb01" pos="0">
            <openEnd id="oe01"></openEnd>
          </trackBegin>
          <trackEnd id="te01" pos="50">
            <connection id="cte01" ref="ctb02"></connection>
          </trackEnd>
          <connections>
            <crossing id="x01" pos="50" type="doubleSwitchCrossing">
              <connection id="cx01" ref="cte03" orientation="incoming" course="left"></connection>
              <!--@passable="true" by default. Here through tr02 or tr04 changing direction of a train movement-->
 
              <connection id="cx02" ref="ctb04" orientation="outgoing" course="right"></connection>
              <!--@passable="true" by default. Here right away -->
            </crossing>
          </connections>
        </trackTopology>
      </track>
      <track id="tr02">
        <trackTopology>
          <trackBegin id="tb02" pos="0">
            <connection id="ctb02" ref="cte01"></connection>
          </trackBegin>
          <trackEnd id="te02" pos="50">
            <openEnd id="oe02"></openEnd>
          </trackEnd>
        </trackTopology>
      </track>
      <track id="tr03">
        <trackTopology>
          <trackBegin id="tb03" pos="0">
            <openEnd id="oe03"></openEnd>
          </trackBegin>
          <trackEnd id="te03" pos="40">
            <connection id="cte03" ref="cx01"></connection>
          </trackEnd>
        </trackTopology>
      </track>
      <track id="tr04">
        <trackTopology>
          <trackBegin id="tb04" pos="0">
            <connection id="ctb04" ref="cx02"></connection>
          </trackBegin>
          <trackEnd id="te04" pos="60">
            <openEnd id="oe04"></openEnd>
          </trackEnd>
        </trackTopology>
      </track>
    </tracks>
  </infrastructure>
</railml>

Example of a Double Switch Crossing Scenario 3

DoubleSwitchCrossingScenario3

In this scenario crossing allows the train to go:

- two ways straight across track 1;

- two ways straight across track 2;

- from track 1 to track 2 through cx01, cx03, through cx02, cx04 connections and x01, x02 crossings.

“Double switch crossing scenario 1” is modelled the same way as the crossover but the switches have two connections and there is no track between them. That is because the crossing has slip switches that allow going two ways. In that the slip switch is connected to track 2 and track 3.

See sections “simple connection” and “insertion of a switch” of the “Dev:Connection between tracks” page for reference.

The navigability of tr02 and tr03 derived is derived from @orientation of the <connection>'s at the <crossing>. Meaning that one of the tracks of crossing is modelled as a combination “incoming left” connection and the “outgoing left” one. See sections “Incoming Branch” and “Incoming Branch” of the “Dev:Connection between tracks” page for reference.

In order to communicate that the two defined <crossing> elements are the same real crossing, it is important that the descriptive attributes such as @type or @orientation, @course or @passable do not contradict each other.

It is assumed that if all connections at 2 crossings reference each other, then it is only a single real crossing.

Below is source code of the example.

<?xml version="1.1" encoding="UTF-8"?>
<railml xmlns="https://www.railml.org/schemas/2021" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://www.railml.org/schemas/2021 https://schemas.railml.org/2021/railML-2.5/schema/railML.xsd">
  <infrastructure id="Double_Switch_Crossing_scenario_3">
    <!--
      Um zu kommunizieren, dass es sich bei den beiden definierten <crossing> elementen um die selbe reale Kreuzung handelt ist, es wichtig, dass sich die beschreibenden Attribute wie @type bzw. @orientation, @course oder @passable nicht wiedersprechen.
      Es wird davon ausgegangen, dass wenn sich an 2 crossings alle connections gegenseitig referenzieren, dass es sich dann nur um eine einzige reale Kreuzung handelt.

      In order to communicate that the two defined <crossing> elements are the same real crossing, it is important that the descriptive attributes such as @type or @orientation, @course or @passable do not contradict each other.
      It is assumed that if all connections at 2 crossings reference each other, then it is only a single real crossing.
    -->
    <tracks>
      <track id="tr01">
        <trackTopology>
          <trackBegin id="tb01" pos="0">
            <openEnd id="oe01"></openEnd>
          </trackBegin>
          <trackEnd id="te01" pos="100">
            <openEnd id="oe02"></openEnd>
          </trackEnd>
          <connections>
            <crossing id="x01" pos="50" type="doubleSwitchCrossing">
              <connection id="cx01" ref="cx03" orientation="incoming" course="left"></connection>
              <connection id="cx02" ref="cx04" orientation="outgoing" course="right"></connection>
            </crossing>
          </connections>
        </trackTopology>
      </track>
      <track id="tr02">
        <trackTopology>
          <trackBegin id="tb02" pos="0">
            <openEnd id="oe03"></openEnd>
          </trackBegin>
          <trackEnd id="te02" pos="100">
            <openEnd id="oe04"></openEnd>
          </trackEnd>
          <connections>
            <crossing id="x02" pos="40" type="doubleSwitchCrossing">
              <connection id="cx03" ref="cx01" orientation="outgoing" course="left"></connection>
              <connection id="cx04" ref="cx02" orientation="incoming" course="right"></connection>
            </crossing>
          </connections>
        </trackTopology>
      </track>
    </tracks>
  </infrastructure>
</railml>

Simple Switch Crossing

Example of a Simple Switch Crossing Scenario 1

SimpleSwitchCrossingScenario1

In this scenario crossing allows the train to go:

- two ways straight across track 1;

- from track 2 to track 3 because they belong to the same crossing and the first is incoming while the other is outgoing or vice versa;

- from track 1 to track 3 through cx02, ct03 connections and crossing x01.

“Simple switch crossing scenario 1” is modelled the same way as “Double switch crossing scenario 1” but has a false passable attribute because it has a single slip switch and allows going in 6 directions only (Double switch crossing allows going in 8 directions).

Below is the source code of the example.

<?xml version="1.1" encoding="UTF-8"?>
<railml xmlns="https://www.railml.org/schemas/2021" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://www.railml.org/schemas/2021 https://schemas.railml.org/2021/railML-2.5/schema/railML.xsd">
  <infrastructure id="Simple_Switch_Crossing_scenario_1">
    <!-- 
    Woraus leitet sich hier die Navigability von tr02 und tr03 ab? Aus der @orientation der <connection>'s am <crossing>!

    From what is the navigability of tr02 and tr03 derived here? From the @orientation of the <connection>'s at the <crossing>!
    -->
    <tracks>
      <track id="tr01">
        <trackTopology>
          <trackBegin id="tb01" pos="0">
            <openEnd id="oe01"></openEnd>
          </trackBegin>
          <trackEnd id="te01" pos="100">
            <openEnd id="oe02"></openEnd>
          </trackEnd>
          <connections>
            <crossing id="x01" pos="50" type="simpleSwitchCrossing">
              <connection id="cx01" ref="cte02" orientation="incoming" course="left" passable="false"></connection>
              <connection id="cx02" ref="ctb03" orientation="outgoing" course="right"></connection>
            </crossing>
          </connections>
        </trackTopology>
      </track>
      <track id="tr02">
        <trackTopology>
          <trackBegin id="tb02" pos="0">
            <openEnd id="oe03"></openEnd>
          </trackBegin>
          <trackEnd id="te02" pos="40">
            <connection id="cte02" ref="cx01"></connection>
          </trackEnd>
        </trackTopology>
      </track>
      <track id="tr03">
        <trackTopology>
          <trackBegin id="tb03" pos="0">
            <connection id="ctb03" ref="cx02"></connection>
          </trackBegin>
          <trackEnd id="te03" pos="60">
            <openEnd id="oe04"></openEnd>
          </trackEnd>
        </trackTopology>
      </track>
    </tracks>
  </infrastructure>
</railml>

Example of a Simple Switch Crossing Scenario 2
be aware of additional constraints

SimpleSwitchCrossingScenario2
be aware of additional constraints

In this scenario crossing allows the train to go:

- two ways straight across track 1 through cte01, ctb02 connections;

- from track 2 to track 3 because they belong to the same crossing and the first is incoming while the other is outgoing or vice versa;

- from track 1 to track 3 through cx02, ct03 connections and crossing x01.

“Simple switch crossing scenario 2” is modelled the same way as “Double switch crossing scenario 2” but has a false passable attribute because it has a single slip switch and allows going in 6 directions only (Double switch crossing allows going in 8 directions).

Below is the source code of the example.

<?xml version="1.1" encoding="UTF-8"?>
<railml xmlns="https://www.railml.org/schemas/2021" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://www.railml.org/schemas/2021 https://schemas.railml.org/2021/railML-2.5/schema/railML.xsd">
  <infrastructure id="Simple_Switch_Crossing_scenario_2">
    <!-- 
    Woraus leitet sich hier die Navigability von tr03 und tr04 ab? Aus der @orientation der <connection>'s am <crossing>!

    From what is the navigability of tr03 and tr04 derived here? From the @orientation of the <connection>'s at the <crossing>!
    -->
    <tracks>
      <track id="tr01">
        <trackTopology>
          <trackBegin id="tb01" pos="0">
            <openEnd id="oe01"></openEnd>
          </trackBegin>
          <trackEnd id="te01" pos="50">
            <connection id="cte01" ref="ctb02"></connection>
          </trackEnd>
          <connections>
            <crossing id="x01" pos="50" type="simpleSwitchCrossing">
              <connection id="cx01" ref="cte03" orientation="incoming" course="left" passable="false"></connection>
              <!--means you can go from tr01 to tr03 through tr04 changing direction of train movement but not through tr02-->
              <connection id="cx02" ref="ctb04" orientation="outgoing" course="right"></connection>
              <!--@passable="true" by default. Here right away-->
            </crossing>
          </connections>
        </trackTopology>
      </track>
      <track id="tr02">
        <trackTopology>
          <trackBegin id="tb02" pos="0">
            <connection id="ctb02" ref="cte01"></connection>
          </trackBegin>
          <trackEnd id="te02" pos="50">
            <openEnd id="oe02"></openEnd>
          </trackEnd>
        </trackTopology>
      </track>
      <track id="tr03">
        <trackTopology>
          <trackBegin id="tb03" pos="0">
            <openEnd id="oe03"></openEnd>
          </trackBegin>
          <trackEnd id="te03" pos="40">
            <connection id="cte03" ref="cx01"></connection>
          </trackEnd>
        </trackTopology>
      </track>
      <track id="tr04">
        <trackTopology>
          <trackBegin id="tb04" pos="0">
            <connection id="ctb04" ref="cx02"></connection>
          </trackBegin>
          <trackEnd id="te04" pos="60">
            <openEnd id="oe04"></openEnd>
          </trackEnd>
        </trackTopology>
      </track>
    </tracks>
  </infrastructure>
</railml>

Example of a Simple Switch Crossing Scenario 3

SimpleSwitchCrossingScenario3

In this scenario crossing allows the train to go:

- two ways straight across track 1;

- two ways straight across track 2;

- from track 1 to track 2 through through cx02, cx04 connections and x01, x02 crossings.

“Simple switch crossing scenario 3” is modelled the same way as “Double switch crossing scenario 3” but has a false passable attribute because it has a single slip switch and allows going in 6 directions only (Double switch crossing allows going in 8 directions).

Below is the source code of the example.

<?xml version="1.1" encoding="UTF-8"?>
<railml xmlns="https://www.railml.org/schemas/2021" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://www.railml.org/schemas/2021 https://schemas.railml.org/2021/railML-2.5/schema/railML.xsd">
  <infrastructure id="Simple_Switch_Crossing_scenario_3">
    <!--
      Um zu kommunizieren, dass es sich bei den beiden definierten <crossing> elementen um die selbe reale Kreuzung handelt ist, es wichtig, dass sich die beschreibenden Attribute wie @type bzw. @orientation, @course oder @passable nicht wiedersprechen.
      Es wird davon ausgegangen, dass wenn sich an 2 crossings alle connections gegenseitig referenzieren, dass es sich dann nur um eine einzige reale Kreuzung handelt.

      In order to communicate that the two defined <crossing> elements are the same real crossing, it is important that the descriptive attributes such as @type or @orientation, @course or @passable do not contradict each other.
      It is assumed that if all connections at 2 crossings reference each other, then it is only a single real crossing.
    -->
    <tracks>
      <track id="tr01">
        <trackTopology>
          <trackBegin id="tb01" pos="0">
            <openEnd id="oe01"></openEnd>
          </trackBegin>
          <trackEnd id="te01" pos="100">
            <openEnd id="oe02"></openEnd>
          </trackEnd>
          <connections>
            <crossing id="x01" pos="50" type="simpleSwitchCrossing">
              <connection id="cx01" ref="cx03" orientation="incoming" course="left" passable="false"></connection>
              <connection id="cx02" ref="cx04" orientation="outgoing" course="right"></connection>
            </crossing>
          </connections>
        </trackTopology>
      </track>
      <track id="tr02">
        <trackTopology>
          <trackBegin id="tb02" pos="0">
            <openEnd id="oe03"></openEnd>
          </trackBegin>
          <trackEnd id="te02" pos="100">
            <openEnd id="oe04"></openEnd>
          </trackEnd>
          <connections>
            <crossing id="x02" pos="40" type="simpleSwitchCrossing">
              <connection id="cx03" ref="cx01" orientation="outgoing" course="left" passable="false"></connection>
              <connection id="cx04" ref="cx02" orientation="incoming" course="right"></connection>
            </crossing>
          </connections>
        </trackTopology>
      </track>
    </tracks>
  </infrastructure>
</railml>

Simple Crossing

Example of a Simple Crossing Scenario 1

SimpleCrossingScenario1

In this scenario crossing allows the train to go:

- two ways straight across track 1;

- from track 2 to track 3 because they belong to the same crossing and the first is incoming while the other is outgoing or vice versa.

“Simple crossing scenario 1” is modelled the same way as “Simple switch crossing scenario 1” but has another false passable attribute because it doesn’t have slip switches and allows going in 4 directions only (Simple switch crossing allows going in 6 directions).

Below is the source code of the example.

<?xml version="1.1" encoding="UTF-8"?>
<railml xmlns="https://www.railml.org/schemas/2021" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://www.railml.org/schemas/2021 https://schemas.railml.org/2021/railML-2.5/schema/railML.xsd">
  <infrastructure id="Simple_Crossing_scenario_1">
    <!-- 
    Woraus leitet sich hier die Navigability von tr02 und tr03 ab? Aus der @orientation der <connection>'s am <crossing>!

    From what is the navigability of tr02 and tr03 derived here? From the @orientation of the <connection>'s at the <crossing>!
    -->
    <tracks>
      <track id="tr01">
        <trackTopology>
          <trackBegin id="tb01" pos="0">
            <openEnd id="oe01"></openEnd>
          </trackBegin>
          <trackEnd id="te01" pos="100">
            <openEnd id="oe02"></openEnd>
          </trackEnd>
          <connections>
            <crossing id="x01" pos="50" type="simpleCrossing">
              <connection id="cx01" ref="cte02" orientation="incoming" course="left" passable="false"></connection>
              <connection id="cx02" ref="ctb03" orientation="outgoing" course="right" passable="false"></connection>
            </crossing>
          </connections>
        </trackTopology>
      </track>
      <track id="tr02">
        <trackTopology>
          <trackBegin id="tb02" pos="0">
            <openEnd id="oe03"></openEnd>
          </trackBegin>
          <trackEnd id="te02" pos="40">
            <connection id="cte02" ref="cx01"></connection>
          </trackEnd>
        </trackTopology>
      </track>
      <track id="tr03">
        <trackTopology>
          <trackBegin id="tb03" pos="0">
            <connection id="ctb03" ref="cx02"></connection>
          </trackBegin>
          <trackEnd id="te03" pos="60">
            <openEnd id="oe04"></openEnd>
          </trackEnd>
        </trackTopology>
      </track>
    </tracks>
  </infrastructure>
</railml>

Example of a Simple Crossing Scenario 2
be aware of additional constraints

SimpleCrossingScenario2
be aware of additional constraints

In this scenario crossing allows the train to go:

- two ways straight across track 1 through cte01, ctb02 connections;

- from track 2 to track 3 because they belong to the same crossing and the first is incoming while the other is outgoing or vice versa.

“Simple crossing scenario 1” is modelled the same way as “Simple switch crossing scenario 1” but has another false passable attribute because it doesn’t have slip switches and allows going in 4 directions only (Simple switch crossing allows going in 6 directions).

Below is the source code of the example.

<?xml version="1.1" encoding="UTF-8"?>
<railml xmlns="https://www.railml.org/schemas/2021" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://www.railml.org/schemas/2021 https://schemas.railml.org/2021/railML-2.5/schema/railML.xsd">
  <infrastructure id="Simple_Crossing_scenario_2">
    <!-- 
    Woraus leitet sich hier die Navigability von tr03 und tr04 ab? Aus der @orientation der <connection>'s am <crossing>!

    From what is the navigability of tr03 and tr04 derived here? From the @orientation of the <connection>'s at the <crossing>!
    -->
    <tracks>
      <track id="tr01">
        <trackTopology>
          <trackBegin id="tb01" pos="0">
            <openEnd id="oe01"></openEnd>
          </trackBegin>
          <trackEnd id="te01" pos="50">
            <connection id="cte01" ref="ctb02"></connection>
          </trackEnd>
          <connections>
            <crossing id="x01" pos="50" type="simpleCrossing">
              <connection id="cx01" ref="cte03" orientation="incoming" course="left" passable="false"></connection>
              <!--means you cannot go from tr03 to tr02-->
              <connection id="cx02" ref="ctb04" orientation="outgoing" course="right" passable="false"></connection>
            </crossing>
          </connections>
        </trackTopology>
      </track>
      <track id="tr02">
        <trackTopology>
          <trackBegin id="tb02" pos="0">
            <connection id="ctb02" ref="cte01"></connection>
          </trackBegin>
          <trackEnd id="te02" pos="50">
            <openEnd id="oe02"></openEnd>
          </trackEnd>
        </trackTopology>
      </track>
      <track id="tr03">
        <trackTopology>
          <trackBegin id="tb03" pos="0">
            <openEnd id="oe03"></openEnd>
          </trackBegin>
          <trackEnd id="te03" pos="40">
            <connection id="cte03" ref="cx01"></connection>
          </trackEnd>
        </trackTopology>
      </track>
      <track id="tr04">
        <trackTopology>
          <trackBegin id="tb04" pos="0">
            <connection id="ctb04" ref="cx02"></connection>
          </trackBegin>
          <trackEnd id="te04" pos="60">
            <openEnd id="oe04"></openEnd>
          </trackEnd>
        </trackTopology>
      </track>
    </tracks>
  </infrastructure>
</railml>

Example of a Simple Crossing Scenario 3

SimpleCrossingScenario3

In this scenario crossing allows the train to go:

- two ways straight across track 1;

- two ways straight across track 2.

“Simple crossing scenario 1” is modelled the same way as “Simple switch crossing scenario 1” but has another false passable attribute because it doesn’t have slip switches and allows going in 4 directions only (Simple switch crossing allows going in 6 directions).

Below is the source code of the example.

<?xml version="1.1" encoding="UTF-8"?>
<railml xmlns="https://www.railml.org/schemas/2021" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://www.railml.org/schemas/2021 https://schemas.railml.org/2021/railML-2.5/schema/railML.xsd">
  <infrastructure id="Simple_Crossing_scenario_3">
    
    <!--
      Um zu kommunizieren, dass es sich bei den beiden definierten <crossing> elementen um die selbe reale Kreuzung handelt ist, es wichtig, dass sich die beschreibenden Attribute wie @type bzw. @orientation, @course oder @passable nicht wiedersprechen.
      Es wird davon ausgegangen, dass wenn sich an 2 crossings alle connections gegenseitig referenzieren, dass es sich dann nur um eine einzige reale Kreuzung handelt.

      In order to communicate that the two defined <crossing> elements are the same real crossing, it is important that the descriptive attributes such as @type or @orientation, @course or @passable do not contradict each other.
      It is assumed that if all connections at 2 crossings reference each other, then it is only a single real crossing.
    -->
    <tracks>
      <track id="tr01">
        <trackTopology>
          <trackBegin id="tb01" pos="0">
            <openEnd id="oe01"></openEnd>
          </trackBegin>
          <trackEnd id="te01" pos="100">
            <openEnd id="oe02"></openEnd>
          </trackEnd>
          <connections>
            <crossing id="x01" pos="50" type="simpleCrossing">
              <connection id="cx01" ref="cx03" orientation="incoming" course="left" passable="false"></connection>
              <connection id="cx02" ref="cx04" orientation="outgoing" course="right" passable="false"></connection>
            </crossing>
          </connections>
        </trackTopology>
      </track>
      <track id="tr02">
        <trackTopology>
          <trackBegin id="tb02" pos="0">
            <openEnd id="oe03"></openEnd>
          </trackBegin>
          <trackEnd id="te02" pos="100">
            <openEnd id="oe04"></openEnd>
          </trackEnd>
          <connections>
            <crossing id="x02" pos="40">
              <connection id="cx03" ref="cx01" orientation="outgoing" course="left" passable="false"></connection>
              <connection id="cx04" ref="cx02" orientation="incoming" course="right" passable="false"></connection>
            </crossing>
          </connections>
        </trackTopology>
      </track>
    </tracks>
  </infrastructure>
</railml>

A Note on History

In the course of time, the semantics behind the railML® 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!