Home » railML newsgroups » railML.infrastructure » [railML3] Positioning approach (How to define unambiguous positions with railML 3.x)
[railML3] Positioning approach [message #3125] Mon, 04 September 2023 12:49 Go to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
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 Go to previous messageGo to next message
Karl-Friedemann Jerosch is currently offline  Karl-Friedemann Jerosch
Messages: 12
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 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 79
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 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
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
Re: [railML3] Positioning approach [message #3185 is a reply to message #3160] Wed, 17 January 2024 13:34 Go to previous messageGo to next message
Dominik Looser is currently offline  Dominik Looser
Messages: 23
Registered: March 2020
Junior Member
Dear all,

A feedback from our (trafIT solutions) side regarding mileage changes.
We agree with Siemens's feedback and would also prefer using <mileageChange> objects over <anchor>s as anchors cannot be assigned to a specific netElement. If a mileage change differs (even slightly) between two tracks of a double-track section, or especially in a curved station, only the <mileageChange>-element allows a precise modelling of the <mileageChange>-elements on each netElement.

Thank you and best regards,
Dominik Looser, trafIT solutions gmbh
Re: [railML3] Positioning approach [message #3220 is a reply to message #3185] Fri, 22 March 2024 13:54 Go to previous messageGo to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 49
Registered: November 2022
Member
Dear all

The initial link to the presentation on positioning expired. This is a new working link https://cloud.railml.org/s/m5SaBW44j2GZWok

Sincerely,


Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] Positioning approach [message #3273 is a reply to message #3160] Wed, 07 August 2024 16:22 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear Thomas,

as there has not been any further feedback from the community on the question about linearCoordinate and geometricCoordinate as child elements of linearLocation and areaLocation, I agree with the proposal to deprecate these two child elements. This means that in future there will be no linearLocation or areaLocation without a topology reference via associatedNetElement.

The related Git issue for railML 3.3 has already been created: https://development.railml.org/railml/version3/-/issues/556

Best regards
Christian


christian.rahmig wrote on Wed, 08 November 2023 06:46
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
Re: [railML3] Positioning approach [message #3282 is a reply to message #3125] Mon, 26 August 2024 08:26 Go to previous messageGo to next message
Ari Tilli is currently offline  Ari Tilli
Messages: 2
Registered: February 2024
Junior Member
Finnish ETCS project:

We plan to use the style of "Every NetElement has to have an associatedPositioningSystem linking to a so-called "intrinsic positioning system" usable as measuring tape"for all ETCS-related data".

Reason : This better matches the segment/offset model of various SA-designs, and also matches PlanPro-usage (IIRC).

If there are persons in the forum working in site data-tools for ETCS supplier, one could state if this is the way forward in their future railML (>=3.2) import tooling, so that we do not unnecessary listen to a supplier opposing this model.




Re: [railML3] Positioning approach [message #3284 is a reply to message #3282] Mon, 26 August 2024 11:32 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear all,

the complete positioning approach is summarized in Gitlab issue #541 [1]

[1] https://development.railml.org/railml/version3/-/issues/541

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 #3396 is a reply to message #3284] Tue, 19 November 2024 15:10 Go to previous message
Torben Brand is currently offline  Torben Brand
Messages: 169
Registered: March 2016
Senior Member
Hi, I have a short question:
What is the purpose of the <geometricCoordinate> elemenet under < topology/netElement/associatedPositioningSystem/intrinsicCor dinate/ >?
It seems a bit weird for me to have geo coordinates on an abstract concept as a <netElement>...
I would rather expect geo coordinates (<geometricCoordinate>) to be used/placed under <spotLocations> of <functionalInfrastructure> (that reference the <netElements>)...
Previous Topic: [railML 3.2] Modelling of Routes
Next Topic: Balise group values for IS:functionalType
Goto Forum:
  


Current Time: Thu Dec 05 14:04:45 CET 2024