Home » railML newsgroups » railml.infrastructure » Modeling of switches (Reaching a consensus on necessary switch parameters, with interpretation examples )
Modeling of switches [message #1561] Mon, 08 May 2017 03:18
Claus Feyling is currently offline  Claus Feyling
Messages: 2
Registered: April 2016
Junior Member
Hello all,

We are modeling switches within the RailCOMPLETE software, and we have been confused by the early examples on the internet concerning the railML modeling of switches ( https://wiki.railML.org/index.php?title=Connection_between_t racksWink.

The purpose of this post is to address the need for an exact representation of all possible situations arising in practice. As an extreme example, an ordinary righthanded switch may be installed with cant in a sharp right curve, such that the highest allowed speed through the switch applies when following a course along curved right leg of this switch. The left leg branches off from the continuing curved track, and goes through complicated geometry in order to be level again.

Scope: This post does not address single / double slip switches or crossings (to be treated later).

* We propose to introduce a new property @geometry for switches in railML 3.x, with an intuitive meaning.

* We propose to re-interpret @length for a switch to mean "the distance from the stock rail joint to the rear end of any course ('leg'Wink along which the switch shall comply 100% with the underlying track's alignment data (i.e. horizontal geometry, vertical profile and cant)

* We propose to interpret "right" and "left" as seen into the tip of tongues, i.e. using the driver's perspective and not the infrastructure owner's "seen in the increasing mileage direction" perspective.

* Please refer to the short PDF "Questions Regarding Switch Modeling" contained in this post, as well as the longer PDF "Q & A Summary - Switch Geometry" found in the next post.


SWITCH GEOMETRY ("what it looks like, as received from a manufacturer")
------------------------------------------------------------ -----------
1) Switch @type is one of {ordinarySwitch, insideCurved, outsideCurved, threeWay, other}
2) Switch @geometry [proposed new property] is one of {right, left, symmetrical}, where "right switch" or "righthanded switch" means that the most curved track is to the right of the lesser curved track when you observe the switch looking into the tip of tongues, and similarly for "left switch" or "lefthanded switch". 'symmetrical' means that the leftmost and the rightmost leg of the switch share the same geometry for the length of the switch.
3) Two combinations of type and geometry are not meaningful (ordinarySwitch/symmetrical, insideCurved/symmetrical).

SWITCH TOPOLOGY ("how it is placed in the network")
----------------------------------
Imagine all track's center lines being drawn, then we fetch a switch with matching geometry and place it on top of these center lines in a location where the switch fits 100% with the track center lines' geometry.
4) A switch belongs to exactly one continuing @track, also nick-named the "parent track" for the switch
5) A switch's position is given by a @track id and a @pos/@absPos value in that track
6) The @trackContinueCourse of a switch denotes the course of travel through the switch geometry that conincides exactly with the continuing @track's alignment, for the length of the switch. Its value is one of {straight, left, right, other}. Note: 'straight' is only meaningful for threeWay switches. 'left' means that the continuing track conicides with the geometrically leftmost leg of the switch, as seen into its tip of tongues, and similarly for 'right'.

BRANCH TRACK(S) - SWITCH CONNETCIONS
------------------------------------
7) Every course through a switch not being the trackContinueCourse is called a 'branch'. It is most often a curved leg of the switch, but a branch may as well follow the straight leg of the switch.
Cool The branch track connects to the continuing track after first following a (connection) @course being one of {straight, left, right, other} as seen into the tip of tongues. Note that the branch track's @course through the switch must evidently be different from the parent track's @trackContinueCourse through the switch.
9) Finally, the @orientation of the branch is called 'outgoing' whenever a train traveling in the increasing mileage direction towards the switch meets the tip of tongues in the switching direction. The branch orientation is called 'incoming' if a train traveling in the increasing mileage direction towards the switch trails the tongues at the locatio where the branch track meets the switch's parent track,
10) Note that in a threeWay switch, both branches must have the same orientation.



Moderators edit: Explanation file will be merged and uploaded again. We beg your patience!

[Updated on: Thu, 11 May 2017 15:53] by Moderator

Report message to a moderator

Previous Topic: Platforms and ramps for railML 2.2
Next Topic: Track: description vs. trackDescr
Goto Forum:
  


Current Time: Sat Jul 22 14:53:10 CEST 2017