| [railML3] Positioning approach [message #3125] |
Mon, 04 September 2023 12:49  |
christian.rahmig
Messages: 436
Registered: January 2016
|
Senior Member |
|
|
Dear all,
Positioning is an important topic, also in railML 3. However, the railML 3.2 data model and schema basically provides different options for specifying a position in a certain coordinate reference system and/or the topology network. This variety of options results from the schema syntax where most elements and attributes are optional. While this variety is very comfortbale for a railML export interface (because you can export whatever suits you best), it causes problems on the side of the railML importer, which need to be able to understand all the different options in the same manner and be able to convert one solution into the other one without any ambiguities.
Considering this challenge, we discussed the positioning topic in our different use case working groups (SCTP, NEST, ETCS) and agreed on a proposal for a ruling framework that limits the variety of how to model positions in railML 3.x. This proposal is documented in the slides [1]. This presentation is in a working draft stage and we would like to collect feedback of the community.
The suggested approach summarized in three points:
(1) Every NetElement has to have an associatedPositioningSystem linking to a so-called "intrinsic positioning system" usable as measuring tape. This associatedPositioningSystem realizes the mapping between the intrinsic coordinates (0..1) and the measuring tape.
(2) Every located functional infrastructure element need to have at least one spotLocation or linearLocation or areaLocation.
(3a) For a spotLocation: define the position either with @intrinsicCoord or linearCoordinate@measure referencing the intrinsic positioning system.
(3b) For a linearLocation: define the position either with @intrinsicCoordBegin / @intrinsicCoordEnd or linearCoordinateBegin@measure / linearCoordinateEnd@measure referencing the intrinsic positioning system.
So, after we already got first feedback from the railML use case working groups, I want to ask the whole railML community to provide us with their thoughts, comments and ideas, directly here in the forum. Please focus on:
* Is the approach understandable (also in its documentation)?
* Do you agree with the approach?
* Is there something missing?
As usual, any kind of feedback is highly appreciated...
[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
|
|
|
|
| Re: [railML3] Positioning approach [message #3156 is a reply to message #3125] |
Thu, 02 November 2023 17:09  |
Karl-Friedemann Jerosch
Messages: 11
Registered: May 2020
|
Junior Member |
|
|
Dear Christian,
concerning your general questions:
- Yes, we understand the approach.
- We cannot fully agree with the suggestion. Details see attached file.
Summary:
- We agree to have intrinsic coordinates for netElements to define their orientation (0.0 and 1.0).
Additionally, each end of a netElement should have a linearCoordinate with absolute kilometer value
(using linearCoordinate with @positioningSystemRef and @measure).
- The location of other infrastructure and interlocking elements positioned on netElements should be given by using @pos (for spotLocations) or @posBegin and @posEnd (for linearLocation or areaLoction).
Additionally, as lower priority, the location can be provided by linearCoordinate (using linearCoordinate with @positioningSystemRef and @measure) to provide different kilometer systems (e.g. a linearPositioningSystem from infrastructure manager and/or another linearPositioningSystem from ETCS measurement).
- We would avoid to use intrinsic coordinates for infrastructure and interlocking elements (except netElements), because to get the absolute kilometer value of a location, conversion calculations are necessary which will result in rounding problems.
Means: To calculate the location, the intrinsic coordinates must be multiply with the netElement's length and this will result in rounding problems.
- After an expectable discussion, the documentation of railML.org should be updated accordingly including minor corrections (see attached file).
Martin Zien & Karl-F. Jerosch
[Updated on: Mon, 04 December 2023 11:00] Report message to a moderator |
|
|
|
| Re: [railML3] Positioning approach [message #3159 is a reply to message #3156] |
Mon, 06 November 2023 19:31 |
Thomas Nygreen
Messages: 68
Registered: March 2008
|
Member |
|
|
Dear Christian,
The linearCoordinate and geometricCoordinate children of linearLocation should be removed to stay consistent with the use that you are describing. And I would prefer either a clear documentation of when to use linearLocation versus areaLocation, or removing the latter. Should a level/over/underCrossing that crosses a multitrack line have one linearLocation for each track or an areaLocation for all tracks? Is a switch a linear or an area element?
Best regards,
Thomas
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] Positioning approach [message #3160 is a reply to message #3159] |
Wed, 08 November 2023 06:46 |
christian.rahmig
Messages: 436
Registered: January 2016
|
Senior Member |
|
|
Dear Thomas,
thank you for your feedback and input to complete the refactoring of the locations. Yes, we still have to talk about the linearCoordinate and geometricCoordinate children of linearLocation and areaLocation, which result from the RTM modelling.
If you want to model a (linear or area) location with reference to the topology layer (netElements...), you have to do it using associatedNetElement and relevant child elements and attributes. So, the remaining question is if we should allow for linearLocation or areaLocation without reference to the topology? Btw: a spotLocation is always linked with the topology...
So, in order to harmonize the approach with spotLocation, I agree with your suggestion to deprecate linearCoordinate and geometricCoordinate in linearLocation and areaLocation. And if someone really needs to define a location without a reference to the topology, he or she may still make use of the gmlLocations and its child elements lineString and point.
Question to the community:
Who is using the child elements linearCoordinate and geometricCoordinate in elements linearLocation and areaLocation?
Any feedback is highly appreciated...
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
|
|
|
Members
Search
Help
Login
Home
