IS:connection switch

From railML 2 Wiki
Jump to navigation Jump to search


Scheme description / Schemenbeschreibung

Position of connection in the XML-Tree / Position von connection im XML-Baum

  • Parent: <switch>
  • Children: Not yet described. / Noch nicht beschrieben.

Multiplicity / Anzahl


Semantics / Bedeutung

The <connection> describes a branch of the <switch>, including which other track this branch is connected to. See Dev:Connection between tracks for more details on different connections between tracks.

Attributes of connection / Attribute von connection

  • id: XML-file-wide unique, machine-interpretable identity, required for later referencing that element internally. For a detailed explanation see Dev:identities.
    XML-Datei-weit eindeutige, maschineninterpretierbare Identität, die für die spätere interne Referenzierung dieses Elements erforderlich ist. Für eine detaillierte Erklärung siehe Dev:identities.
  • ref: This refers to the id attribute of the associated <connection> element.
  • orientation: Orientation of the <switch> branch relative to the direction of the <track> (looking towards the <trackEnd>).
  • incoming: This branch is merging into the track, tracks are converging relative to the direction.
  • outgoing: Twis branch is splitting out from the track, tracks are diverging relative to the direction.
  • rightAngled: This branch is crossing perpendicular to the track. Only meaningful for <crossing>, not for <switch>.
  • unknown: The direction is not known.
  • other:anything: Any value that does not fit any value from the previous enumeration list, fulfilling the constraint: at minimum two characters, whitespace is not allowed. Please, apply Dev:usingAny accordingly.
  • course: Sideways direction of this branch relative to the continuation of the <track> in the track's direction (looking towards the <trackEnd>).
  • straight This branch continues straight. This assumes the principal track is not considered straight (<switch>@trackContinueCourse is not "straight").
  • left: This branch is merging from the left or is diverging leftward from the track.
  • right: This branch is merging from the right or is diverging rightward from the track.
  • other:anything: Any value that does not fit any value from the previous enumeration list, fulfilling the constraint: at minimum two characters, whitespace is not allowed. Please, apply Dev:usingAny accordingly.
  • radius: Radius of the curve with which the branch rails converge into or diverge from the track, measured from an imaginary center of a circle. Defined in the same way as <radiusChange>@radius.
  • maxSpeed: Speed restriction for passing over the switch on this branch.
  • passable Denotes if you can pass between the track the <connection> is placed on and the track referred to by ref. See Dev:Connection_between_tracks for descriptions of the usage.
  • branchDist (deprecated with version 2.1) Since originally no separate, connecting track element was allowed, a special attribute denoted the length of the connection. See Dev:Connection_between_tracks.

Syntactic Constraints / Syntaktische Beschränkungen

  • id: xs:ID, required
    a string, starting with a letter (a..zA..Z) or an underscore (_),
    followed by a non-colonized and non-spaced string consisting of letters, digits, points (.), dashes (-) or underscores (_)
  • ref: tGenericRef (xs:IDREF); required
    Must point to the id of another <connection>
  • orientation: tConnectionOrientation (FIXME); required
  • course: tCourse (Restriction of xs:string; can be "straight"/"left"/"right" or any); optional
  • radius: tRadiusM (xs:decimal, 6 fraction digits, radius value measured in meter); optional (introduced with version 2.4)
🗒️ Until railML® 2.3: tLengthM (xs:decimal, 6 fraction digits, length value measured in meter) (deprecated with version 2.3)
  • maxSpeed: tSpeedKmPerHour (xs:decimal, 5 digits and 1 fraction digit with minimum value 0, speed value measured in km/h); optional
  • passable: xs:boolean; default: TRUE; optional
  • branchDist: tLengthM (xs:decimal, 6 fraction digits, length value measured in meter); optional

Best practice & Examples / Empfohlene Anwendung & Beispiele

As the movement possibilities are given for a fully functional <switch> (true), a simple <crossing> (false and false) and a double switch crossing (true and true; within railML® a <crossing>@type="doubleSwitchCrossing"), the attribute passable does not need to be defined for these element types. For fully functional switches and crossings only use passable for each of the <connection>s of a <crossing>@type="simpleSwitchCrossing" (single slip switch) with either the value combination true and false or false and true.

When setting a switch/crossing into a reduced state in railML

When you pad(lock) a switch or crossing, use <state>@disabled="true" to mark the switch or crossing as locked. Use passable on each <connection> to mark if that branch is passable in the locked state. There is no such attribute for passing over the switch/crossing in the track that continues through the switch, so this is only given implicitly through the combination of passability of the branches and the <switch>@type or <crossing>@type.

Norwegian vs. German business logic

This section is based on an example from the railML forum.

<switch>@trackContinueCourse always refers to the continuation of the <track> that the switch is placed on. If the switch is placed at that end of a <track>, this is the <connection> in the corresponding <trackBegin> or <trackEnd>. Conversely, the <connection>@course, gives the course(s) of the other leg(s). The attribute <switch>@trackContinueCourse is bound to the continuation of the track, and you cannot change which leg it refers to without also swapping the connections. Still, it is possible to swap which leg that is connected in <trackBegin>/<connection> (or <trackEnd>/<connection>) and which leg that belongs in <switch>/<connection>. What is important, to be able to determine the topology, is that the courses given on the same switch are different. In the case of a symmetrical switch, it is maybe most intuitive that one is "left" and the other is "right". If one is considered "straight" then the other should be "left" or "right".

Using the example of the switch 70W02 in the Advanced Example, here is a simplified code example with some placeholders in CAPITAL letters:

      <track id="tr1" type="mainTrack">
          <trackBegin id="tb1" pos="0.0" absPos="6505.0">
            <connection id="ctb1" ref="REF1"/>
          <!-- ... -->
            <switch id="sw1" name="70W02" pos="0.0" absPos="6505.0" trackContinueCourse="TRACK_COURSE">
              <connection id="csw1" orientation="incoming" course="SW_COURSE" ref="REF_SW"/>
          <!-- ... -->
        <!-- ... -->

      <track id="tr2" name="1" type="mainTrack">
          <!-- ... -->
          <trackEnd id="te2" pos="1180.0" absPos="6505.0">
            <connection id="cte2" ref="REF2"/>
          <!-- ... -->
        <!-- ... -->

      <track id="tr3" name="2" type="secondaryTrack">
          <!-- ... -->
          <trackEnd id="te3" pos="1180.0" absPos="6505.0">
            <connection id="cte3" ref="REF3"/>
          <!-- ... -->
        <!-- ... -->

With the "German definition" we would have

REF1: cte3

TRACK_COURSE: straight

REF_SW: cte2

SW_COURSE: right

REF2: csw1

REF3: ctb1

With the "Norwegian definition" we get

REF1: cte2


REF_SW: cte3

SW_COURSE: straight

REF2: ctb1

REF3: csw1

So, we are only swapping the two connections. The topology is unchanged, and in both cases the connection from tr1 to tr2 is "right" and the connection from tr1 to tr3 is "straight".

Please also refer to Dev:Connection_between_tracks for information on how to use connections and switches/crossings.

Notes / Anmerkungen


Open issues / Offene Punkte/Pendenzen

Not yet described. / Noch nicht beschrieben.