| Handling of netElement directions in switches and crossings [message #3702] |
Tue, 26 August 2025 16:43  |
Torben Brand
Messages: 211
Registered: March 2016
|
Senior Member |
|
|
In the latest proposed version 14 of the advanced example we have introduced three linear positioning systems (LPS); see attached PDF. Transition between LPS 2444 and LPS 9333 in the border point "Kudowa chranice" is straight forward with a mileage direction change.
But there seems to be a potential issue where LPS 9333 and LPS 8176 meet inside Cranz station
LPS 8176 is valid for track 1, 2 and 21 and LPS 9333 for track 3, where it currently ends at double slip switch "69W08cd". The increasing mileage direction for LPS 8176 goes from right to left and for LPS 9333 it goes from left to right.
The netElement direction is not defined in the advanced example drawing.
In the work of drawing the advanced example in the tool RailOscope to generate the draft for the railML.org example file I encountered an issue:
In a first version (here A) I had the netElements (track edges in railOscope) direction follow the direction of the mileage increase this seemed natural for me as it is a Norwegian in-house best practice. So the netElements direction (from intrinsicCoordinate 0 to 1) goes from right to left for LPS 8176 and from left to right for LPS 9333. This leads to a direction change in the two switches 69W10 and 69W09 and the double slip switch 69W08cd.
This alternative A generates an error warning in railOscope and an invalid railML file!
So is it possible/valid in railML to have a netElement direction change for netElements connected to the same switch/crossing?
For instance would it not be challenging due to generic values that describe directions of elements in the switch/crossing node and elements on the switch like: applicationDirection="normal"/"reverse", side="left"/"right", <leftBranch>/<rightBranch> and branchingSpeed/joiningSpeed (and more?). How would these be handled?
Could we make a rule to reference this relevant to a specific netElement? Even if, this would very quickly become very complex for the exporting/importing tools!
I have created an alternative B in railOscope [2] where I have changed the direction of the netElements inside Cranz for LPS 9333 but kept the mileage direction (still compliant with the advanced example drawing) . This results in the netElements in Cranz being in the same direction for both LPS and thus for all netElements connected to all/the three switches. This creates a direction change on the station border towards Funera, but not a mileage direction change. This does create a falling mileage in direction of the netelements in track 3. This is valid in railML - but might be unexpected. The alternative B exports fine in RailOscope.
We could also have an alternative C where we adhere to the rules of having the mileage increase in the direction of the net elements AND have all netElements in switches and crossings in the same direction.
In this case we have to place the LPS borders next to the switches/crossings and not in their node. For the advanced example I suggest this to be on the train detectors on km 4,350 (LPS 8176) for switch 69W10 and km 4,360 (LPS 8176) for switch 69W09 and on the spotLocation for track 3 Cranz on km 0 (LPS 9333) and 4,8 (LPS 8176) for the double slip switch 69ac (same as in version 13).
I have made an example for this in RailOscpe here [3]
What does the community think?
Should we use alternative A, B or C in the advanced example? See attached illustration.
And should we to remove the ambiguity described here, introduce semantic constraints for the increasing mileage direction to be one or both?:
1. the same as the direction of the netElements
2. have same netElement direction for all netElements connected to a switch or crossing
[1] error message and link to alt A - pending
[2] link to alt B - pending
[3] link to alt C - pending
[Updated on: Tue, 26 August 2025 16:51] Report message to a moderator |
|
|
|
| Re: Handling of netElement directions in switches and crossings [message #3703 is a reply to message #3702] |
Thu, 28 August 2025 09:45  |
Mathias Vanden Auweele
Messages: 129
Registered: February 2025
Location: Brussels
|
Senior Member |
|
|
The direction of netElements should be independent on any linear positioning systems defined on them. That's the whole purpose of having a topology, to make it stable and independent, whatever the functional implementation on top of it.
Quote:
This alternative A generates an error warning in railOscope and an invalid railML file!
Yes, don't do this
Quote:
applicationDirection="normal"/"reverse", side="left"/"right", <leftBranch>/<rightBranch> and branchingSpeed/joiningSpeed (and more?). How would these be handled?
These don't depend on LPS but on the direction of the netElement in question.
Honestly, I would just really randomize the direction of NetElements in order to avoid this kind of confusion. Don't try to invent a rule for the direction of netElements, it will fail in edge cases like what you are facing now and you will try to find fixes that will make the problem worse :(
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
[Updated on: Mon, 06 October 2025 13:38] Report message to a moderator |
|
|
|
| Re: Handling of netElement directions in switches and crossings [message #3731 is a reply to message #3702] |
Mon, 06 October 2025 09:37 |
Silvan Gruber
Messages: 11
Registered: July 2024
|
Junior Member |
|
|
Hi Torben,
The topic was discussed in the ETCS Working Group on September 22nd. The participants agreed that railML should not specify any rules/semantic constraints regarding the orientation of NetElements. The presented options [A] [B] [C] describe "best practices" with the use of "railOscope" as a tool. However, the participants generally consider variant [B] to be a possible "best practice" to avoid making the tools unnecessarily complex.
Direction-dependent values of switches as you metioned above should generally only refer to the switch element (viewing the switch from the switch tip) and should not be dependent on the orientation of the underlying topology. However, option [B] can be quite helpful for switchCrossings/crossings etc.
Best regards,
Silvan
|
|
|
|
Members
Search
Help
Login
Home
