| [railML3] @lateralSide and @verticalSide and distances [message #3759] |
Thu, 23 October 2025 15:23  |
Mathias Vanden Auweele
Messages: 174
Registered: February 2025
Location: Brussels
|
Senior Member |
|
|
Currently, the only way to give a lateral side for a location is to also give a linear positioning coordinate. Conceptually, this is strange, since these properties are actually on the same level as @applicationDirection.
Furthermore, there can be an issue with conflicting data. An <AssociatedNetElement> has a <LinearCoordinateBegin> and <..End>. So potentially, one can have @lateralSide = "left" and the other "right". That would be a very confusing platformEdge!
And what about an <AreaLocation>? Now it's possible to also define these properties although I can't imagen any case where it would be useful.
I would like to propose to move these properties to the level of the <LinearLocation> and the <SpotLocation>
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
|
|
| Re: [railML3] @lateralSide and @verticalSide and distances [message #3787 is a reply to message #3786] |
Mon, 17 November 2025 13:33  |
christian.rahmig
Messages: 590
Registered: January 2016
|
Senior Member |
|
|
Dear Mathias and Jim,
thanks for bringing up this topic.
Now please think of the following situation: you have a platform edge spanning over at least two netElement objects. The netElement objects have different orientation. As the @lateralSide depends on the orientation of the netElement, you would have two different @lateralSide values to describe the lateral location of the platform edge. There would be no changes to @verticalSide though.
Regarding areaLocation: Think of an island platform between two tracks, which you want to locate in the network. This would be possible with an areaLocation linking the two netElement objects under these tracks. If the netElement objects are oriented the same way, you would have again different @lateralSide values - one for each netElement. Yes, you are right, there are better ways to model this scenario: use two platformEdge elements instead of (or additional to) one platform object.
Best regards
Christian
Christian Rahmig – Infrastructure schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] @lateralSide and @verticalSide and distances [message #3788 is a reply to message #3787] |
Wed, 19 November 2025 10:42 |
Mathias Vanden Auweele
Messages: 174
Registered: February 2025
Location: Brussels
|
Senior Member |
|
|
Hello Christian,
Thank you for looking into this.
Quote:Now please think of the following situation: you have a platform edge spanning over at least two netElement objects. The netElement objects have different orientation. As the @lateralSide depends on the orientation of the netElement, you would have two different @lateralSide values to describe the lateral location of the platform edge. There would be no changes to @verticalSide though.
No, @lateralSide should not depend on the orientation of the <NetElement>. If the @lateralSide is defined on the <LinearLocation>, it should behave in the same way as the @applicableDirection. Independent on the orientation of the underlying <NetElement> of the <AssociatedNetElement>s. The <LinearLocation> has a direction, going from the @intrinsicCoordBegin of the first <AsscociatedNetElement> to the @intrinsicCoordEnd of the last <AssociatedNetElement>. That direction allows to define the left and right sides.
Quote:
Regarding areaLocation: Think of an island platform between two tracks, which you want to locate in the network. This would be possible with an areaLocation linking the two netElement objects under these tracks. If the netElement objects are oriented the same way, you would have again different @lateralSide values - one for each netElement. Yes, you are right, there are better ways to model this scenario: use two platformEdge elements instead of (or additional to) one platform object.
For <AreaLocations> it would make slightly more sense to set the @lateralSide attribute to the <AssociatedNetElement>, given that the <AreaLocation> doesn't really have a direction per se. You could still set it on the <AreaLocation> but then why isn't there the @applicableDirection attribute defined on it either? If there would be both, they could be conflicting. In any case, again I would not look at <AreaLocation> and keep the @applicableSide solely on the <LinearLocation> and <SpotLocation>
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
| Re: [railML3] @lateralSide and @verticalSide and distances [message #4062 is a reply to message #3788] |
Mon, 22 June 2026 23:25 |
Mathias Vanden Auweele
Messages: 174
Registered: February 2025
Location: Brussels
|
Senior Member |
|
|
After a meeting between BaneNOR and railML, we come to the following proposal:
The attributes @lateralSide, @lateralDistance, @verticalSide and @verticalDistance will be removed from the <linearCoordinate> and moved to the <spotLocation> and <linearLocation> elements.
The reference for what is "left" and "right" for a <spotLocation> is determined by the <netElement> to which it refers to.
The reference for what is "left" and "right" for a <linearLocation> is determined by the direction of the <linearLocation> itself. It has a sequence of <associatedNetElement>s that each have a @intrinsicCoordinateBegin and @intrinsicCoordinateEnd that determines the direction of the <linearLocation>.
The <AreaLocation> will not have these attributes. The only Infrastructure entity that we could think of that might have an arealocation and is in need of defining the side, is the <Platform>. However, this can easily be solved by either 1) referring to the <platformEdge>s and not defining a location for the platform or 2) adding two <linearLocation> to the <platform>.
Here's an example for the spotlocation:
Current:
<spotLocation intrinsicCoordinate='0.5' applicationDirection='Normal'>
<linearCoordinate lateralSide='Left'>
Proposal:
<spotLocation lateralSide='Left' intrinsicCoordinate='0.5' applicationDirection='Normal'>
And the linearlocation:
Current:
<LinearLocation applicationDirection='Normal'>
<AssociatedNetElement ref='A' IntrinsicCoordinateBegin='0.5' IntrinsicCoordinateBegin='1' seq='1'>
<LinearCoordinateBegin lateralSide='Left'>
<LinearCoordinateEnd lateralSide='Left'>
<AssociatedNetElement ref='B' IntrinsicCoordinateBegin='0' IntrinsicCoordinateBegin='1' seq='2'>
<LinearCoordinateBegin lateralSide='Left'>
<LinearCoordinateEnd lateralSide='Left'>
<AssociatedNetElement ref='C' IntrinsicCoordinateBegin='0' IntrinsicCoordinateBegin='0.7' seq='3'>
<LinearCoordinate lateralSide='Left'>
<LinearCoordinateEnd lateralSide='Left'>
Proposal:
<LinearLocation applicationDirection='Normal' lateralSide='Left'>
<AssociatedNetElement ref='A' IntrinsicCoordinateBegin='0.5' IntrinsicCoordinateBegin='1' seq='1'>
<AssociatedNetElement ref='B' IntrinsicCoordinateBegin='0' IntrinsicCoordinateBegin='1' seq='2'>
<AssociatedNetElement ref='C' IntrinsicCoordinateBegin='0' IntrinsicCoordinateBegin='0.7' seq='3'>
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
[Updated on: Tue, 23 June 2026 12:20] Report message to a moderator |
|
|
|
|
|
| Re: [railML3] @lateralSide and @verticalSide and distances [message #4186 is a reply to message #4185] |
Tue, 15 September 2026 00:17 |
Thomas Nygreen
Messages: 137
Registered: March 2008
|
Senior Member |
|
|
Dear all,
Would it make sense to move @lateralSide and @verticalSide, but keep @lateralDistance and @verticalDistance in the coordinates? Repeated measurements, included as multiple linear coordinates, may very well have slightly different lateral/vertical offsets. Remember: the offsets are part of linear referencing systems.
Best regards,
Thomas
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] @lateralSide and @verticalSide and distances [message #4193 is a reply to message #4186] |
Wed, 16 September 2026 11:52 |
Mathias Vanden Auweele
Messages: 174
Registered: February 2025
Location: Brussels
|
Senior Member |
|
|
@Thomas, introducing the word 'measurements' is opening a box of pandora :)
Many properties can change when remeasuring, linear coordinates are not the only one, also intrinsic and geometric. I'm not sure what railML files are meant to contain, nominal values, measurements, estimates... Is there maybe a metadata element that can clarify this? Otherwise I guess that information is transmitted by other means.
I don't think there's a construct currently in railml that allows to say: "this is the design parameter, this is the as build parameter and this is the measurement value of that parameter of the mesurement that we did yesterday".
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
| Re: [railML3] @lateralSide and @verticalSide and distances [message #4197 is a reply to message #4193] |
Fri, 18 September 2026 20:22 |
Thomas Nygreen
Messages: 137
Registered: March 2008
|
Senior Member |
|
|
Dear Mathias,
I simply mentioned one of the uses I've seen of multiple parallel LPSs. Thinking about it, that case may still fit better into separate location elements, even given [1], so it may not be relevant. For something that truly is the same location, these offsets should not change unless we use different baselines for the different LPSs (but the current assumption is that everyone is using track center).
It gets stranger when combining lateral and vertical offsets with geometric coordinates. If we separate the lateral and vertical offsets from the linear coordinate and move them up to *Location, so that the linearCoordinate is in the middle of the track and a complete linear coordinate is made by combining the linearCoordinate and the offsets in the *Location, should we interpret a geometricCoordinate in the same way? Let's say you provide a signal with a spotLocation that has a lateralSide, a lateralDistance, a linearCoordinate and a geometricCoordinate. Is the geometricCoordinate pointing to the same place as the linearCoordinate (and they should both be offset laterally and vertically) or do the offsets only apply to the linearCoordinate children? In the latter case, why not place them there?
Depending on how the final positioning model looks after [1], the offsets could also be placed on topologicalCoordinate or both on the linearCoordinate and intrinsicCoordinate.
Normally a railML file is a snapshot in time. To some extent it is possible to include an element repeatedly with different properties and different validity periods. But that is truly a Pandora's jar (box is a mistranslation) that we'll need to open somewhere else. Metadata can be used to describe the temporal coverage, the file's validity and subject matter using structured data or more generally describe the contents in free text. But this is all a bit tangential to the topic here.
[1] https://www.railml.org/forum/index.php?t=msg&th=1058& ;goto=4063&#msg_4063
Best regards,
Thomas
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] @lateralSide and @verticalSide and distances [message #4205 is a reply to message #4197] |
Wed, 23 September 2026 22:51 |
Mathias Vanden Auweele
Messages: 174
Registered: February 2025
Location: Brussels
|
Senior Member |
|
|
Quote:unless we use different baselines for the different LPSs
This feels like something to clarify in RTM as a global standard instead of something that can be defined by the LPS owner.
Quote:should we interpret a geometricCoordinate in the same way? Let's say you provide a signal with a spotLocation that has a lateralSide, a lateralDistance, a linearCoordinate and a geometricCoordinate. Is the geometricCoordinate pointing to the same place as the linearCoordinate (and they should both be offset laterally and vertically) or do the offsets only apply to the linearCoordinate children? In the latter case, why not place them there?
For me, everything relates to a topological position here. The NetEntity is the effect of something on the network/topology. That something is not being located, but it's effect is located. So the geometric coordinates should not indicate the coordinates of the signals pole, but the point in the topology.
The lateral and vertical offsets are annoying distractions for me that don't really fit into RTM. They try too hard to speak about "the thing" instead of "it's effect". They fit much better in infrastructure elements that are furthermore also located with gml descriptions. The lateralSide and verticalSide are different since they can be seen as 'this side of the topology location'. That's very relevant for a platformEdge, but not so relevant for a signal.
My view on this is probably not shared by everyone.
Quote:Normally a railML file is a snapshot in time. To some extent it is possible to include an element repeatedly with different properties and different validity periods. But that is truly a Pandora's jar (box is a mistranslation) that we'll need to open somewhere else. Metadata can be used to describe the temporal coverage, the file's validity and subject matter using structured data or more generally describe the contents in free text. But this is all a bit tangential to the topic here.
Yes, I agree (interesting about the jar, I wasn't aware, thanks). We should just be a little careful about this point when building the railML ontology. That's different from "a file", since it's purpose is not in a specific container with specific metadata. At least, that's not how we are using it in DIM (and not how ERA is building their ontology). I'm yet to find out, what the intentions of railML are with it.
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
Members
Search
Help
Login
Home
