| [railML3] Interpreting @applicationDirection of <linearLocation> [message #3297] |
Tue, 03 September 2024 19:12  |
Larissa Zhuchyi
Messages: 49
Registered: November 2022
|
Member |
|
|
Dear all,
This post deals with an ambiguity we found when specifying the location of an oriented functional infrastructure element when using <linearLocation>.
<linearLocation> as well as <spotLocation> have an attribute @applicationDirection, which is used to indicate the orientation of a functional infrastructure element in regards to the orientation of the underlying netElement. As <spotLocation> can refer only to one <netElement> there is no problem in interpretation. However, <linearLocation> can have an ordered list of <associatedNetElement>s each referring to a <netElement>. The direction of definition may vary between these referenced <netElements>. Therefore, it is not clear to which <netElement> of <linearLocation> its attribute @applicationDirection is referring. Below we suggest how to interpret this to resolve ambiguity.
Please let us know:
1) If you agree with suggested approach;
2) If no room for misinterpretation is left.
Currently @applicationDirection is defined as follows "direction in which the element is applied, related to the orientation of the <netElement>".
railML.org's suggestion: within a list of <associatedNetElement>s of one <linearLocation> the attribute @applicationDirection should be linked with the <netElement> referred from the "first" <associatedNetElement>.
"First" <associatedNetElement> can be identified:
1) implicitly by linearCoordinateBegin/@measure that is not equal to linearCoordinate-/@measure of any other <associatedNetElement> within a list;
2) explicitly by the associatedNetElement with the lowest value of its attribute @sequence.
In the example below //linearCoordinateBegin/@measure="x" is not equal to any of //linearCoordinateEnd/@measure. Therefore @applicationDirection should be linked with "ne_q".
Therefore for example if applicationDirection is "normal", then <length> begins at point "x" and continues in the direction from intrinsicCoord="0" to intrinsicCoord="1" of netElement/@id="ne_q".
<overCrossing id="ov01">
<linearLocation id="sps01_lloc01" applicationDirection="k">
<associatedNetElement netElementRef="ne_q">
<linearCoordinateBegin positioningSystemRef="lps01" measure="x"/>
<linearCoordinateEnd positioningSystemRef="lps01" measure="y"/>
</associatedNetElement>
<associatedNetElement netElementRef="ne_f">
<linearCoordinateBegin positioningSystemRef="lps01" measure="y"/>
<linearCoordinateEnd positioningSystemRef="lps01" measure="p"/>
</associatedNetElement>
<length value="500.0" type="physical"/>
</linearLocation>
</overCrossing>
<netElement id="ne_q">
<associatedPositioningSystem id="ne_q_aps01">
<intrinsicCoordinate id="ne_q_aps01_ic01" intrinsicCoord="0">
<linearCoordinate positioningSystemRef="lps01" measure="j"/>
</intrinsicCoordinate>
<intrinsicCoordinate id="ne_q_aps01_ic02" intrinsicCoord="1">
<linearCoordinate positioningSystemRef="lps01" measure="y"/>
</intrinsicCoordinate>
</associatedPositioningSystem>
</netElement>
<netElement id="ne_f">
<associatedPositioningSystem id="ne_f_aps01">
<intrinsicCoordinate id="ne_f_aps01_ic01" intrinsicCoord="0">
<linearCoordinate positioningSystemRef="lps01" measure="y"/>
</intrinsicCoordinate>
<intrinsicCoordinate id="ne_f_aps01_ic02" intrinsicCoord="1">
<linearCoordinate positioningSystemRef="lps01" measure="z"/>
</intrinsicCoordinate>
</associatedPositioningSystem>
</netElement>
Sincerely,
Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] Interpreting @applicationDirection of <linearLocation> [message #3302 is a reply to message #3297] |
Wed, 04 September 2024 10:30  |
Milan Wölke
Messages: 145
Registered: April 2007
|
Senior Member |
|
|
Hi all,
in a recent discussion we came across a very similar question regarding how to specify the mainDirection of a track. We also came to the conclusion that the specified mainDirection would need to be determined in relation to the first of the specified associatedNetElements and then continued over the following associatedNetElements independent of the orientation of the those following netElements.
Would that also have been your conclusion when specifying a mainDirection of a track that spans over multiple netElements?
Best regards, Milan
Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] Interpreting @applicationDirection of <linearLocation> [message #3307 is a reply to message #3302] |
Wed, 04 September 2024 16:45 |
Thomas Nygreen
Messages: 75
Registered: March 2008
|
Member |
|
|
Dear all,
Item 1 in the suggested approach leads to a lot of comparisons when reading a file. Furthermore, it fails as soon as there is a mileage change or change of positioning system between the netElements. Mostly this has little consequence, as one will move on to item 2, but item 1 can incidentally provide the wrong order. Lastly, we need a tiebreaker if item 2 also fails.
I would rather say that the defining <associatedNetElement> is
1) The one with the lowest @sequence number (these should be unique, but if they are not, take the first of the lowest)
2) If no @sequence numbers are specified, the one listed first in the <linearLocation>
Best regards,
Thomas
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
