Home » railML newsgroups » railML.infrastructure » [railML3.1] Modelling of a double slip switch
[railML3.1] Modelling of a double slip switch [message #2412] Fri, 03 April 2020 06:05 Go to next message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 86
Registered: March 2016
Member
Dear all,

there seems to be a general issue when transforming a track plan into railML:

1) For an 'ordinarySwitch' we have in IS the elements 'leftBranch' and 'rightBranch'. Just from the netRelations it
seems not really possible to decide which is one of the both branches. How would you solve the issue?

2) For a 'doubleSwitchCrossing' we have in IS the elements 'straightBranch' and 'turningBranch' but in IL we need to
split into two normal switches which again have 'leftBranch' and 'rightBranch'. Could this be solved just from the
topology information? How would you do this trick?

--
Regards,
Jörg von Lingen - Interlocking Coordinator
Re: [railML3.1] Modelling of a double slip switch [message #2423 is a reply to message #2412] Fri, 24 April 2020 08:14 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Jörg,

Jörg von Lingen wrote on Fri, 03 April 2020 06:05
Dear all,

there seems to be a general issue when transforming a track plan into railML:

1) For an 'ordinarySwitch' we have in IS the elements 'leftBranch' and 'rightBranch'. Just from the netRelations it
seems not really possible to decide which is one of the both branches. How would you solve the issue?
You are right: from topology alone, it is not possible to identify a left or right branch of a switch. But this "gap" is intended, because topology has no layout. Topology purely describes logical connections/relations and navigability of the network. Therefore: the infrastructure element <switchIS> is needed (together with topology) to distinguish left and right branch at a switch.

Jörg von Lingen wrote on Fri, 03 April 2020 06:05
2) For a 'doubleSwitchCrossing' we have in IS the elements 'straightBranch' and 'turningBranch' but in IL we need to
split into two normal switches which again have 'leftBranch' and 'rightBranch'. Could this be solved just from the
topology information? How would you do this trick?
As said before: it is not possible to distinguish between left and right branch just from topology. However, netElements and netRelations describe the topology dimension (navigability...) of a double switch crossing completely. In infrastructure the <switchIS> element builds on top of this topology view summarizing the relations in "straight" and "turning" branches. If - in interlocking - you want to model the double switch crossing with two <switchIL> elements, a different aggregation approach is needed. How this looks in detail, still needs to be analysed and results should be published here in this forum thread.

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3.1] Modelling of a double slip switch [message #2450 is a reply to message #2412] Mon, 01 June 2020 15:37 Go to previous message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 86
Registered: March 2016
Member
Dear all,

in-between I had a discussion about this topic with some users and want to add
the outcome here for your info.

The attached pictures show the 3 steps of evolution from simple switches to a
double slip crossing if you go into interlocking domain.
step01: For a simple switch one needs to do a geometrical check in order to find
out what's right and left of the deviating branches,
step02: This is more an intermediate state for illustration. The two switches
are a bit superimposed (not yet a real double slip but to show the evolution).
Here the determination right/left shall be the same as in step01.
step03:The third step is the final superimposition but if you think of two
simple switches making the picture then the decision for right/left shall be
under the same rule.

The picture "switches01" shows the net plan for an example of double slip switch
(SLIP SWITCH Dsw02):

1) select from straightBranch one with starting netElement
nr_ne5ne12_dsw7 -> ne5
2) connection straight -> ne12
3) connection turning -> ne6
4) geometrical check: ne6 is right of ne12
rightBranch=ne6, leftBranch=ne12
5) select the other end of the straightBranch -> ne12
6) connection straight -> ne5
leftBranch=ne5 (due to symmetry)
7) connection turning -> ne2
rightBranch=ne2

similar procedure for SLIP SWITCH Dsw04:

1) nr_ne9ne11_dsw10 -> ne9
2) straight -> ne11
3) turning -> ne6
4) geometrical check: leftBranch=ne6, rightBranch=ne11
5) ne11
6) straight -> ne9, rightBranch=ne11
7) turning -> ne10, leftBranch=ne10


Best regards,
Joerg v. Lingen - Interlocking Coordinator
Am 03.04.2020 um 06:05 schrieb Joerg von Lingen:
> Dear all,
>
> there seems to be a general issue when transforming a track plan into railML:
>
> 1) For an 'ordinarySwitch' we have in IS the elements 'leftBranch' and 'rightBranch'. Just from the netRelations it
> seems not really possible to decide which is one of the both branches. How would you solve the issue?
>
> 2) For a 'doubleSwitchCrossing' we have in IS the elements 'straightBranch' and 'turningBranch' but in IL we need to
> split into two normal switches which again have 'leftBranch' and 'rightBranch'. Could this be solved just from the
> topology information? How would you do this trick?
>
  • Attachment: step01.jpg
    (Size: 15.17KB, Downloaded 239 times)
  • Attachment: step02.jpg
    (Size: 12.91KB, Downloaded 224 times)
  • Attachment: step03.jpg
    (Size: 12.77KB, Downloaded 229 times)
  • Attachment: switches01.png
    (Size: 51.32KB, Downloaded 237 times)
Previous Topic: [railML3] Functional type parameter for the balise group element
Next Topic: Defintion of is::track type attribute
Goto Forum:
  


Current Time: Fri Mar 29 11:50:03 CET 2024