| Clustering of location information [message #3023] |
Thu, 30 June 2022 14:02  |
Martin Zien
Messages: 12
Registered: December 2021
|
Junior Member |
|
|
The currently recommended approach to provide multiple location data of an infrastructure element is, to have a list of multiple related location entries. This would look similar to the example below:
<spotLocation id="sloc01" netElementRef="ne_02" applicationDirection="normal" pos="1698.421">
<geometricCoordinate positioningSystemRef="geops01" x="104105.74771934206" y="1254522.1541942309" z="313.62441070564091" />
</spotLocation>
<spotLocation id="sloc02" netElementRef="ne_02" applicationDirection="normal" pos="1698.421">
<linearCoordinate positioningSystemRef="lps01" measure="65599.693" />
</spotLocation>
<spotLocation id="sloc03" netElementRef="ne_02" applicationDirection="normal" pos="1698.421">
<linearCoordinate positioningSystemRef="lps02" measure="55699.69" />
</spotLocation>
Now we are challenged to make clear, that two of the coordinate-information lps02 & geops01 would belong contextually together. This is necessary, because they are derived from the same source.
The other location reference system "lps01" is referring to another domain with its own reference. This other domain must be provided in the data exchange via railML.
Is there already an established / recommended best practice for such a scenario?
If there is nothing available yet, what does the railML-community think about the collection of two different coordinate-entries collected below one location-element? The example above would then look like this:
<spotLocation id="sloc01" netElementRef="ne_02" applicationDirection="normal" pos="1698.421">
<geometricCoordinate positioningSystemRef="geops01" x="104105.74771934206" y="1254522.1541942309" z="313.62441070564091" />
<linearCoordinate positioningSystemRef="lps02" measure="55699.69" />
</spotLocation>
<spotLocation id="sloc02" netElementRef="ne_02" applicationDirection="normal" pos="1698.421">
<linearCoordinate positioningSystemRef="lps01" measure="65599.693" />
</spotLocation>
I'm looking forward to your answers.
[Updated on: Thu, 30 June 2022 14:04] Report message to a moderator |
|
|
|
| Re: Clustering of location information [message #3047 is a reply to message #3023] |
Fri, 20 January 2023 19:23  |
christian.rahmig
Messages: 436
Registered: January 2016
|
Senior Member |
|
|
Dear Martin,
dear all,
thank you for sharing your experiences about the location issue with us.
The topic "locations" is indeed very important and the aim of railML
development is to increase clarity in this complex matter in order to
define an unambiguous solution needed for a standardized data exchange
of railway infrastructure data.
The information that you want to model is a contextual relation between
two positioning systems. This information I would expect to be modelled
with the positioningSystem element. Currently, the positioningSystem is
missing this information and we can think about extending the railML
model. In particular, I see two options:
1) Add an attribute @source (string) to element <*positioningSystem>,
where you can define a source of the linear positioning system.
2) Add a referencing attribute @linkedWith (tRef) to element
<*positioningSystem>, where you can refer to another
<*positioningSystem> element.
I prefer the second option, because it is not the source you are
interested in, but the question whether two positioning systems have the
same source and thus are linked with each other. Further, a referencing
attribute is more unambiguous than a free text entry of a source.
Dear railML community, what do you think about this proposed extension?
Does it match with your use case requirements?
Martin, you described in your forum post a third option, which is
actually already possible with today's railML schema version 3.2.
However, I recommend not to use this approach for the following reasons:
* With this approach the linking information is modelled implicitly
(actually we would need another semantic rule then saying that two
coordinates modelled in one <spotLocation> belong together) and it is
modelled in the single coordinate. As mentioned before, the linking
information should be connected to the positioning system and not a
single coordinate.
* The definition of two coordinates of different location systems within
one <spotLocation> is not aligned with the RailTopoModel approach, which
allows only one coordinate. The fact, that you can put a
<linearCoordinate> AND a <geometricCoordinate> in one <spotLocation>
element is actually a not-intended side effect of the railML schema. It
becomes clear, when you want to put two coordinates of the same type
(linear or geometric) in one <spotLocation> element - which is not possible.
As always, any comments from the community are highly appreciated.
Best regards
Christian
--
Christian Rahmig - Infrastructure scheme coordinator
railML.org e.V. (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany
Am 30.06.2022 um 14:02 schrieb Martin Zien:
> The currently recommended approach to provide multiple
> location data of an infrastructure element is, to have a
> list of multiple related location entries. This would look
> similar to the example below:
> <spotLocation id="sloc01" netElementRef="ne_02"
> applicationDirection="normal" pos="1698.421">
> <geometricCoordinate positioningSystemRef="geops01"
> x="104105.74771934206" y="1254522.1541942309"
> z="313.62441070564091" />
> </spotLocation>
> <spotLocation id="sloc02" netElementRef="ne_02"
> applicationDirection="normal" pos="1698.421">
> <linearCoordinate positioningSystemRef="lps01"
> measure="65599.693" />
> </spotLocation>
> <spotLocation id="sloc03" netElementRef="ne_02"
> applicationDirection="normal" pos="1698.421">
> <linearCoordinate positioningSystemRef="lps02"
> measure="55699.69" />
> </spotLocation>
>
>
>
> Now we are challenged to make clear, that two of the
> coordinate-information lps02 & geops01 would belong
> contextually together. This is necessary, because they are
> derived from the same source. The other location reference system
> "lps01" is referring to
> another domain with its own reference. This other domain
> must be provided in the data exchange via railML. Is there already an
> established / recommended best practice
> for such a scenario?
>
> If there is nothing available yet, what does the
> railML-community think about the collection of two different
> coordinate-entries collected below one location-element? The
> example above would then look like this:
>
> <spotLocation id="sloc01" netElementRef="ne_02"
> applicationDirection="normal" pos="1698.421">
> <geometricCoordinate positioningSystemRef="geops01"
> x="104105.74771934206" y="1254522.1541942309"
> z="313.62441070564091" />
> <linearCoordinate positioningSystemRef="lps02"
> measure="55699.69" />
> </spotLocation>
> <spotLocation id="sloc02" netElementRef="ne_02"
> applicationDirection="normal" pos="1698.421">
> <linearCoordinate positioningSystemRef="lps01"
> measure="65599.693" />
> </spotLocation>
>
>
> I'm looking forward to your answers.
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
