| Feedback from 1st railML 3.1 Workshop 09./10.01.2018 - intrinsic coordinates [message #1700] |
Wed, 07 February 2018 22:18  |
christian.rahmig
Messages: 460
Registered: January 2016
|
Senior Member |
|
|
Dear RTM colleagues,
on January 9-10, 2018 the first railML 3.1 Workshop took place in
Berlin. The aim of this workshop was to collect feedback on the beta
version of railML 3.1 that has been released in Octobre 2017. As railML
3.1 is based on RailTopoModel V1.1 (November 2017) one question that has
been raised deals with intrinsic coordinates to be forwarded to you:
Intrinsic coordinates are used to define a relative position of a
NetEntity between 0 and 1 within the topological network. This attribute
is used for all types of locations, e.g. <spotLocation> and
<linearLocation>.
Examples in railML 3.1 beta:
<levelCrossing id="lcr01" ...>
<spotLocation id="lcr01_sloc01" netElementRef="ne_x01"
intrinsicCoord="0.6944" applicationDirection="both">
<linearCoordinate positioningSystemRef="lps01" measure="2.500"/>
</spotLocation>
</levelCrossing>
<platformEdge id="ple02" ...>
<linearLocation id="ple02_lloc01">
<associatedElement netElementRef="ne_a02" intrinsicCoordBegin="0.2"
intrinsicCoordEnd="0.6">
<linearCoordinateBegin positioningSystemRef="lps01" measure="0.600"/>
<linearCoordinateEnd positioningSystemRef="lps01" measure="0.700"/>
</associatedElement>
</linearLocation>
</platformEdge>
The problem:
The intrinsic coordinate is usually not the "leading" positioning
information in data base exports. Instead, it is being calculated on the
basis of mileage or meter positioning values and thus represents a
"derived" value. The conclusion of the discussion was the statement that
for the data exchange intrinsic coordinates are not of interest.
Instead, it may be calculated by the importing system based on the
positioning information from the input. Thus, it was suggested to make
the intrinsic coordinate for all NetEntities optional for the data
exchange format since the information seems to be redundant. The concept
of intrinsic coordinates in general and within internal data models is
not questioned by this discussion.
Questions resulting from the discussion:
* Can UIC please provide a more detailed documentation of the whole
topic of intrinsic coordinates? Is there something more specific
available than in [1]?
* What do you think about the proposal above to having intrinsic
coordinates in the data exchange scheme only optionally? If considered
positively, when will such a modelling change be implemented in RTM (V1.2?)?
[1]
http://wiki.railtopomodel.org/index.php?title=Object_positio ning_in_the_network
Thank you very much and best regards
Christian Rahmig
--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
|
| Re: Feedback from 1st railML 3.1 Workshop 09./10.01.2018 - intrinsic coordinates [message #1923 is a reply to message #1875] |
Thu, 23 August 2018 11:30  |
Felix Prüter
Messages: 28
Registered: June 2016
Location: Berlin
|
Junior Member |
|
|
Airy Magnien wrote on Thu, 12 July 2018 16:58
A2: Intrinsic coordinates have been made optional in RTM 1.1. In the location package, the intrinsic coordinates have been moved from the AssociatedNetElement to a daughter class, the use of which is optional. It is always possible to refer to other positioning systems instead.
On the other hand, in the Topology package, the extremities of (linear) NetElements need to be differentiated (disambiguated) in some way. This is why the corresponding intrinsic coordinates (0 and 1) of PositioningNetElements must refer to some coordinate, in the POsitioningSystem package.
I agree with the given argumentation.
--
Felix Prüter
SIGNON Deutschland GmbH
|
|
|
|
|
|
Members
Search
Help
Login
Home
