Dev:Railway switch
Introduction
The purpose of this example is twofold. It shall teach newcomers principles of modelling topologies with railML® 3. As for the proficient users, this tutorial is to provide a common way to describe a railway switch, e.g. for certification purposes.
A switch is a unit of a railway track network used to direct vehicles from one track to another track.
To separate the description of the infrastructure topology from its construction, railML® 3 is based on a connexity graph that is based on the structure of the RailTopoModel®. In the context of the description of a railway switch, this means that the type of railway switch (e.g., ordinary, or inside curved switch, etc.) is specified in the functional layer, while the location and mode of operation are specified in the topological layer. Please refer to “Example data” of railML.org website for an example of a linear positioning system definition. Below code snippet below deliberately misses these for the sake of space reasons (this section is already very-very long).
1 <?xml version="1.0" encoding="UTF-8"?> 2 <railML xmlns="https://www.railml.org/schemas/3.1" 3 xmlns:dc="http://purl.org/dc/elements/1.1/" 4 xmlns:gml="http://www.opengis.net/gml/3.2/" 5 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 6 xsi:schemaLocation="https://www.railml.org/schemas/3.1 https://www.railml.org/schemas/3.1/railml3.xsd" 7 version="3.1"> 8 <infrastructure id="is_01"> 9 <topology> 10 <netElements> 11 <netElement id="ne_b01" 12 length="500.0"> 13 <associatedPositioningSystem id="ne_b01_aps01"> 14 <intrinsicCoordinate id="ne_b01_aps01_ic01" 15 intrinsicCoord="0"> 16 <linearCoordinate positioningSystemRef="lps01" 17 measure="4500.0"/> 18 </intrinsicCoordinate> 19 <intrinsicCoordinate id="ne_b01_aps01_ic02" 20 intrinsicCoord="1"> 21 <linearCoordinate positioningSystemRef="lps01" 22 measure="5000.0"/> 23 </intrinsicCoordinate> 24 </associatedPositioningSystem> 25 </netElement> 26 <netElement id="ne_b03" 27 length="200.0"> 28 <associatedPositioningSystem id="ne_b03_aps01"> 29 <intrinsicCoordinate id="ne_b03_aps01_ic01" 30 intrinsicCoord="0"> 31 <linearCoordinate positioningSystemRef="lps01" 32 measure="4300.0"/> 33 </intrinsicCoordinate> 34 <intrinsicCoordinate id="ne_b03_aps01_ic02" 35 intrinsicCoord="1"> 36 <linearCoordinate positioningSystemRef="lps01" 37 measure="4500.0"/> 38 </intrinsicCoordinate> 39 </associatedPositioningSystem> 40 </netElement> 41 <netElement id="ne_b04" 42 length="50.0"> 43 <associatedPositioningSystem id="ne_b04_aps01"> 44 <intrinsicCoordinate id="ne_b04_aps01_ic01" 45 intrinsicCoord="0"> 46 <linearCoordinate positioningSystemRef="lps01" 47 measure="4500.0"/> 48 </intrinsicCoordinate> 49 <intrinsicCoordinate id="ne_b04_aps01_ic02" 50 intrinsicCoord="1"> 51 <linearCoordinate positioningSystemRef="lps01" 52 measure="4550.0"/> 53 </intrinsicCoordinate> 54 </associatedPositioningSystem> 55 </netElement> 56 </netElements> 57 <netRelations> 58 <netRelation id="nr_b01b03" 59 positionOnA="0" 60 positionOnB="1" 61 navigability="Both"> 62 <elementA ref="ne_b01"/> 63 <elementB ref="ne_b03"/> 64 </netRelation> 65 <netRelation id="nr_b01b04" 66 positionOnA="0" 67 positionOnB="0" 68 navigability="None"> 69 <elementA ref="ne_b01"/> 70 <elementB ref="ne_b04"/> 71 </netRelation> 72 <netRelation id="nr_b03b04" 73 positionOnA="1" 74 positionOnB="0" 75 navigability="Both"> 76 <elementA ref="ne_b03"/> 77 <elementB ref="ne_b04"/> 78 </netRelation> 79 </netRelations> 80 <networks> 82 <network id="nw01"> 83 <level id="lv0" 84 descriptionLevel="Micro"> 85 <networkResource ref="ne_b01"/> 86 <networkResource ref="ne_b03"/> 87 <networkResource ref="ne_b04"/> 88 <networkResource ref="nr_b01b03"/> 89 <networkResource ref="nr_b01b04"/> 90 <networkResource ref="nr_b03b04"/> 91 </level> 92 </network> 93 </networks> 94 </topology> 95 <functionalInfrastructure> 96 <switchesIS> 97 <switchIS id="swi02" 98 continueCourse="left" 99 branchCourse="right" 100 type="ordinarySwitch"> 101 <name name="69W03" 102 language="en"/> 103 <spotLocation id="swi02_sloc01" 104 netElementRef="ne_b03" 105 applicationDirection="normal" 106 pos="200.0"> 107 <linearCoordinate positioningSystemRef="lps01" 108 measure="4.500"/> 109 </spotLocation> 110 <leftBranch netRelationRef="nr_b01b03" 111 branchingSpeed="80" 112 joiningSpeed="80" 113 radius="0"/> 114 <rightBranch netRelationRef="nr_b03b04" 115 branchingSpeed="40" 116 joiningSpeed="40" 117 radius="300"/> 118 </switchIS> 119 </switchesIS> 120 <tracks> 121 <track id="trc03" 122 type="mainTrack"> 123 <linearLocation id="trc03_lloc01" 124 applicationDirection="both"> 125 <associatedNetElement netElementRef="ne_b03" 126 keepsOrientation="true" 127 posBegin="0.0" 128 posEnd="200.0"> 129 </associatedNetElement> 130 </linearLocation> 131 <trackEnd ref="swi02"/> 132 <length value="200.0" 133 type="physical"/> 134 </track> 135 <track id="trc04" 136 type="mainTrack"> 137 <name name="2" 138 language="en"/> 139 <linearLocation id="trc04_lloc01" 140 applicationDirection="both"> 141 <associatedNetElement netElementRef="ne_b01" 142 keepsOrientation="true" 143 posBegin="0.0" 144 posEnd="500.0"> 145 </associatedNetElement> 146 </linearLocation> 147 <trackBegin ref="swi02"/> 148 <length type="physical" 149 value="500.0"/> 150 </track> 151 <track id="trc07" 152 type="connectingTrack"> 153 <linearLocation id="trc07_lloc01" 154 applicationDirection="both"> 155 <associatedNetElement netElementRef="ne_b04" 156 keepsOrientation="true" 157 posBegin="0.0" 158 posEnd="50.0"> 159 </associatedNetElement> 160 </linearLocation> 161 <trackBegin ref="swi02"/> 162 <length value="50.0" 163 type="physical"/> 164 </track> 165 </tracks> 166 </functionalInfrastructure> 167</infrastructure> 168</railML>
Topological layer of a switch
To describe the railway switch at the topological level, at least three elements must be defined (ellipses). The “branching” course needs to be described, from track 3 to track 7 in the example and the “continuing” direction needs to be modelled, from track 3 to track 4 in the example. On a topological level this description is performed using <netElement> (lines 10-56 of the listing). These elements are linked by relations (Figure 1: green and red circles; lines 57-80 of the listing).
In railML® 3, the mechanism for being able to travel from one element to another is called connexity representation and is implemented using relations with a navigability attribute (in the The RailTopoModel® wiki). The condensed relations matrix for this case is presented in Table.
| 3 | 4 | 7 | |
|---|---|---|---|
| 3 | + | + | |
| 4 | + | - | |
| 7 | + | - |
In the table, pluses are navigable relations (e.g., line 61 of the listing). The train can go through the railway switch in a “branching” direction ‒ from track 3 to track 7 ‒ and in “continuing” direction ‒ from track 3 to track 4. In this case, an ordinary switch is described, so the @navigability attribute is set to “both”. In other cases where only unidirectional travel is allowed the other enumeration values “AB” and “BA” may be used to describe the permitted orientation of travel.
To represent the impossibility to go from track 4 to track 7 directly, non-navigable relations (attribute @navigability, line 68 of the listing) are used ‒ they are represented as minuses in Table 1.
Functional layer of a switch
The @continueCourse and @branchCourse attributes represent the direction of movement through the railway switch (Figure 2, line 98 of the listing). Please note that two directions are present on the figure. Application direction is not relevant for specifying the direction using @continueCourse and @branchCourse. The directions are always meant looking from switch beginning to switch end. However, the application direction is imperative for understanding the orientation of a switch.
The description of all cases is presented in Table 2. The case of Figure 2 is a). See the changes in source code below.
Table 2 Direction of the railway switch construction in railML® 3
| Case | @continueCourse | @branchCourse | @applicationDirection |
|---|---|---|---|
| a | left | right | normal |
| b | left | right | reverse |
| c | right | left | normal |
| d | right | left | reverse |
A switch in railML is defined as a non-linear infrastructure element (although it is possible to describe it by area location. We will provide this example as soon as possible). As such its position is defined by one or more <spotLocation>-s. In contrast a track is defined as a linear infrastructure element, accordingly its position is specified using a <linearLocation>.
Based on the topology of the example above, the child element <spotLocation> defines the logical position of the railway switch (line 103 of the listing) to be at the end of the <netElement> b03 (@position is given with 200 and the length of the <netElement> is specified as 200 as well). Track 3 is also located at element b03 (line 125 of the listing). This implies that switch is located at track.
It is recommended that switch is located at the net element of the beginning of a switch, i.e. b03. It is not recommended to set elements b01 or b04 as spot location of a switch.
The railway switch is then connected to navigable relations via <leftBranch> and <rightBranch> children (line 110 of the listing). Railway switches are not explicitly linked with non-navigable relations (line 65 of the listing). This means that both navigable and non-navigable relations are necessary to describe topology of an ordinary railway switch but only first ones are linked to a switch by @netRelationRef attributes of a switch’s children.
See source code for case b) below:
<switchIS id="swi02"
continueCourse="left"
branchCourse="right"
type="ordinarySwitch">
<name name="69W03"
language="en"/>
<spotLocation id="swi02_sloc01"
netElementRef="ne_b03"
applicationDirection="reverse"
pos="200.0">
<linearCoordinate positioningSystemRef="lps01"
measure="4.500"/>
</spotLocation>
<leftBranch netRelationRef="nr_b01b03"
branchingSpeed="80"
joiningSpeed="80"
radius="0"/>
<rightBranch netRelationRef="nr_b03b04"
branchingSpeed="40"
joiningSpeed="40"
radius="300"/>
</switchIS>
See source code for case c) below:
<switchIS id="swi02"
continueCourse="right"
branchCourse="left"
type="ordinarySwitch">
<name name="69W03"
language="en"/>
<spotLocation id="swi02_sloc01"
netElementRef="ne_b03"
applicationDirection="normal"
pos="200.0">
<linearCoordinate positioningSystemRef="lps01"
measure="4.500"/>
</spotLocation>
<rightBranch netRelationRef="nr_b01b03"
branchingSpeed="80"
joiningSpeed="80"
radius="0"/>
<leftBranch netRelationRef="nr_b03b04"
branchingSpeed="40"
joiningSpeed="40"
radius="300"/>
</switchIS>
See source code for case d) below:
<switchIS id="swi02"
continueCourse="right"
branchCourse="left"
type="ordinarySwitch">
<name name="69W03"
language="en"/>
<spotLocation id="swi02_sloc01"
netElementRef="ne_b03"
applicationDirection="reverse"
pos="200.0">
<linearCoordinate positioningSystemRef="lps01"
measure="4.500"/>
</spotLocation>
<rightBranch netRelationRef="nr_b01b03"
branchingSpeed="80"
joiningSpeed="80"
radius="0"/>
<leftBranch netRelationRef="nr_b03b04"
branchingSpeed="40"
joiningSpeed="40"
radius="300"/>
</switchIS>
Comparison with railML® 2
In railML® 2, the railway switch is positioned at the track. The railway switch “must” have both branches because of the cardinality constraint of XSD. In railML® 3, the railway switch is positioned at the net element. According to the schema, the railway switch “can” have both branches because of the cardinality constraint of XSD. However, both are necessary semantically.
In railML® 2, the construction of the railway switch is specified using attributes:
‒ @orientation: incoming, outgoing
‒ @course: left, right.
See railML® 2 interpretation of cases of Table 2 in Connection_between_tracks.
The railML® 2 railway switches @orientation is related to @applicationDirection railML® 3. The orientation of a switch in railML® 2 was always dependent on the direction of the track. In railML® 3 the directions specified for @continueCourse and @branchCourse can always be interpreted the same way, looking from the base of the switch.
Scope
A switch is a unit of a railway track network used to direct vehicles from one track to another track. This means that in railML® 3 the "class" of railway switches also includes a switch crossing. Simple crossings do not allow the train to get from one track to another and are represented by the <crossing> element.
In railML® 2, both switchable crossing and simple crossing are represented by the <crossing> element.
Topology
The code shows that track 3 includes net element b03. The railway switch is at the end of track 3 and the end of net element b03.
In railML® 2 it is possible to insert railway switches in the middle of a track. In railML® 3 this can also be done for tracks. Assuming the tracks 3 and 4 are merged into one let this new track be called 3X. Then, the new track 3X includes net elements b03 and b01 and a railway switch in the middle of the track. The main restriction of the railML® 3 model however is, that a railway switch is always at the end or the beginning of a net element. It cannot be defined in the middle of it.
This is because the railway switch refers to <netRelation>, which are always on the edge of net elements. This is implied by the fact that the @positionOnA and @positionOnB attributes of the netRelation can only accept the values 0 and 1. Thus, even though the attribute @intrinsicCoord of the child element <spotLocation> of the railway switch is of “double” data type, meaning that one can set intrinsic coordination to something like 0.75 (comp. Linear Positioning / referencing in the RailTopoModel® wiki) or position not equal to the length, the railway switch must still be on the edge of the net element (lines 110-113 of the listing).
Remarks
See <switchIL> for interlocking context.