|
|
|
|
| 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   |
christian.rahmig
Messages: 523
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
|
|
|
|
| Re: Interpreting "begin" and "end" in the sub elements <linearCoordinateBegin> and <linearCoordinateEnd> [message #3726 is a reply to message #3555] |
Wed, 24 September 2025 13:52 |
Mathias Vanden Auweele
Messages: 82
Registered: February 2025
Location: Brussels
|
Member |
|
|
Hello all, and thank you for raising and discussing this!
I understand the @applicationDirection as it was first introduced in RTM v1.0 and written in the IRS 30100:
IRS 30100
normal: "the located object is valid in the direction of the LinearLocation"
reverse: "the located object is valid in the reverse direction of the LinearLocation"
both: "the located object is valid in both directions"
So what's important is that RTM 1.0 never referred to the direction of the <netElement> to interpret the @applicationDirection. Inherently the <linearLocation> already has a direction, by virtue of the @sequence and @intrinsicCoordBegin and @intrinsicCoordEnd. So @applicationDirection should thus refer to this direction and not to <netElement> direction.
So this:
<speedSection id="sps01" maxSpeed="110.0">
<linearLocation id="ll1" applicationDirection="normal">
<associatedNetElement netElementRef="ne01" intrinsicCoordBegin="0.6" intrinsicCoordEnd="1" seq="1" />
<associatedNetElement netElementRef="ne02" intrinsicCoordBegin="0" intrinsicCoordEnd="0.2" seq="2" />
</linearLocation>
<validForSpeedProfile ref="spprf01"/>
</speedSection>
Would have the same effect for me as this:
<speedSection id="sps01" maxSpeed="110.0">
<linearLocation id="ll1" applicationDirection="reverse">
<associatedNetElement netElementRef="ne01" intrinsicCoordBegin="1" intrinsicCoordEnd="0.6" seq="2" />
<associatedNetElement netElementRef="ne02" intrinsicCoordBegin="0.2" intrinsicCoordEnd="0" seq="1" />
</linearLocation>
<validForSpeedProfile ref="spprf01"/>
</speedSection>
I never visited and read the wiki documentation for this attribute, but I see that it's interpretation has changed for the worse :( and this has caused the current confusion.
Now I do wonder when it would be useful to ever state @applicationDirection="reverse". I think this is redundant as you could just as well reverse the direction as defined by the <associatedNetElement>s. I could see two use cases:
1) when you have a set of <associatedNetElement> that are reused by multiple <linearLocations> but some need to use the same <associatedNetElement> but in the reverse direction. That's impossible in railML XML but is done by Bane NOR in the knowledge graph.
2) To easily allow a user to change the direction in some application UI. (but then there could just as well be a logically disconnect between the data model and the UI to add this feature)
So as far as I can see, there are two options:
1) return to the definition as originally intended by the RTM v1.0 (and accept that @applicationDirection="reverse" most likely will not be used
2) remove @applicationDirection from <linearLocation> and replace it with a new attribute @appliesInBothDirectons (or equivalent) for which the default would be "False".
I'll be happy to hear your comments on my proposal! Thanks
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
[Updated on: Wed, 24 September 2025 13:59] Report message to a moderator |
|
|
|
| Re: Interpreting "begin" and "end" in the sub elements <linearCoordinateBegin> and <linearCoordinateEnd> [message #3727 is a reply to message #3726] |
Wed, 24 September 2025 17:24 |
Thomas Nygreen
Messages: 108
Registered: March 2008
|
Senior Member |
|
|
Dear Mathias,
I just want to note that the documentation of attributes and elements in railML 3 is consistent between the UML, the XSD, the wiki and any other derived export, and I recommend any developer using railML to read and rely on this documentation  The documentation of @applicationDirection has been unchanged since the first railML 3.1 beta was released in October 2017 (based on RTM 1.1), and has always been "direction in which the element is applied, related to the orientation of the <netElement>" (both for <spotLocation> and <linearLocation>). However, railML and RTM are revised and improved with every new version, so it is never to late to suggest changes 
I think your reference to the section from IRS 30100 is very relevant, and I don't know why there is a difference between the interpretation in IRS 30100 and later RTM versions or their implementation in railML. The corresponding documentation of applicationDirection for SpotLocation in IRS 30100 is less precise, but there the intension seems to be the same as currently documented in railML.
I have been wondering if @applicationDirection is needed for <linearLocation> at all, if we apply a definition in line with what Dominik and now you suggest. Can you (or anyone else) provide examples where "both" is used and necessary?
Best regards,
Thomas
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
[Updated on: Wed, 24 September 2025 17:27] Report message to a moderator |
|
|
|
| Re: Interpreting "begin" and "end" in the sub elements <linearCoordinateBegin> and <linearCoordinateEnd> [message #3728 is a reply to message #3727] |
Wed, 24 September 2025 18:22 |
Mathias Vanden Auweele
Messages: 82
Registered: February 2025
Location: Brussels
|
Member |
|
|
/ off topic
@Thomas: I'm not sure why you start pointing out to me that every railML developer needs to read and rely on the railML documentation. I didn't want to give any impression that I'm not doing that. I just stated that for this particular case, @applicationDirection for <linearLocation>, I didn't do so because I thought I understood it based on RTM v1.0.
However I do want to comment on a couple of statements that you are making. This is a bit of topic, but you started it :)
Quote:I just want to note that the documentation of attributes and elements in railML 3 is consistent between the UML, the XSD, the wiki and any other derived export
That's not true for everything: https://www.railml.org/forum/index.php?t=msg&th=1076& ;start=0&
Quote:However, railML and RTM are revised and improved with every new version, ..
Good that you say "revised and improved" and not just "improved" :)
https://www.railml.org/forum/index.php?t=msg&th=1058& ;start=0&
/ back on topic!
To answer your question:
Quote:I have been wondering if @applicationDirection is needed for <linearLocation> at all, if we apply a definition in line with what Dominik and now you suggest. Can you (or anyone else) provide examples where "both" is used and necessary?
There are more cases where @applicationDirection="both" applies than where "normal" would apply. Examples:
- platformEdges
- track
- default speed sections (for when you don't know the speed but don't want any application to assume an unlimited speed..)
- Generally, everything that could have an arealocation instead of a linearlocation such as electrificationSection, levelCrossingIS, line, loadingGauge, overCrossing, ...
I would rather say that the list of classes where you would put @applicationDirection<>"both" is rather limited. SpeedSections... Maybe some more signaling elements such as trainDetection or protection? Carwash installations where you can only enter from a certain direction?
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
|
|
| Re: Interpreting "begin" and "end" in the sub elements <linearCoordinateBegin> and <linearCoordinateEnd> [message #3826 is a reply to message #3744] |
Tue, 09 December 2025 14:05 |
Thomas Nygreen
Messages: 108
Registered: March 2008
|
Senior Member |
|
|
Dear Mathias,
My comment was a reaction to the statement you made about the "wiki documentation", as if this is not the same official railML documentation as in the other sources. I apologise for the unnecessary snideness. Unfortunately, the order of child elements is actually consistently (i.e. not) documented. It is only shown by the syntax of the XSD. But this will be fixed, so it is also documented in the Wiki.
I could have been clearer when asking for examples. What I was after are cases where the same type of element in some cases has applicationDirection "normal" and in other cases "both". Apart from speed, I think all of the examples you mention will always have applicationDirection="both", making it redundant. Speeds with "both" is a controversial topic, and a two-way speed section can easily be split into two one-way sections.
I agree that removing "reverse" or replacing the attribute with a boolean flag simplifies the modelling. If we are sure that we have no examples where the flag is needed (as in sometimes true and sometimes false for the same type of element), we can further simplify by removing it.
Best regards,
Thomas
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: Interpreting "begin" and "end" in the sub elements <linearCoordinateBegin> and <linearCoordinateEnd> [message #3828 is a reply to message #3826] |
Tue, 09 December 2025 15:43 |
Mathias Vanden Auweele
Messages: 82
Registered: February 2025
Location: Brussels
|
Member |
|
|
Dear Thomas
Quote:My comment was a reaction to the statement you made about the "wiki documentation", as if this is not the same official railML documentation as in the other sources. I apologise for the unnecessary snideness. Unfortunately, the order of child elements is actually consistently (i.e. not) documented. It is only shown by the syntax of the XSD. But this will be fixed, so it is also documented in the Wiki.
I was probably a bit brief in my answer. My intention was to reference the topic again so that we wouldn't lose sight of it :)
Quote:I could have been clearer when asking for examples. What I was after are cases where the same type of element in some cases has applicationDirection "normal" and in other cases "both". Apart from speed, I think all of the examples you mention will always have applicationDirection="both", making it redundant. Speeds with "both" is a controversial topic, and a two-way speed section can easily be split into two one-way sections.
I don't know of any case where the same type of element could have different applicationDirections. Though I'm not sure I would agree with the conclusion that might come next "then we don't need to specify the applicationDirection because it can be inferred by the element type". I think this is one of those cases where I would agree to spend a few bits on adding clarity :)
Though I won't be completely against it either. Just as long as we preserve the property inside the RTM model. In the railML XSD it can be removed, but it should definitely be kept in RTM.
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
Members
Search
Help
Login
Home
