| suggestion for switchIS@type="crossingPart" [message #3770] |
Mon, 27 October 2025 13:01  |
Torben Brand
Messages: 205
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: 536
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: 100
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: 536
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: 100
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: 536
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: 100
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
|
|
|
|
Members
Search
Help
Login
Home
