| Handling of netElement directions in switches and crossings [message #3702] |
Tue, 26 August 2025 16:43  |
Torben Brand
Messages: 214
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 |
|
|
|
Members
Search
Help
Login
Home
