| suggestion for switchIS@type="crossingPart" [message #3770] |
Mon, 27 October 2025 13:01  |
Torben Brand
Messages: 214
Registered: March 2016
|
Senior Member |
|
|
Topology of a double slip switch (switchIS@type="doubleSwitchCrossing") [1] can be univocally defined with use of the construct switchIS@type="switchCrossingPart" as explained in Dev:Double and single switch crossing [2].
The same requirement (for univocally definition of topology) exist also for single slip switch and simple crossings. But it seems wrong to use a "switchCrossingPart" for one of the two parts in single slip switches and for a simple crossing according to reality and existing railML term definitions.
singleSwitchCrossing: It is a point where two tracks cross each other and enable trains to move from one track to the other. It is combination of a simple crossing, switch and connecting tracks used to guide a train from one straight track to another as well as going straight across. It allows going in 6 directions.
Thus, I suggest introducing the new enumerations value in railML3.4: switchIS@type="crossingPart"
with definition:
crossingPart: a crossing part of a singleSwitchCrossing or crossing segments part of a simple crossing
We would need a slight adjustment to the term definition of:
belongsToParent: reference to the one and only parent switch or simple crossing of this switch or crossing(segment) (to be used at switch crossings or simple crossings)
This for UC SCTP without screen coordinates. Whit use of an automated layouter to draw the topology.
[1] https://wiki3.railml.org/wiki/IS:switchIS
[2] https://wiki3.railml.org/wiki/Dev:Double_and_single_switch_c rossing
|
|
|
|
|
|
| Re: suggestion for switchIS@type="crossingPart" [message #3820 is a reply to message #3771] |
Mon, 08 December 2025 07:44  |
christian.rahmig
Messages: 568
Registered: January 2016
|
Senior Member |
|
|
Dear all,
your proposal touches several aspects, which I want to comment on as follows:
* A simple crossing does not contain any parts. There is a crossing point in the center, and that's it. Therefore, I don't see a necessity to transfer the "part concept" from switch to (simple) crossing.
* Simple switch crossings are complex and they should be handled like double switch crossings. This means: splitting into parts shall be possible. A code example may give us an impression of how such a simple switch crossing can look like.
* If we are missing information for a proper visualization of the branches of switch and crossing, what about the idea of introducing an attribute defining the crossing angle in reference to the oriented netElement, where the switch/crossing center point is located on? This angle may open in mathematical positive direction taking values between 0 and 180 degrees. I think, we had something like this in railML 2 already...
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: suggestion for switchIS@type="crossingPart" [message #3822 is a reply to message #3820] |
Mon, 08 December 2025 10:34 |
Mathias Vanden Auweele
Messages: 146
Registered: February 2025
Location: Brussels
|
Senior Member |
|
|
Quote:* Simple switch crossings are complex and they should be handled like double switch crossings.
Did you mean 'Single' instead of 'Simple'?
Here is a code sample on how it would look when we would add the 'crossingPart' in the case of a single switch crossing:
<switchIS id="swi1" type="singleSwitchCrossing">
<straightBranch netRelationRef="nr1"/>
<straightBranch netRelationRef="nr2"/>
<turningBranch netRelationRef="nr3"/>
</switchIS>
<switchIS id="swi1_part1" type="switchCrossingPart" branchCourse="left" continueCourse="right" belongsToParent="swi1">
<spotLocation intrinsicCoord="1.0" netElementRef="le1" applicationDirection="normal" />
<leftBranch netRelationRef="nr3"/>
<rightBranch netRelationRef="nr2"/>
</switchIS>
// following element is invalid railML3.3
// but proposed to be made possible railML3.4
<switchIS id="swi1_part2" type="crossingPart" branchCourse="left" continueCourse="right" belongsToParent="swi1">
<spotLocation intrinsicCoord="1.0" netElementRef="le4" applicationDirection="reverse" />
<leftBranch netRelationRef="nr4"/>
<rightBranch netRelationRef="nr2"/>
</switchIS>
Here's a schematic:
https://link.excalidraw.com/readonly/4yJOs2oj204neDP9jatl
Quote:what about the idea of introducing an attribute defining the crossing angle in reference to the oriented netElement, where the switch/crossing center point is located on?
I think it's a good idea to look at it from this angle (pun intended). But defining the crossing angle might go further than what's required to fulfill the use case. We essentially need to say which branch is left of which other branch.
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
[Updated on: Mon, 08 December 2025 10:38] Report message to a moderator |
|
|
|
| Re: suggestion for switchIS@type="crossingPart" [message #3840 is a reply to message #3822] |
Mon, 15 December 2025 13:56 |
christian.rahmig
Messages: 568
Registered: January 2016
|
Senior Member |
|
|
Dear Mathias,
let me pick up your code example and modify it a little bit: Instead of adding a "crossing part", I just left out the second switch crossing part, because there is no "switch functionality" if approaching from this side. Consequently, a partitioned single switch crossing consists of one switch of type "switchCrossingPart" and one parent switch of type "singleSwitchCrossing".
In particular:
<switchIS id="swi1" type="singleSwitchCrossing">
<straightBranch netRelationRef="nr1"/>
<straightBranch netRelationRef="nr2"/>
<turningBranch netRelationRef="nr3"/>
</switchIS>
<switchIS id="swi1_part1" type="switchCrossingPart" branchCourse="left" continueCourse="right" belongsToParent="swi1">
<spotLocation intrinsicCoord="1.0" netElementRef="le1" applicationDirection="normal" />
<leftBranch netRelationRef="nr3"/>
<rightBranch netRelationRef="nr2"/>
</switchIS>
This approach of not explicitly modelling "crossing parts" fits to the approach of modelling simple crossings, where there are also no "crossing parts".
As always, any feedback from you and the rest of the community is very much appreciated.
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: suggestion for switchIS@type="crossingPart" [message #3846 is a reply to message #3840] |
Tue, 16 December 2025 15:12 |
Mathias Vanden Auweele
Messages: 146
Registered: February 2025
Location: Brussels
|
Senior Member |
|
|
Hello Christian, yes I know that there is no switching possibility on crossing parts, the example was to show how it could work with the proposal of Torben in the topic start:
Quote:Thus, I suggest introducing the new enumerations value in railML3.4: switchIS@type="crossingPart"
with definition:
crossingPart: a crossing part of a singleSwitchCrossing or crossing segments part of a simple crossing
just as you requested:
Quote:A code example may give us an impression of how such a simple switch crossing can look like.
The problem that this forum topic tries to discuss is that a schematic track layout tool is not capable of knowing what to draw left and what to draw right, based on a <crossing> or <switchIS type="singleSwitchCrossing">, because it is missing left/right information that is supplied as <switchIS type="switchCrossingPart"> for <switchIS type="doubleSwitchCrossing">
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
| Re: suggestion for switchIS@type="crossingPart" [message #3922 is a reply to message #3846] |
Sun, 08 March 2026 08:14 |
christian.rahmig
Messages: 568
Registered: January 2016
|
Senior Member |
|
|
Dear all,
the topic of modelling simple crossings in a way of unambiguous layouting has been discussed in the SCTP working group and in the BaneNOR workshop, too. As shown in the presentation [1], we could solve the question of unambiguous layouting for single switch crossing and double switch crossing. However, the situation with simple crossings remained open:
The following model of a crossing (see slide 17) still results in two possible layouts:
<crossing id="cro42" angle="140">
<name name="69K08" />
<spotLocation id="swi42_sloc01" netElementRef="ne_15" ... />
<straightBranch netRelationRef="nr_a15a18" radius="0" />
<straightBranch netRelationRef="nr_a16a17" radius="0" />
</crossing>
Question to be answered in this example: what is the reference for the angle attribute? Solution proposal: we define a semantic rule that a simple crossing always needs to be located on the topology (netElement) using a <spotLocation> element. This means that the simple crossing will be located at exactly one of four <netElement> elements connected in this crossing. This one <netElement> can be the reference as "incoming branch" from which the angle of the crossing branch can be added in a mathematical positive direction with values in range 1..179. For above example referring to slide 17 of the presentation [1] this means that the layout of the crossing will be one of the two lower options.
For solving the last step, looking at the navigable <netRelation> elements is necessary. For example:
<netRelations>
<netRelation id="nr_a15a16" navigability="Both" positionOnA="1" positionOnB="1">
<elementA ref="ne_15" />
<elementB ref="ne_16" />
</netRelation>
</netRelations>
In this example the connection from "ne_15" to "ne_16" is navigable. Together with the information about the crossing angle as described above, we end up with an unambiguous layout of the simple crossing. Do you agree?
[1] https://cloud.railml.org/s/XpJHA6HSNPTZfy4
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: suggestion for switchIS@type="crossingPart" [message #3930 is a reply to message #3922] |
Mon, 09 March 2026 12:17 |
Mathias Vanden Auweele
Messages: 146
Registered: February 2025
Location: Brussels
|
Senior Member |
|
|
Some other ideas to complement the angle (since topology netrelations are not possible):
- give the angleFromNetElement and angleToNetElement (in which case, making the angle a subelement instead of an attribute would make more sense to me, as multiple angles could be given)
- define two spotlocations on linear elements and the angle is mandatory between the two netelements of those spotlocations (don't like this idea very much)
- make the angle mandatory between the 'elementA' of the straightBranches' netrelations (probably cleanest approach).
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
|
|
| Re: suggestion for switchIS@type="crossingPart" [message #3942 is a reply to message #3939] |
Fri, 20 March 2026 12:33 |
christian.rahmig
Messages: 568
Registered: January 2016
|
Senior Member |
|
|
Dear Dominik and Mathias,
thank you very much for your input! Taking the idea with the angle and applying it to the example from above, this may look like this:
<crossing id="cro42">
<name name="69K08" />
<spotLocation id="swi42_sloc01" netElementRef="ne_15" ... />
<crossingAngle fromNetElement="ne_15" toNetElement="ne_16" value="140" />
<straightBranch netRelationRef="nr_a15a18" radius="0" />
<straightBranch netRelationRef="nr_a16a17" radius="0" />
</crossing>
Does this fulfill your needs?
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
|
|
|
|
|
| Re: suggestion for switchIS@type="crossingPart" [message #4033 is a reply to message #3954] |
Fri, 12 June 2026 12:55 |
christian.rahmig
Messages: 568
Registered: January 2016
|
Senior Member |
|
|
Dear all,
when implementing the issues for railML 3.4, we discovered an overlap between this discussion about simple crossings [1] and the other topic about switch ratios [2], [3].
In particular: the ratio is defined as tangens of the switch/crossing angle. This means, that a crossing angle in the range 0<angle<90 degrees can be unambiguously translated into a ratio value of 1:x with x>0.
In order to avoid redundancies and model conflicts, we thought about how to fuse both issues: Make use of the ratio (denominator), but link it with the netElements that form the (smaller) crossing angle. This is, how the idea can look like for the already introduced example crossing with ratio 1:9 (corresponds to a crossing angle of 6,4 degrees):
<crossing id="cro42">
<name name="69K08" />
<spotLocation id="swi42_sloc01" netElementRef="ne_15" ... />
<ratio fromNetElement="ne_15" toNetElement="ne_16" denominator="9" />
<straightBranch netRelationRef="nr_a15a18" radius="0" />
<straightBranch netRelationRef="nr_a16a17" radius="0" />
</crossing>
My questions to you, dear community:
1) What do you think about this approach?
2) What do you use more in reality: crossing angle or crossing ratio?
As usual, any kind of feedback is very much appreciated before I am going to update the solution proposal in [1].
Thank you very much and best regards
Christian
[1] https://development.railml.org/railml/version3/-/issues/719
[2] https://development.railml.org/railml/version3/-/issues/685
[3] https://www.railml.org/forum/index.php?t=msg&th=1099& ;start=0&
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
|
|
|
|
|
| Re: suggestion for switchIS@type="crossingPart" [message #4048 is a reply to message #4038] |
Wed, 17 June 2026 11:29 |
christian.rahmig
Messages: 568
Registered: January 2016
|
Senior Member |
|
|
Dear Dominik and Mathias,
thank you very much for your feedback!
For a crossing angle of 90 degrees the ratio (defined as tangens of the crossing angle) is infinite. As we model only the denominator of the ratio (e.g. only "9" instead of "1:9"), we can define a denominator of "0" to correspond to an infinite ratio and a crossing angle of 90 degrees.
Important is also the definition of the second referenced netElement being the one that is closest to the first one (smallest angle). Taking this into consideration we allow for (mathematical) negative angles, too.
So, the example from above could look like this:
<crossing id="cro42">
<name name="69K08" />
<spotLocation id="swi42_sloc01" netElementRef="ne_15" ... />
<ratio fromNetElement="ne_15" toNetElement="ne_17" denominator="-7.5" />
<straightBranch netRelationRef="nr_a15a18" radius="0" />
<straightBranch netRelationRef="nr_a16a17" radius="0" />
</crossing>
As you can see, the second referenced netElement is ne_17 and not ne_16, because the (absolute value of) angle between ne_15 and ne_17 is smaller than the angle between ne_15 and ne_16. For reference, please have a look at the updated solution proposal in the Gitlab issue #719 [1] and the slide presentation [2].
[1] https://development.railml.org/railml/version3/-/issues/719
[2] https://cloud.railml.org/f/716092
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
