| 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: 530
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: 86
Registered: February 2025
Location: Brussels
|
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: 530
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: 86
Registered: February 2025
Location: Brussels
|
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
|
|
|
|
Members
Search
Help
Login
Home
