I walk a lot, and tote along a GPS receiver that creates a GPX file on
my phone (using GPSMid) as I go. When I get home, I copy the file to my
Mac, and push it through gpsBabel to create a KML.

As I travel, I can look at a data page created by GPSMid that tells me
the distance I've walked. When I get home, I can open the KML file
created from the GPX file and see the distance I traveled (in a summary
along with some other items). They are always the same, or very close.

Now, I know that the GPX file is just an ordered list of locations and
times, and does not contain any information concerning the accumulated
distance. That tells me -- I think -- that gpsBabel must be calculating
the path length from the coordinate data. GPSMid, on my phone, is
presumably doing the same thing, because I don't think the GPS unit
emits messages containing data about distance traveled.

So the question is, how is the length of a path calculated, so that
identical answers are produced by both methods?

Isaac

isw wrote:
> I walk a lot, and tote along a GPS receiver that creates a GPX file on
> my phone (using GPSMid) as I go. When I get home, I copy the file to
> my Mac, and push it through gpsBabel to create a KML.
>
> As I travel, I can look at a data page created by GPSMid that tells me
> the distance I've walked. When I get home, I can open the KML file
> created from the GPX file and see the distance I traveled (in a
> summary along with some other items). They are always the same, or
> very close.
>
> Now, I know that the GPX file is just an ordered list of locations and
> times, and does not contain any information concerning the accumulated
> distance. That tells me -- I think -- that gpsBabel must be
> calculating the path length from the coordinate data. GPSMid, on my
> phone, is presumably doing the same thing, because I don't think the
> GPS unit emits messages containing data about distance traveled.
>
> So the question is, how is the length of a path calculated, so that
> identical answers are produced by both methods?
>
> Isaac

But surely "both methods" are just calculating distance from the
co-ordinates? However there are a range of different algorithms giving
different levels of accuracy. The simplest assumes the area concerned is
flat so that Pythagoras for a plane surface applies. More complex
calculations take the real shape of the Earth into account.

Mike.
--
If reply address is Mike@@mjcoon.+.com (invalid), remove spurious "@"
and substitute "plus" for +.

Mike Coon wrote:
> isw wrote:
>> I walk a lot, and tote along a GPS receiver that creates a GPX file on
>> my phone (using GPSMid) as I go. When I get home, I copy the file to
>> my Mac, and push it through gpsBabel to create a KML.
>>
>> As I travel, I can look at a data page created by GPSMid that tells me
>> the distance I've walked. When I get home, I can open the KML file
>> created from the GPX file and see the distance I traveled (in a
>> summary along with some other items). They are always the same, or
>> very close.
>>
>> Now, I know that the GPX file is just an ordered list of locations and
>> times, and does not contain any information concerning the accumulated
>> distance. That tells me -- I think -- that gpsBabel must be
>> calculating the path length from the coordinate data. GPSMid, on my
>> phone, is presumably doing the same thing, because I don't think the
>> GPS unit emits messages containing data about distance traveled.
>>
>> So the question is, how is the length of a path calculated, so that
>> identical answers are produced by both methods?
>>
>> Isaac
>
> But surely "both methods" are just calculating distance from the
> co-ordinates? However there are a range of different algorithms giving
> different levels of accuracy. The simplest assumes the area concerned is
> flat so that Pythagoras for a plane surface applies. More complex
> calculations take the real shape of the Earth into account.

Isaac, you should listen to Mike here!

Almost by definition, the two devices _have_ to generate the same total
distance.

The "perfect" solution is to calculate each track point to track point
distance using Vincenty, this is an algorithm which is accurate to a few
mm between any two points on the Earth's surface.

For a relatively short trip, like a hike or bike ride (or when you have
track points close together) you will get cm-level accuracy by simply
taking the "flat" distance from track point to track point:

meter_pr_degree = 20e6 / 180;
degree_2_radian = 180 / 3.1415926535;
dx = (lon2-lon1)*cos((lat1+lat2)/2 * degree_2_radian);
dy = (lat2-lat1);
dist = sqrt(dx*dx + dy*dy) * meter_pr_degree;

As long as the distance between individual track points is within
several km this will be effectively identical to the "perfect" distance.

Within 100 km or so you can do the same even easier using UTM
coordinates, in which case you are effectively projecting all the track
points onto a single flat surface, and you get all measurements directly
in meters.

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 2012-02-05 00:10 , isw wrote:
> I walk a lot, and tote along a GPS receiver that creates a GPX file on
> my phone (using GPSMid) as I go. When I get home, I copy the file to my
> Mac, and push it through gpsBabel to create a KML.
>
> As I travel, I can look at a data page created by GPSMid that tells me
> the distance I've walked. When I get home, I can open the KML file
> created from the GPX file and see the distance I traveled (in a summary
> along with some other items). They are always the same, or very close.
>
> Now, I know that the GPX file is just an ordered list of locations and
> times, and does not contain any information concerning the accumulated
> distance. That tells me -- I think -- that gpsBabel must be calculating
> the path length from the coordinate data. GPSMid, on my phone, is
> presumably doing the same thing, because I don't think the GPS unit
> emits messages containing data about distance traveled.

Typically not.

> So the question is, how is the length of a path calculated, so that
> identical answers are produced by both methods?

I'd be surprised if you got identical results from two different methods
unless both do the simple integration of delta-pos for each recorded
point and both have the same resolution in calculation (or otherwise run
the same method). But they should be close.

Most handheld GPS' compute position at 1 Hz. If you're walking (about 1
to 1.5 metres per second is typical) the position recording tends to be
noisy.

GPS makers know this and use various strategies to reduce the noise. My
Garmin, for example, is set to record position every 5 seconds. (I
could also set it to record only every x metres of change). But I find
the Garmin to record very poor tracks compared to my other GPS. (An AMOD
3080 photo tracker). (I do need to test the Garmin in recording
position changes)

OTOH, the same Garmin has an "odometer" feature, and it is quite
accurate as far as I've checked. So it seems while Garmin tracks are
not great their algorithm for distance is quite good. Note that Garmin
make a lot of products for athletes, so they've probably honed this
feature well and the same is integrated into their handheld GPS'.

If I integrate (from the AMOD data) on Google Earth (open the track and
right-click the elevation profile - that also gives you distance) then I
get hiking distance results that are about 10% longer than the actual hike.

I wrote my own integrator/filter to take track logs, do a moving average
delta-pos and then integrate only intervals of x metres or more (5 or 10
being the usual value). It also writes a new log with the filtered
track. Looks smoother on Google Earth, etc. That has given me accurate
(better than 1%) distance on courses that I could measure using Google
Earth "path" (clear view of the path on the ground in GE).

You can be sure GPSBabel has its own assumptions and algorithm. I
didn't even know it had a distance integration feature. (I only use it
to convert my AMOD tracks from NMEA to GPX so I can upload them to
Google Maps when needed).

As to phones, I have the iPhone 4 and its tracks are not that great,
esp. in the woods. The iPhone is great for finding restaurants and
navigating there, it's not a great hiking GPS - though the display
quality is fantastic, the "compass" is nice, and I have several paid for
GPS Apps that are very good. Too bad the GPS in the iPhone is a bit
crippled.

It would be nice if the iPhone GPS could be set by the user to run at a
higher rate (at the expense of battery power) such that the GPS solution
would be better.

--
"We demand rigidly defined areas of doubt and uncertainty."
Douglas Adams - (Could have been a GPS engineer).

In article <ho5209-(E-Mail Removed)>,
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:

> Mike Coon wrote:
> > isw wrote:
> >> I walk a lot, and tote along a GPS receiver that creates a GPX file on
> >> my phone (using GPSMid) as I go. When I get home, I copy the file to
> >> my Mac, and push it through gpsBabel to create a KML.
> >>
> >> As I travel, I can look at a data page created by GPSMid that tells me
> >> the distance I've walked. When I get home, I can open the KML file
> >> created from the GPX file and see the distance I traveled (in a
> >> summary along with some other items). They are always the same, or
> >> very close.
> >>
> >> Now, I know that the GPX file is just an ordered list of locations and
> >> times, and does not contain any information concerning the accumulated
> >> distance. That tells me -- I think -- that gpsBabel must be
> >> calculating the path length from the coordinate data. GPSMid, on my
> >> phone, is presumably doing the same thing, because I don't think the
> >> GPS unit emits messages containing data about distance traveled.
> >>
> >> So the question is, how is the length of a path calculated, so that
> >> identical answers are produced by both methods?
> >>
> >> Isaac
> >
> > But surely "both methods" are just calculating distance from the
> > co-ordinates? However there are a range of different algorithms giving
> > different levels of accuracy. The simplest assumes the area concerned is
> > flat so that Pythagoras for a plane surface applies. More complex
> > calculations take the real shape of the Earth into account.
>
> Isaac, you should listen to Mike here!
>
> Almost by definition, the two devices _have_ to generate the same total
> distance.
>
> The "perfect" solution is to calculate each track point to track point
> distance using Vincenty, this is an algorithm which is accurate to a few
> mm between any two points on the Earth's surface.
>
> For a relatively short trip, like a hike or bike ride (or when you have
> track points close together) you will get cm-level accuracy by simply
> taking the "flat" distance from track point to track point:
>
> meter_pr_degree = 20e6 / 180;
> degree_2_radian = 180 / 3.1415926535;
> dx = (lon2-lon1)*cos((lat1+lat2)/2 * degree_2_radian);
> dy = (lat2-lat1);
> dist = sqrt(dx*dx + dy*dy) * meter_pr_degree;
>
> As long as the distance between individual track points is within
> several km this will be effectively identical to the "perfect" distance.
>
> Within 100 km or so you can do the same even easier using UTM
> coordinates, in which case you are effectively projecting all the track
> points onto a single flat surface, and you get all measurements directly
> in meters.

Thanks to both you and Mike. That's the answer I was looking for. I was
unaware of the existence of the algorithm you mentioned.

Isaac

On 2012-02-06 01:59 , isw wrote:
> In article<ho5209-(E-Mail Removed)>,
> Terje Mathisen<"terje.mathisen at tmsw.no"> wrote:
>
>> Mike Coon wrote:
>>> isw wrote:
>>>> I walk a lot, and tote along a GPS receiver that creates a GPX file on
>>>> my phone (using GPSMid) as I go. When I get home, I copy the file to
>>>> my Mac, and push it through gpsBabel to create a KML.
>>>>
>>>> As I travel, I can look at a data page created by GPSMid that tells me
>>>> the distance I've walked. When I get home, I can open the KML file
>>>> created from the GPX file and see the distance I traveled (in a
>>>> summary along with some other items). They are always the same, or
>>>> very close.
>>>>
>>>> Now, I know that the GPX file is just an ordered list of locations and
>>>> times, and does not contain any information concerning the accumulated
>>>> distance. That tells me -- I think -- that gpsBabel must be
>>>> calculating the path length from the coordinate data. GPSMid, on my
>>>> phone, is presumably doing the same thing, because I don't think the
>>>> GPS unit emits messages containing data about distance traveled.
>>>>
>>>> So the question is, how is the length of a path calculated, so that
>>>> identical answers are produced by both methods?
>>>>
>>>> Isaac
>>>
>>> But surely "both methods" are just calculating distance from the
>>> co-ordinates? However there are a range of different algorithms giving
>>> different levels of accuracy. The simplest assumes the area concerned is
>>> flat so that Pythagoras for a plane surface applies. More complex
>>> calculations take the real shape of the Earth into account.
>>
>> Isaac, you should listen to Mike here!
>>
>> Almost by definition, the two devices _have_ to generate the same total
>> distance.
>>
>> The "perfect" solution is to calculate each track point to track point
>> distance using Vincenty, this is an algorithm which is accurate to a few
>> mm between any two points on the Earth's surface.
>>
>> For a relatively short trip, like a hike or bike ride (or when you have
>> track points close together) you will get cm-level accuracy by simply
>> taking the "flat" distance from track point to track point:
>>
>> meter_pr_degree = 20e6 / 180;
>> degree_2_radian = 180 / 3.1415926535;
>> dx = (lon2-lon1)*cos((lat1+lat2)/2 * degree_2_radian);
>> dy = (lat2-lat1);
>> dist = sqrt(dx*dx + dy*dy) * meter_pr_degree;
>>
>> As long as the distance between individual track points is within
>> several km this will be effectively identical to the "perfect" distance.
>>
>> Within 100 km or so you can do the same even easier using UTM
>> coordinates, in which case you are effectively projecting all the track
>> points onto a single flat surface, and you get all measurements directly
>> in meters.
>
> Thanks to both you and Mike. That's the answer I was looking for. I was
> unaware of the existence of the algorithm you mentioned.

Except that answer is wrong. The "code" above is fine (it's about
identical to my own) for calculating the distance between two points at
a small distance apart.

But, because small errors over short distances and time will accumulate
quickly the error will grow quickly as well. A degree of filtering of
the distances (that takes account of the kind of movement - eg: hiking
v. cycling) is required to reduce that error.

--
"We demand rigidly defined areas of doubt and uncertainty."
Douglas Adams - (Could have been a GPS engineer).

On 2012-02-05 06:28 , Terje Mathisen wrote:

> For a relatively short trip, like a hike or bike ride (or when you have
> track points close together) you will get cm-level accuracy by simply
> taking the "flat" distance from track point to track point:
>
> meter_pr_degree = 20e6 / 180;
> degree_2_radian = 180 / 3.1415926535;
> dx = (lon2-lon1)*cos((lat1+lat2)/2 * degree_2_radian);
> dy = (lat2-lat1);
> dist = sqrt(dx*dx + dy*dy) * meter_pr_degree;
>
> As long as the distance between individual track points is within
> several km this will be effectively identical to the "perfect" distance.

Except that accumulating differences between 2 GPS points over short
distances and time will result in an error accumulation. Those short
distances need to be filtered (appropriate to the speed of movement) to
reduce those errors.


--
"We demand rigidly defined areas of doubt and uncertainty."
Douglas Adams - (Could have been a GPS engineer).

Alan Browne wrote:
> Except that accumulating differences between 2 GPS points over short
> distances and time will result in an error accumulation. Those short
> distances need to be filtered (appropriate to the speed of movement)
> to reduce those errors.

But not an error *percentage* accumulation.

Another way of getting distance would be to integrate the speed
measurements. But this is not likely to be easier of more accurate.

Mike.
--
If reply address is Mike@@mjcoon.+.com (invalid), remove spurious "@"
and substitute "plus" for +.

On Feb 5, 12:10*am, isw <i...@witzend.com> wrote:
> I walk a lot, and tote along a GPS receiver that creates a GPX file on
> my phone (using GPSMid) as I go. When I get home, I copy the file to my
> Mac, and push it through gpsBabel to create a KML.
>
> As I travel, I can look at a data page created by GPSMid that tells me
> the distance I've walked. When I get home, I can open the KML file
> created from the GPX file and see the distance I traveled (in a summary
> along with some other items). They are always the same, or very close.
>
> Now, I know that the GPX file is just an ordered list of locations and
> times, and does not contain any information concerning the accumulated
> distance. That tells me *-- I think -- that gpsBabel must be calculating
> the path length from the coordinate data. GPSMid, on my phone, is
> presumably doing the same thing, because I don't think the GPS unit
> emits messages containing data about distance traveled.
>
> So the question is, how is the length of a path calculated, so that
> identical answers are produced by both methods?
>
> Isaac

Using a typical consumer class receiver, iff you look at a scatter
plot of the fixes, you will typically see a grouping where most of
the points are within a 80 foot diameter circle. Most of them will
actually fall within a 20 foot diameter circle providing a good
probability that your position is fixed within about 10 feet of true.

So I'd suspect your travel path would need to exceed 40 feet by a
great margin to cancel out the precision error at the beginning and
end points of your route. If you walked around a 5 foot radius
circle, could you accurately measure the total distance by summing the
distance between successive fixes?

Of course if your route is long enough you can use flat earth
Pythagoras for distances of 30 miles (or so). Round earth Haversine
type solutions can provide solutions accurate to a percent or so. If
you need a 'squashed earth' solution, the method of Andoyer-Lambert is
excellent providing an error of just a few meters.

Other iterative type solutions can be employed for ultimate accuracy
on the reference ellipsoid.

--- CHAS

Alan Browne wrote:
> On 2012-02-05 06:28 , Terje Mathisen wrote:
>> As long as the distance between individual track points is within
>> several km this will be effectively identical to the "perfect" distance.
>
> Except that accumulating differences between 2 GPS points over short
> distances and time will result in an error accumulation. Those short
> distances need to be filtered (appropriate to the speed of movement) to
> reduce those errors.

Only true if you have transverse noise.

I.e. errors along the direction of travel don't matter for the final
distance accumulator.

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"