| [railML3] @lateralSide and @verticalSide and distances [message #3759] |
Thu, 23 October 2025 15:23  |
Mathias Vanden Auweele
Messages: 165 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: 578 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 scheme 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: 165 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: 165 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
|
|
|
|