Home » railML newsgroups » railML.infrastructure » odometry, pos and absPos
odometry, pos and absPos [message #1237] Mon, 08 December 2014 15:30 Go to next message
bob.janssen is currently offline  bob.janssen
Messages: 8
Registered: May 2013
Junior Member
Dear all,

ETCS operation relies on precise odometry. Engineers will want to use
RailML positions of balises, points and other track elements to compute
speedprofiles, balise-profiles, etc. This information is vital.

Geographic coordinates are of little use for this purpose. Much rather,
the pos and absPos attributes of many IS elements are useful.

These elements therefore deserve a thorough definition and here's my
proposal:

pos: the length of track, measured along the track's centreline from
<trackBegin>. To be used for vital purposes such as train odometry.

absPos: a mileage, or kilometrage, typically displayed alongside the
track, that supports positioning e.g. for maintenance purposes but not
for vital or signalling purposes.

Yours,
Bob Janssen

--
----== posted via PHP Headliner ==----
Re: odometry, pos and absPos [message #1238 is a reply to message #1237] Tue, 09 December 2014 00:44 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Bob Janssen,

for pos and absPos, we use the following definitions so far:

> Due to historical reasons, the mileage (or "metering") of the tracks of a line often is not continuous. It can have any points of discontinuity ("jump" and/or change of counting direction between raising and falling) for instance by geographical corrections / repositioning of a line. In railML, the practical, historical mileage (written e.g. at mileposts) is named "absolute mileage". On the contrary, there is the "relative mileage" (attribute pos) which always has to be continuously raising (but not necessarily starting with zero). The relative mileage normally is virtual, i.e. not visible at stations or mileposts. To calculate distances, the relative mileage is used.

(Translated extract from:)
http://www.wiki.railml.org/index.php?title=IS:mileageChange# Notes

So far: No objections against your definitions.
From the requirements of <timetable> there is probably no such
'exactness' necessary as for precise odometry. One could think that this
is not a problem.

However, we have to be careful. You write "measured along the track's
centreline". This would lead to different /pos/ values for both <track>s
of a double-track line. Most timetabling applications probably assume
the same distances for both tracks of a double-track line. From my
opinion, this distance is measured along the centre of a _line_ which is
the centre between both tracks in case of a double-track line.

So, if you really need a distance measured in the centre of each track
independently from its line, we possibly need three position values:
- one for the absolute (traditional, discontinuous) mileage = absPos,
- one for the relative distances along the centre of a track,
- one for the relative distances along the centre of a line or group
of tracks.

I would welcome if this would not be necessary but instead we could use
the same definitions (and existing attributes) for all purposes.

Best regards,
Dirk Bräuer.
Re: odometry, pos and absPos [message #1239 is a reply to message #1238] Thu, 11 December 2014 14:23 Go to previous messageGo to next message
bob.janssen is currently offline  bob.janssen
Messages: 8
Registered: May 2013
Junior Member
Hello Dirk,

thanks for your enlightening reply. From your mail, I now understand your
use of mileage of a double-track line for the purpose of time-tabling;
fair enough.

From the point of view of signalling and train protection, we need
distances travelled along individual tracks, e.g. ETCS relies on exact
distances between balises, section limits and the like.

I was inspired by the definition of pos from IS:trackend which reads
"pos ... defined by the "real" length of the track as distance from the
trackBegin regardless the "absolute mileage".

I suggest that the position of objects irrelevant to time tabling are
measured relative to trackBegin. In particular, the definitions of
attributes pos in elements balise, traindetectors, signals, would need to
be completed accordingly.

Yours,
Bob Janssen


Dirk Br�uer wrote:
>
> Dear Bob Janssen,
>
> for pos and absPos, we use the following definitions so far:
>
>> Due to historical reasons, the mileage (or "metering") of the tracks of a
line often is not continuous. It can have any points of discontinuity ("jump"
and/or change of counting direction between raising and falling) for instance
by geographical corrections / repositioning of a line. In railML, the
practical, historical mileage (written e.g. at mileposts) is named "absolute
mileage". On the contrary, there is the "relative mileage" (attribute pos)
which always has to be continuously raising (but not necessarily starting with
zero). The relative mileage normally is virtual, i.e. not visible at stations
or mileposts. To calculate distances, the relative mileage is used.
>
> (Translated extract from:)
> http://www.wiki.railml.org/index.php?title=IS:mileageChange# Notes
>
> So far: No objections against your definitions.
> From the requirements of <timetable> there is probably no such
> 'exactness' necessary as for precise odometry. One could think that this
> is not a problem.
>
> However, we have to be careful. You write "measured along the track's
> centreline". This would lead to different /pos/ values for both <track>s
> of a double-track line. Most timetabling applications probably assume
> the same distances for both tracks of a double-track line. From my
> opinion, this distance is measured along the centre of a _line_ which is
> the centre between both tracks in case of a double-track line.
>
> So, if you really need a distance measured in the centre of each track
> independently from its line, we possibly need three position values:
> - one for the absolute (traditional, discontinuous) mileage = absPos,
> - one for the relative distances along the centre of a track,
> - one for the relative distances along the centre of a line or group
> of tracks.
>
> I would welcome if this would not be necessary but instead we could use
> the same definitions (and existing attributes) for all purposes.
>
> Best regards,
> Dirk Br�uer.
>
>



--
----== posted via PHP Headliner ==----
Re: odometry, pos and absPos [message #1246 is a reply to message #1239] Mon, 09 February 2015 15:17 Go to previous message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Dear Bob and Dirk,

Am 11.12.2014 um 14:23 schrieb Bob Janssen:
> [...]
>
> I suggest that the position of objects irrelevant to time tabling are
> measured relative to trackBegin. In particular, the definitions of
> attributes pos in elements balise, traindetectors, signals, would need to
> be completed accordingly.
>
> [...]

thank you for your input. I tried to clarify the definitions for pos and
absPos in the railML wiki, e.g. see [1]. If you have any further remarks
or questions, please let me know...

[1] http://wiki.railml.org/index.php?title=IS:trackEnd

Best regards

--
Christian Rahmig
railML.infrastructure coordinator
Previous Topic: give us the derailer !
Next Topic: Introduction of TAF-TSI PrimaryLocationCode as reference
Goto Forum:
  


Current Time: Fri Mar 29 06:58:02 CET 2024