| Link a "doubleSwitchCrossing" to two switchesIL [message #2855] |
Mon, 06 December 2021 19:55  |
Martin Zien
Messages: 12
Registered: December 2021
|
Junior Member |
|
|
My colleagues and me are facing a scenario, where a so called "doubleSwitchCrossing" is in a leter step being linked two single switches inside the "interlocking" (in railML as well as inside the real-live-system).
The difficulty is, that certain individual "designator"-Elements and also the name would also have to be assigned in Infrastructure-node individually.
In the work group for the ETCS-Use case, we elaborated that this special scenario is not covered yet by the current possibilities of modeling inside raiML 3.x.
To comply as much as possible with the already defined approaches in railML 3.2, we think it might help to introduce further optional sub-elements for the case of a "doubelSwitchCrossing" under such conditions.
These would appear only if needed - similar to what is being done with the specific elements "straightBranch" and "turningBranch".
As working title these specific extra branches should be called "switchPartition". Any referencing - e.g. inside "switchesIL" would occur to these sub-nodes.
In this regards it should be discussed, if this approach should also be considered for a singleSwitchCrossing as well - but only with one occurence.
You can find a complete double switch crossing in the attahement.
<switchPartition id="swip_13cd" applicationDirection="normal">
<name name="11" language="NO"/>
<designator register="infrastructureRegister" entry="switch11entry"/>
<leftBranch netRelationRef="nr_10388E_0_103C17_1"/>
<rightBranch netRelationRef="nr_103C17_1_B543_0"/>
</switchPartition>
|
|
|
|
|
|
|
|
| Re: Link a "doubleSwitchCrossing" to two switchesIL [message #2876 is a reply to message #2875] |
Mon, 17 January 2022 11:53  |
christian.rahmig
Messages: 436
Registered: January 2016
|
Senior Member |
|
|
Dear Martin,
thank you very much for your new proposal. From infrastructure point of view, it looks good, as it does not introduce new elements, but only new types for the <switch> element. The new types "doubleSwitchCrossingPartitioned" and "partitionSwitch" can be used to define semantic rules on the appearance and multiplicity of <switch> child elements, e.g. branches.
In order to have a synchronized approach: is it also necessary to partition simple switch crossings? If yes: can we use your approach also for simple switch crossings (partitioned)? If no: is the approach described in [1] with only one <switch> element for a simple switch crossing sufficient for all your needs?
[1] https://cloud.railml.org/index.php/f/77969
Thank you very much and best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Link a "doubleSwitchCrossing" to two switchesIL [message #2928 is a reply to message #2925] |
Tue, 01 March 2022 09:53 |
Thomas Nygreen
Messages: 66
Registered: March 2008
|
Member |
|
|
Dear all,
Thank you, Martin, for these proposals and examples. I suggest to use the existing type="doubleSwitchCrossing" and type="singleSwitchCrossing", also when the individual halves are included. The belongsToParent attribute is a general feature in the infrastructure schema, and I believe that we should not start splitting up types to signal that this feature is used. A simple Xpath query (from the context of the first switch in the given example: ../switchIS[@belongsToParent = "swi_10"]) will provide the "child" switches, if there are any.
I also hope that we can identify a more intuitive term than "partitionSwitch". When used in compound nouns, the word partition is normally placed last (e.g. hard disk partition), but this use is also rare. Some alternative suggestions: "switchPart", "switchCrossingPart", "partialSwitch", "componentSwitch", "virtualSwitch".
Regarding "virtualSwitch", the point is that these two halves are a virtual model of the physical switches placed in the opposite direction at each "corner" (i.e. at a, b, c and d for double switch crossings, and at either a and b or c and d for single switch crossings). Should our modelling reflect that, and also include the more physical (and nanoscopic) perspective as an option?
In the case of the single switch crossing, I also assume that the two <switchIL>s should be linked using <hasPositionRestriction> as described in [1]. It is not completely clear to me what the missing <branchTip> should point to in these cases. Perhaps that topic is worth a new thread in the IL part of the forum?
[1] https://wiki3.railml.org/wiki/IL:switchIL#Single_Slip_Switch
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: Link a "doubleSwitchCrossing" to two switchesIL [message #2933 is a reply to message #2928] |
Mon, 07 March 2022 09:08 |
christian.rahmig
Messages: 436
Registered: January 2016
|
Senior Member |
|
|
Dear all,
first of all thank you Thomas for summarizing your feedback from last workshop with Bane NOR on this topic of switch crossings. From your comments I concluded the following proposal:
* double switch crossings are modelled with a <switchIS>@type="doubleSwitchCrossing"
* single switch crossings are modelled with a <switchIS>@type="singleSwitchCrossing"
* switch crossings can be modelled as composition of switch parts or as single elements
* switch crossing parts are modelled with a <switchIS>@type="switchCrossingPart"
* switch crossing parts shall reference the switch crossing they belong to via @belongsToParent
Dear community, please let us know if you have any doubts with this adapted proposal. Its implementation is foreseen with upcoming railML 3.2. Any feedback is highly 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: Link a "doubleSwitchCrossing" to two switchesIL [message #3158 is a reply to message #2933] |
Mon, 06 November 2023 14:06 |
Dominik Looser
Messages: 18
Registered: March 2020
|
Junior Member |
|
|
Dear all,
I cannot open the attached files from above (always creates a 0 Byte file), so I am asking here about the contents.
For a double switch crossing, three <switchIS> elements exist. One with type="doubleSwitchCrossing", two with type="switchCrossingPart".
In interlocking, two <switchIL>-elements exist, one for each "switchCrossingPart".
Which of these IS-elements does the <switchIL>-element refer to in the <refersTo>-subelement? Does it refer to the "parent-doubleSwitchCrossing" or to its respective switchCrossingPart-counterpart?
Thank you and best regards,
Dominik
|
|
|
|
Members
Search
Help
Login
Home
