|
Re: @keepsOrientation in Track object [message #2774 is a reply to message #2756] |
Fri, 25 June 2021 15:13 |
christian.rahmig
Messages: 465 Registered: January 2016
|
Senior Member |
|
|
Dear Benoit,
welcome to the railML community and thank you very much for this very interesting question! Both solutions can be argumented and both solutions are possible from a technical perspective. Therefore, let's push this question to the railML 3.1 users: Which solution did you implement in your railML 3.1 exporting tool?
Any feedback is very much appreciated...
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Re: @keepsOrientation in Track object [message #2935 is a reply to message #2807] |
Mon, 07 March 2022 13:01 |
christian.rahmig
Messages: 465 Registered: January 2016
|
Senior Member |
|
|
Dear all,
as there has been no requests from the community and examples for intended usage, I propose to deprecate the attribute @keepsOrientation with upcoming railML 3.2. If you have any interest in keeping this attribute, please comment here in the forum until Friday, 11.03.2022. There is already a Git issue mentioning a missing documentation: https://development.railml.org/railml/railtopomodel/-/issues/3
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Re: @keepsOrientation in Track object [message #3099 is a reply to message #2974] |
Wed, 21 June 2023 10:28 |
Jan Gruteser
Messages: 2 Registered: June 2023 Location: Düsseldorf
|
Junior Member |
|
|
Dear all,
I am late to this discussion, but I currently have an implementation that relies heavily on this attribute.
At the moment I am writing my master's thesis at the Heinrich-Heine-University in Düsseldorf in the context of formal methods. We are trying to import railML 3 into the formal B Method, namely ProB (prob.hhu.de), which allows to check and validate properties of the resulting model by formal methods, animation, and also simulation in combination with visualisation.
There is a need to describe formally how the netElements are connected and this is done by (mathematical) relations which take the intrinsic coordinates of the netElements and connects them as stated in netRelations. When defining tracks this is done by linear locations with certain associatedNetElements. As far as I understood, posBegin and posEnd are always used in an increasing way, i.e. posBegin < posEnd, even when the intrinsic coordinates for the netElement according to the specified sequence would decrease. To keep the directional data correct in the formal relation, I use the attribute "keepsOrientation". For me it seems, that it exactly stores this property, i.e. it is true, if posBegin < posEnd and according to the sequence we also travel from 0.0 to 1.0 within the netElement (false otherwise).
In my opinion, this technique can be observed in the Advanced Example.
As this attribute is deprecated now: How can I obtain this information in another way?
Thank you and kind regards
Jan Gruteser
|
|
|
Re: @keepsOrientation in Track object [message #3101 is a reply to message #3099] |
Mon, 03 July 2023 12:39 |
christian.rahmig
Messages: 465 Registered: January 2016
|
Senior Member |
|
|
Dear Jan,
you can model linear locations spanning over several associated NetElements also without the attribute @keepsOrientation.
Let's take the element <line> in the railML Simple Example. It spans over three NetElements (in mesoscopic level). Now, let's assume that the NetElement in the middle is oriented in opposite direction. If you model the location with intrinsic coordinates, the source code looks like this:
<linearLocation id="lin01_lloc01" applicationDirection="both">
<associatedNetElement netElementRef="ne_a11" intrinsicCoordBegin="0" intrinsicCoordEnd="1" />
<associatedNetElement netElementRef="ne_x11" intrinsicCoordBegin="1" intrinsicCoordEnd="0" />
<associatedNetElement netElementRef="ne_b11" intrinsicCoordBegin="0" intrinsicCoordEnd="1" />
</linearLocation>
If you want to use the intrinsic positioning system (usable for length and distance measurements) instead of intrinsic coordinates, the source code looks like this:
<linearLocation id="lin01_lloc02" applicationDirection="both">
<associatedNetElement netElementRef="ne_a11">
<linearCoordinateBegin positioningSystemRef="ips" measure="0.0"/>
<linearCoordinateEnd positioningSystemRef="ips" measure="700.0"/>
</associatedNetElement>
<associatedNetElement netElementRef="ne_x11">
<linearCoordinateBegin positioningSystemRef="ips" measure="3600.0"/>
<linearCoordinateEnd positioningSystemRef="ips" measure="0.0"/>
</associatedNetElement>
<associatedNetElement netElementRef="ne_b11">
<linearCoordinateBegin positioningSystemRef="ips" measure="0.0"/>
<linearCoordinateEnd positioningSystemRef="ips" measure="700.0"/>
</associatedNetElement>
</linearLocation>
Please use one of these two approaches for modelling the linear location of the line. In addition, you are free to add the mileage (line kilometer reference system) as another coordinate system. The resulting source code may look like this (as you see, this mileage is independent from the NetElement orientation):
<linearLocation id="lin01_lloc03" applicationDirection="both">
<associatedNetElement netElementRef="ne_a11">
<linearCoordinateBegin positioningSystemRef="lps01" measure="0.0"/>
<linearCoordinateEnd positioningSystemRef="lps01" measure="700.0"/>
</associatedNetElement>
<associatedNetElement netElementRef="ne_x11">
<linearCoordinateBegin positioningSystemRef="lps01" measure="700.0"/>
<linearCoordinateEnd positioningSystemRef="lps01" measure="4300.0"/>
</associatedNetElement>
<associatedNetElement netElementRef="ne_b11">
<linearCoordinateBegin positioningSystemRef="lps01" measure="4300.0"/>
<linearCoordinateEnd positioningSystemRef="lps01" measure="5000.0"/>
</associatedNetElement>
</linearLocation>
Does this sound fine for you? Please give us a feedback or write your further questions.
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Re: @keepsOrientation in Track object [message #3121 is a reply to message #3107] |
Mon, 04 September 2023 09:50 |
christian.rahmig
Messages: 465 Registered: January 2016
|
Senior Member |
|
|
Dear Jan,
thank you for your feedback and apologies for the long answering time due to vacations...
The minimalistic example you presented is syntactically correct, but it is not usable. In railML 3 development working groups we discussed the topic of positioning in the past weeks and months and we came to the conclusion that we have to set some rules in order to make modelling of positions unambiguous. The analysis of the various positioning options and the concluded modelling approach are documented in the concept presentation [1].
So, according to this approach, it is not feasible to have a linear location without both, the intrinsic coordinates and linear coordinates in the intrinsic positioning system. You have to use one of these two options.
As this concept presentation is still a draft, railML community will have the chance to decide whether this approach will become active with railML 3.3 or already with railML 3.2.
[1] https://cloud.railml.org/s/m8JGaBsARjmoD2m
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|