IS:connection switch: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
[checked revision][checked revision]
(Additions suggested by Torben Brand)
(railML→{{rml}})
 
(4 intermediate revisions by 3 users not shown)
Line 24: Line 24:
|bestpractice=As the movement possibilities are given for a fully functional {{IS:Tag|switch}} (''true''), a simple {{IS:Tag|crossing}} (''false'' and ''false'') and a double switch crossing (''true'' and ''true''; within {{rml}} a crossing with @type=doubleSwitchCrossing) the passable does not need to be defined for these element types. For fully functional switches/crossings only use @passable for each of the IS:crossing connection of a crossing@type="simpleSwitchCrossing" (single slip switch) with either the value combination ''true'' and ''false'' or ''false'' and ''true''.
|bestpractice=As the movement possibilities are given for a fully functional {{IS:Tag|switch}} (''true''), a simple {{IS:Tag|crossing}} (''false'' and ''false'') and a double switch crossing (''true'' and ''true''; within {{rml}} a crossing with @type=doubleSwitchCrossing) the passable does not need to be defined for these element types. For fully functional switches/crossings only use @passable for each of the IS:crossing connection 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 inn a reduced state in railML =====
===== When setting a switch/crossing into a reduced state in {{rml|tm=no}} =====
When you pad(lock) a switch/switch crossing use the combination of state@disabled=true and passable=true/false under the switch/crossing element.
When you pad(lock) a switch/switch crossing use the combination of state@disabled=true and passable=true/false under the switch/crossing element.
The passable for passing over the switch/crossing on the track the switch is placed on (the principal/straight track) is implicit given through the @passable=''true''/''false'' of the switch connection (the diverging track).
The passable for passing over the switch/crossing on the track the switch is placed on (the principal/straight track) is implicit given through the @passable=''true''/''false'' of the switch connection (the diverging track).
==== Norwegian vs. German business logic ====
https://www.railml.org/forum/index.php?t=msg&th=924&start=0&
@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 @trackContinueCourse is bound to the continuation of the track, and you cannot change which leg it refers to without also swapping the connections. So you should not really be asking which leg @trackContinueCourse should refer to, but which leg that belongs in trackBegin/connection (or trackEnd/connection) and which leg that belongs in switch/connection. In my view and experience, it is perfectly fine to allow different business logics in this question.
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". If we make a rule that depends on radius, what will we do when the radius is unknown?
To return to the example of the switch 70W02 in the advanced example, here is a simplified code example with some placeholders in CAPITAL letters:
<syntaxhighlight lang="xml">
      <track id="tr1" type="mainTrack">
        <trackTopology>
          <trackBegin id="tb1" pos="0.0" absPos="6505.0">
            <connection id="ctb1" ref="REF1"/>
          </trackBegin>
          <!-- ... -->
          <connections>
            <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"/>
            </switch>
          </connections>
          <!-- ... -->
        </trackTopology>
        <!-- ... -->
      </track>
      <track id="tr2" name="1" type="mainTrack">
        <trackTopology>
          <!-- ... -->
          <trackEnd id="te2" pos="1180.0" absPos="6505.0">
            <connection id="cte2" ref="REF2"/>
          </trackEnd>
          <!-- ... -->
        </trackTopology>
        <!-- ... -->
      </track>
      <track id="tr3" name="2" type="secondaryTrack">
        <trackTopology>
          <!-- ... -->
          <trackEnd id="te3" pos="1180.0" absPos="6505.0">
            <connection id="cte3" ref="REF3"/>
          </trackEnd>
          <!-- ... -->
        </trackTopology>
        <!-- ... -->
      </track>
</syntaxhighlight>
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
TRACK_COURSE: right
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.
}}
}}

Latest revision as of 18:21, 22 January 2024


connection
 


Scheme description / Schemenbeschreibung

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

  • Parent: <switch>
  • Children: None

Multiplicity / Anzahl

[1..3]

Semantics / Bedeutung

A <connection> is an element to determine which branches of a track are connected at a certain position.

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 element relative to general track direction (aligned with increasing mileage) [1]
  • incoming: A track is merging into the principal track, tracks are converging relative to the direction [1]
  • outgoing: A track is splitting out from the principal track, tracks are diverging relative to the direction [1]
  • rightAngled: semantics unclear. Please try to avoid and refer to official examples Dev:Connection_between_tracks
  • 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: Relative direction of a converging/diverging track connection facilitated by a switch in a crossing. Course is always defined relative to the switch element (i.e. to stock rail), regardless of global track direction. [1]
  • straight semantics is not clear. Please try to avoid and refer to official examples Dev:Connection_between_tracks
  • left: A switch track is merging from the left or is diverging leftward from the principal track [1]
  • right: A switch track is merging from the right or is diverging rightward from the principal track [1]
  • 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 switch rails converge into or diverge from the principal track, measured from an imaginary center of a circle. Value will usually be non-zero. [1]
  • maxSpeed: Speed restriction on a switch when used in a deflecting direction, i.e. when merging onto or diverging from a principal track [1]
  • passable
    Denotes if you can pass between the track the switch is placed on and the track connecting to the switch.
  • 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 with @type=doubleSwitchCrossing) the passable does not need to be defined for these element types. For fully functional switches/crossings only use @passable for each of the IS:crossing connection 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/switch crossing use the combination of state@disabled=true and passable=true/false under the switch/crossing element. The passable for passing over the switch/crossing on the track the switch is placed on (the principal/straight track) is implicit given through the @passable=true/false of the switch connection (the diverging track).

Norwegian vs. German business logic

https://www.railml.org/forum/index.php?t=msg&th=924&start=0&

@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 @trackContinueCourse is bound to the continuation of the track, and you cannot change which leg it refers to without also swapping the connections. So you should not really be asking which leg @trackContinueCourse should refer to, but which leg that belongs in trackBegin/connection (or trackEnd/connection) and which leg that belongs in switch/connection. In my view and experience, it is perfectly fine to allow different business logics in this question.

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". If we make a rule that depends on radius, what will we do when the radius is unknown?

To return to 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">
        <trackTopology>
          <trackBegin id="tb1" pos="0.0" absPos="6505.0">
            <connection id="ctb1" ref="REF1"/>
          </trackBegin>
          <!-- ... -->
          <connections>
            <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"/>
            </switch>
          </connections>
          <!-- ... -->
        </trackTopology>
        <!-- ... -->
      </track>

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

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

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

TRACK_COURSE: right

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


None.

Open issues / Offene Punkte/Pendenzen

Not yet described. / Noch nicht beschrieben.