Home » railML newsgroups » railML.infrastructure » odometry, pos and absPos
Re: odometry, pos and absPos [message #1239 is a reply to message #1238] Thu, 11 December 2014 14:23 Go to previous messageGo to previous 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 ==----
 
Read Message
Read Message
Read Message
Read Message
Previous Topic: give us the derailer !
Next Topic: Introduction of TAF-TSI PrimaryLocationCode as reference
Goto Forum:
  


Current Time: Sat May 18 06:45:33 CEST 2024