Home » railML newsgroups » railML.infrastructure » Interpreting "begin" and "end" in the sub elements <linearCoordinateBegin> and <linearCoordinateEnd>
Interpreting "begin" and "end" in the sub elements <linearCoordinateBegin> and <linearCoordinateEnd> [message #3541] Mon, 07 April 2025 10:22 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 180
Registered: March 2016
Senior Member
There seems to be an ambiguity in the meaning of "begin" and "end" in the sub elements <linearCoordinateBegin> and <linearCoordinateEnd> in <linearLocation/associatedNetElement> [1]

Ref documentation of <linearCoordinateBegin> [2]:
"linear coordinate of the beginning of area covered by some functional IS entity"

Some interpret begin and end to be in the direction of the net element. Others see it in the application direction of the (functionalInfrastructure) object that creates the linear location.
I have seen (certified) code examples for both. So, I suggest allowing the ambiguity for now. But to discuss if we should make it more consistent in railML 3.4.

We could also discuss to make it at least a bit more consistent for now to add the following sematic constraint or best
practice:
If you are using linearLocation@applicationDirection then <linearCoordinateBegin> and <linearCoordinateEnd> follows the direction of the net element. If linearLocation@applicationDirection is NOT set, then <linearCoordinateBegin> and <linearCoordinateEnd> follows the application direction of the (functionalInfrastructure) object.

See also related post #3297 [3]


[1] https://wiki3.railml.org/wiki/RTM:associatedNetElement#3.3-0
[2] https://wiki3.railml.org/wiki/RTM:linearCoordinateBegin#3.3- 0
[3] https://www.railml.org/forum/index.php?t=msg&goto=3297&a mp;&srch=linearCoordinateBegin#msg_3297

Report message to a moderator

Re: Interpreting "begin" and "end" in the sub elements <linearCoordinateBegin> and <linearCoordinateEnd> [message #3551 is a reply to message #3541] Tue, 08 April 2025 16:55 Go to previous messageGo to next message
Dominik Looser is currently offline  Dominik Looser
Messages: 24
Registered: March 2020
Junior Member
Dear community,

Thank you Torben for bringing up this topic.

We export linearLocations without applicationDirection, because the direction of the functional element is implicitly defined by the attributes intrinsicCoordBegin/End, posBegin/End and/or the subelements linearCoordinateBegin/End of each associatedNetElement.

Your semantic constraint suggestion sounds like a good idea to handle the different interpretations of this topic.

Best regards,
Dominik Loooser

Report message to a moderator

Re: Interpreting "begin" and "end" in the sub elements <linearCoordinateBegin> and <linearCoordinateEnd> [message #3555 is a reply to message #3551] Wed, 09 April 2025 22:29 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 505
Registered: January 2016
Senior Member
Dear all,

it's time to clarify few things related to linear locations, which seem to miss proper documentation so far:

A <linearLocation> has an orientation. This orientation is defined by the <*Begin> and <*End> child elements or the @intrinsicCoordBegin and @intrinsicCoordEnd attributes of all the <associatedNetElement> instances that are at least partly covered by this <linearLocation>. In that context, it does not matter, whether the *Begin value is smaller or bigger than the *End value.

In particular: Both of the following (simple) examples are valid linear locations on one netElement:

(1a)
[0------ne_a1-------(lloc_begin)-------------(lloc_end)----- ---1 >

(2a)
[0------ne_a1-------(lloc_end)-------------(lloc_begin)----- ---1 >

Consequently, the orientation of the <linearLocation> is independent from the orientation of the <netElement>.

Now, what does that look like if the <linearLocation> covers multiple <netElement> elements (with changing orientation) via <associatedNetElement> instances. Adapting above examples looks like this:

(1b)
[0------ne_a1-------(lloc_begin1)--------(lloc_end1)1><1(lloc_begin2)----(lloc_end2)--------0]

(2b)
[0------ne_a1-------(lloc_end2)--------(lloc_begin2)1><1(lloc_end1)----(lloc_begin1)--------0]

The orientation of the covered <netElement>s did not change, but the orientation of the <linearLocation> did.

Now, what is the @applicationDirection of the <linearLocation>? Is it the same like the orientation of the <linearLocation>? No, but it can match with it. The @applicationDirection describes the direction of driving for which the functional infrastructure element is valid. Think of a <speedSection>: This linear element has clearly an application direction. Now, think of a <platformEdge>: This linear element has no specific application direction, because trains can use this platform edge no matter from which side they come. However, the <linearLocation> of the <platformEdge> has an orientation defined by *Begin and *End values.

The remaining question is: What is the reference of @applicationDirection value? Should it be the orientation of the <linearLocation> defined by *Begin and *End values? Or should it be the orientation of the <netElement> covered by the <associatedNetElement> with the lowest @sequence number?

To answer this question, I am happy to hear/read your opinions...

Best regards
Christian

PS: Yes, there is a semantic constraint related to a <linearLocation> ranging over several <associatedNetElement> instances. It says that there must be no gap between the *End value of the first <associatedNetElement> and the *Begin value of the next <associatedNetElement>...

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Previous Topic: [railML 2] Semantic Constraint at trackBegin and trackEnd
Next Topic: Station borders
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sat May 03 19:33:29 CEST 2025