On 2012-02-06 13:08 , Terje Mathisen wrote:
> 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.

Which you always have. And the lower the speed, the more noise per
along track travel. The more and thicker the tree cover, the more
"transverse noise".

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

Back to the "transverse noise" and that continues to integrate.
I've proven this with simple integrators like that in Google Earth and
my own code - which is why I've implemented filters that reduce the
error significantly, esp. for hiking. For higher speeds, less filtering
is required.

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

On 2012-02-06 10:02 , Mike Coon wrote:
> 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.

If you mean "the percentage changing" yes. However, it will be
different for hiking (worse case) than cycling as the "noise" is highest
v. distance traveled at low speeds.

Recall the original post. He's talking about what his GPS reports as
distance traveled while walking. To do so, the receiver integrates
small changes in position. Every time it does so, it integrates the
error into the sum.

Receivers like Garmin, appear to use a smarter algorithm that filters
appropriately for walkers, bikers, automobile users. Some form of
filtering is occurring.

Using the 'code' presented earlier, and integrating the difference, the
error will pile up.

In the earlier days of GPS, handheld receivers performed very poorly at
integrating distance (in large part because of lower satellite coverage
and SA, but also the algorithms were simply too simple).

If I use Google Earth to calculate the distance traveled (for a hike),
the error is always positive and generally around 10%. I suspect that
for a bike ride its error will be less - I'll try to validate that this
spring.

My own filter both smooths the track (reducing what Terje calls
"transverse noise") and integrates on a minimum distance moved setting
(usually set to 5 metres for hikes). With that I get errors of better
than 1% - similar to the error with the Garmin.

(I've checked these on easy to measure courses on Google Earth using the
distance/path feature).

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

On Feb 6, 6:35*pm, Alan Browne <alan.bro...@FreelunchVideotron.ca>
wrote:
> On 2012-02-06 10:02 , Mike Coon wrote:
>
> > 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.
>
> If you mean "the percentage changing" yes. *However, it will be
> different for hiking (worse case) than cycling as the "noise" is highest
> v. distance traveled at low speeds.
>
> Recall the original post. *He's talking about what his GPS reports as
> distance traveled while walking. *To do so, the receiver integrates
> small changes in position. *Every time it does so, it integrates the
> error into the sum.
>
> Receivers like Garmin, appear to use a smarter algorithm that filters
> appropriately for walkers, bikers, automobile users. *Some form of
> filtering is occurring.
>
> Using the 'code' presented earlier, and integrating the difference, the
> error will pile up.
>
> In the earlier days of GPS, handheld receivers performed very poorly at
> integrating distance (in large part because of lower satellite coverage
> and SA, but also the algorithms were simply too simple).
>
> If I use Google Earth to calculate the distance traveled (for a hike),
> the error is always positive and generally around 10%. *I suspect that
> for a bike ride its error will be less - I'll try to validate that this
> spring.
>
> My own filter both smooths the track (reducing what Terje calls
> "transverse noise") and integrates on a minimum distance moved setting
> (usually set to 5 metres for hikes). *With that I get errors of better
> than 1% - similar to the error with the Garmin.
>
> (I've checked these on easy to measure courses on Google Earth using the
> distance/path feature).
>
> --
> "We demand rigidly defined areas of doubt and uncertainty."
> Douglas Adams - (Could have been a GPS engineer).

You are such strange people,entirely oblivious to the Earth's motions
as the concentration here is between a moving device and the Earth's
surface and has noting to say about the surface of the Earth or its
motion.

To the nearest mile,the Earth turns 1037.5 miles an hour at the
equator and a full 24901 mile circumference in 24 hours yet you
dummies follow a system where 15 degrees of geographical separation
does not equate to 1 hour time difference as you insist on linking
daily rotation directly to stellar circumpolar motion and come up with
an imbalance of 1465 rotations in 1461 days.

Engineers are creating havoc and they don't know it for when you are
4 rotations adrift of the 1461 rotations in 1461 days I wouldn't
consider a person in any way brilliant.Do you do this on purpose or is
it some kind of protective stupidity that prevents you from
distinguishing a moving device and distance on a planet and the motion
of the planet itself ?.

You all actually know that the Earth is round and rotating ?,maybe
even that Feb 29th is the final 1461 st rotation enclosing 4 orbital
circuits of the Earth.Ah,I am wasting my time with a bunch of
astronomical illiterates and programming riff-raff.

Alan Browne wrote:
> On 2012-02-06 10:02 , Mike Coon wrote:
>> 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.
>
> If you mean "the percentage changing" yes. However, it will be
> different for hiking (worse case) than cycling as the "noise" is
> highest v. distance traveled at low speeds.

I have no idea what "the percentage changing" means, so I cannot comment on
that. All I actually meant is that an accumulation of 10% errors is still no
more than a 10% error in the total however many items are added.

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

On 2012-02-06 17:42 , Mike Coon wrote:
> Alan Browne wrote:
>> On 2012-02-06 10:02 , Mike Coon wrote:
>>> 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.
>>
>> If you mean "the percentage changing" yes. However, it will be
>> different for hiking (worse case) than cycling as the "noise" is
>> highest v. distance traveled at low speeds.
>
> I have no idea what "the percentage changing" means, so I cannot comment on
> that. All I actually meant is that an accumulation of 10% errors is still no
> more than a 10% error in the total however many items are added.

That's what I meant and yes I wrote that poorly.

But the objective is to get that 10% down as much as possible. Garmin
does that well in the etrex that I have, and my filter does it well too
.... but Google Earth's "Elevation Profile" integration shows about 10%
positive error.

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

Alan Browne wrote:
> On 2012-02-06 13:08 , Terje Mathisen wrote:
>> I.e. errors along the direction of travel don't matter for the final
>> distance accumulator.
>
> Back to the "transverse noise" and that continues to integrate.
> I've proven this with simple integrators like that in Google Earth and
> my own code - which is why I've implemented filters that reduce the
> error significantly, esp. for hiking. For higher speeds, less filtering
> is required.
>

My "hikes" are in the form of orienteering competitions, running in both
regular and very dense forests: Under these conditions the actual track
length error is almost always in the other direction, i.e. the track log
is showing _less_ sidewise movement than what I've really done, in order
to run around individual trees, rocks and other obstacles!
:-)

OTOH when I'm sailing, the actual/real track is usually less wiggly than
the raw GPS fixes, so some filtering will improve it.

About 10 years ago I wrote a filter which would optimize a given track
log, i.e. either minimizing the number of track points needed to
maintain a maximum allowable sidewise offset from the original track
points, or doing the same with a given budget of track points.

The latter was most useful when converting a track log into a route for
a GPS with relatively low limits on the number of route points.

I gave this code to the author of OziExplorer, he used it as the basis
for the filter in that application.

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

On 6 Feb, 16:02, "Mike Coon" <Mike@@mjcoon.+.com> wrote:
> 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.

This should be usually worst, because if loose the fix you loose also
the speed you would like to integrate.
Using position delta instead, unless you make turns while you son't
have the fix, you can recover the distance lost when in no-fix.

On 2012-02-07 07:11 , claudegps wrote:
> On 6 Feb, 16:02, "Mike Coon"<Mike@@mjcoon.+.com> wrote:
>> 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.
>
> This should be usually worst, because if loose the fix you loose also
> the speed you would like to integrate.
> Using position delta instead, unless you make turns while you son't
> have the fix, you can recover the distance lost when in no-fix.

If the number of speed samples = number of position samples, and the
resolution of the speed sample is fine enough, there would be no
difference.

Note that hiking rarely allows straight line travel, so if you lose the
GPS, then your last velocity (or average v) will integrate well whereas
the last position to new position when GPS comes back will be a straight
line that does not represent the line of travel.


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

On 2012-02-07 06:36 , Terje Mathisen wrote:
> Alan Browne wrote:
>> On 2012-02-06 13:08 , Terje Mathisen wrote:
>>> I.e. errors along the direction of travel don't matter for the final
>>> distance accumulator.
>>
>> Back to the "transverse noise" and that continues to integrate.
>> I've proven this with simple integrators like that in Google Earth and
>> my own code - which is why I've implemented filters that reduce the
>> error significantly, esp. for hiking. For higher speeds, less filtering
>> is required.
>>
>
> My "hikes" are in the form of orienteering competitions, running in both
> regular and very dense forests: Under these conditions the actual track
> length error is almost always in the other direction, i.e. the track log
> is showing _less_ sidewise movement than what I've really done, in order
> to run around individual trees, rocks and other obstacles!
> :-)

Then you need a GPS with a higher sampling rate.

> OTOH when I'm sailing, the actual/real track is usually less wiggly than
> the raw GPS fixes, so some filtering will improve it.
>
> About 10 years ago I wrote a filter which would optimize a given track
> log, i.e. either minimizing the number of track points needed to
> maintain a maximum allowable sidewise offset from the original track
> points, or doing the same with a given budget of track points.

How does it select?

> The latter was most useful when converting a track log into a route for
> a GPS with relatively low limits on the number of route points.
>
> I gave this code to the author of OziExplorer, he used it as the basis
> for the filter in that application.
>
> Terje


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

Alan Browne wrote:
> On 2012-02-07 06:36 , Terje Mathisen wrote:
>> Alan Browne wrote:
>>> On 2012-02-06 13:08 , Terje Mathisen wrote:
>>>> I.e. errors along the direction of travel don't matter for the final
>>>> distance accumulator.
>>>
>>> Back to the "transverse noise" and that continues to integrate.
>>> I've proven this with simple integrators like that in Google Earth and
>>> my own code - which is why I've implemented filters that reduce the
>>> error significantly, esp. for hiking. For higher speeds, less filtering
>>> is required.
>>>
>>
>> My "hikes" are in the form of orienteering competitions, running in both
>> regular and very dense forests: Under these conditions the actual track
>> length error is almost always in the other direction, i.e. the track log
>> is showing _less_ sidewise movement than what I've really done, in order
>> to run around individual trees, rocks and other obstacles!
>> :-)
>
> Then you need a GPS with a higher sampling rate.
>
>> OTOH when I'm sailing, the actual/real track is usually less wiggly than
>> the raw GPS fixes, so some filtering will improve it.
>>
>> About 10 years ago I wrote a filter which would optimize a given track
>> log, i.e. either minimizing the number of track points needed to
>> maintain a maximum allowable sidewise offset from the original track
>> points, or doing the same with a given budget of track points.
>
> How does it select?

(This is from decade-old memory)

Reduce a track to N points:

The first iteration would start with a straight line from start to end,
then locate the track point with the largest perpendicular offset.

The track would then be split into two parts, repeating the previous
process while looking for offsets from the two straight segments.

I did this until I had something like twice as many points as the target
(N) I was looking for.

Next I went through the 2N selected points and deleted the one which had
the least offset from a straight line between its two neighbors,
repeating this process until I was back at N points.

To further improve the fit I would also try some genetic permutations,
randomly selecting a track point to be moved to the next/previous point.

The final result is/was pretty good; even though it probably isn't
optimal it will be quite close.

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