| associated netElements coordinates for LPS and measure precision issues [message #3642] |
Wed, 11 June 2025 16:14  |
Fredrik Jönsson
Messages: 14
Registered: June 2024
Location: Sweden
|
Junior Member |
|
|
When using linearCoordinateBegin/associatedNetElement/linearCoordinateE nd a measure is given in meters refering and a ref to a linearPositioningSystem via associatedPositioningSystem.
The measure is calculated by taking the value of last km board(km post) times 1000 + meters after said board. Due to the distance between kilometer boards not always being exactly 1000m the measure for a linearCordinate might differ from the actual real value. We've not dealt with a situation like this before as the Swedish equivalent of measure in our legacy system is given in the format of (km + m), for example (44+500) would be 500m after km-board 44, no matter how long or short the "kilometres" are, the location is still "accurate" as it doesn't have to refer back to the start of the LPS only the last board.
Our tool railexporterSE https://www.railml.org/en/software/railexporterse does not know the distance of all kilometers before where the export begins, it only has data from the given scope of the current export. Therefore, railexporterSE does not know the actual distance from the start point (measure = 0) of the LinearPositioningSystem(s) to the start of the given scope of the export.
How important is it that the value of "measure" is 100% spot on? We mostly see this as a data quality/ precision issue.
The way we have used LPS in the Swedish railroad system it's a "secondary way" of locating objects in the network. Our main/master way of locating is using meters from last node/switch. Which is converted to intrinsic coordinates on linearLocation/associatedNetElement in railexporterSE. Therefore, we see the intrinsic coordinates as the "Must have" for precise locating of assets in the network and the LinearCoordinate with measure and LPS-ref to be used for a quick overview where the precision is not that important, the important part is that the assets with lower measure are physically located "before" assets with hight measure.
For example: How big issue would it be if a signal is given a measure of 114600m (yes we have atleast one LPS where this is possible) but the actual measure might differ with a few 100m if you were to accurately measure the distance in meter from the start of the LPS to the end. As long as all objects in the exported railML-file has the same offset to the true distance along the LPS there is no real problem, objects closer to the start of the LPS will get a lower measure than objects closer to the end of the LPS 99.9% of the time.
Example
associatedNetElement/linearCoordinateBegin and linearCoordinateBegin/associatedNetElement/linearCoordinateE nd measure values refer to the green locations.
On the third location you get a discrepancy due to the previous kilometre not being 1000m
Measure = 2010 m (green location)
Real value = 1960 m (red arrow)
950m is an exaggerated value to illustrate the problem, usually the distance between boards is 1000 +/- 5 m.
Has anyone else dealt with a similar issue, and if so, what was your solution?
Fredrik Jönsson
Trafikverket - Swedish Transport Administration
|
|
|
|
| Re: associated netElements coordinates for LPS and measure precision issues [message #3657 is a reply to message #3642] |
Fri, 20 June 2025 11:39  |
christian.rahmig
Messages: 555
Registered: January 2016
|
Senior Member |
|
|
Dear Frederik,
thank you for bringing up this real world example. I will think about it and we can discuss possible solutions in the NEST meeting on Monday. I hope, other working group members will do the same and contribute with their examples and experiences...
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: associated netElements coordinates for LPS and measure precision issues [message #3662 is a reply to message #3657] |
Tue, 24 June 2025 16:46 |
Mathias Vanden Auweele
Messages: 129
Registered: February 2025
Location: Brussels
|
Senior Member |
|
|
Hello Frederik, Christian,
You raise an important point that I have also raised a couple of times. In Belgium, there are some extreme cases where kilometer boards are even spaced 1900m apart. There the notation of 44+500 is also used. And depending on the application, that can also be 44+1500
In my opinion, there are some issues with how railML handles the LinearCoordinate.
Let's start from the beginning
railML allows the possibility to specify the type of LinearPositioningSystem https://wiki3.railml.org/wiki/RTM:linearPositioningSystem
- absolute: mileage i.e. distance from beginning of a line
- interpolation: determine location by interpolating between two known locations along a route.
- relative: relative to some point on a line, not a beginning of a line,
I'm not sure about that 'interpolation' type. But the 'absolute' type is how you describe it to be and needs to be "spot on" if you want to do any serious calculations with the LinearCoordinate (distances for example). Required quality always depends on the use case, so if the use case is ok with 1000m of accuracy, then an accurate absolute measure doesn't matter.
What's more interesting is the 'relative' type. railML allows to associate Anchors to a LinearPositioningSystem. The Anchors are these kilometer boards/poles in most cases. I'm assuming that those Anchors are only relevant for the 'relative' type.
However, the LinearCoordinate doesn't allow to use these Anchors: https://wiki3.railml.org/wiki/RTM:spotLocation:linearCoordin ate#3.3-0
The "measure" attribute always seems to be referencing the start of the LinearPositioningSystem. So always dealing with an 'absolute' type of LinearPositioningSystem. Where is the option to reference a 'relative' type of LinearPositioningSystem together with an Anchor that serves as the 0 point for the measure value? If railML adds this possibility, then your problem is solved and you can use this "44+500" type of notation in the LinearCoordinate.
But then again, when you have the exact position of the Anchors and you know their 'measure' on the LinearPositioningSystem, you can convert "44+500" into "measure of board 44" + 500 and use that as the measure of the LinearCoordinate. Any applications that are using the linear coordinate should then be smart enough to use the 44+500 notation when converting back from the absolute position.
NOTE 1: some anchors can be missing. For example can jump from 43 to 45. Either the real physical board is missing, the LinearPositioningSystem is interrupted (track void), or the data missing in the database. Several solutions exist such as "virtual kilometer markers". Sometimes a LinearPositioningSystem just isn't long enough to have Anchors. It is VERY important that railML (if it's going to use relative LinearCoordinates) defines the exact method to use to define the Anchor measure on LinearPositioningSystem axis and the measure/offset from that Anchor along axis the LinearPositioningSystem (such as how to deal with LinearPositioningSystem axis voids).
NOTE 2: The anchor doesn't necessary have an integer as a label. It can be a string: 1, 1new, 1newest, 2, 3, 4 ....
NOTE 2: In some software systems, there is not a possibility to enter (when filling in the inventory) a distance from anchor that is greater than 999m. Sometimes these software systems will then in the backend use an interpolation to determine the exact LinearCoordinate. So when the distance between the anchors is 1100m, and the user enters 999, the resulting distance to anchor is 999/1000*1100=1098,9m
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
Members
Search
Help
Login
Home
