Distance Travelled

[+Don Kebals]

Hi I was wondering if anybody could help me on this, I have recently purchased a Garmin GPSMAP62 Unit for Caching. This is the first GPS Unit I have used and have found it to be a very useful piece of kit once I got round the many functions available. I used to use my iphone but soon found the short battery life to be a serious issue, hence the recent purchase. My problem however is with being able to believe the distances shown on the Odometer. I am a keen walker and Cacher and I am always interested in the distance I have walked, I always reset the unit to zero when I start the walk and if I use it purely for walking it gives me a very accurate distance, the same can be said if i use it in the car again very accurate, however if I do any caching whilst on the walk the distance is massively over the top usually around double the true amount. It is not taking into account the distance traveled in the car prior to commencing the walk as I set it back to zero on exiting the vehicle. Can anybody shed any light on this as I am finding it very frustrating, Many Thanks

[+T.D.M.22]

What you probably want is from poit A to B. say the car to a lookout point. What might be happening is it measure every movement. The 10 feet off the trail to the can. The 6 inches to the other side of the trail- all those small distances add up.

[+gelfling6]

I usually don't measure my distance traveled, until I can read the data off the GPS onto the computer.. Either from the Magellan, or any of the Garmins. (Vista-HCx, and NuVI 40 in the car.) I'll extract track data from the Magellan GC, strip the waypoints (Geocaches, child,) then feed the .GPX file through EasyGPS, resave it (there's something funky about the GPX format right off the GC, that seems incompatible with other programs other than EasyGPS.) then I'll load the track GPX (from any source) into Garmin's MapSource, and trim down the excess data (car travel, sitting in one spot, and getting random jumps within 20-feet.) then measure the track that way.

 

Totally freaked me out, back around Mid-May, 2013, I took a hike around a local reservoir. total track length, from home to start point, around, back to start point, back to home, was about 19 miles.. When I stripped off the home-startpoint, then the startpoint back home, the distance was in excess of 11.34 miles! (explained my legs starting to hurt the last 3!)

 

I imagine you can do the same with Google Maps, feeding them a GPX or KML/KMZ file.

[+Redwoods Mtn Biker]

Set the tracklog to record a point once per second for the greatest accuracy.

[+Don Kebals]

Set the tracklog to record a point once per second for the greatest accuracy.

 

Spot on works a treat many thanks

[Grasscatcher]

Set the tracklog to record a point once per second for the greatest accuracy.

 

Rich, I respectfully disagree..... and you can physically prove your statement is incorrect for yourself by traveling an accurately measured path using different logging intervals. Perfectly straight paths don't seem to exist in the real world.

 

Yes, trackpoint interval set to 1/sec will produce the most accurate "path traveled" curvature or shape wise, but the length of the track, or distance traveled, will always be longer than "actual distance traveled".

Accuracy better for shape yes, but not for distance.

 

When logging interval is set to 1/sec, absolutely every bit of GPS error is added to length which results in "over distance" being reported. Most points possible being logged results in largest error. Arguably,"auto" method, and interval of "most often" produces the "most accurate overall results". (Best compromise)

[+Mineral2]

Set the tracklog to record a point once per second for the greatest accuracy.

 

Rich, I respectfully disagree..... and you can physically prove your statement is incorrect for yourself by traveling an accurately measured path using different logging intervals. Perfectly straight paths don't seem to exist in the real world.

 

Yes, trackpoint interval set to 1/sec will produce the most accurate "path traveled" curvature or shape wise, but the length of the track, or distance traveled, will always be longer than "actual distance traveled".

Accuracy better for shape yes, but not for distance.

 

When logging interval is set to 1/sec, absolutely every bit of GPS error is added to length which results in "over distance" being reported. Most points possible being logged results in largest error. Arguably,"auto" method, and interval of "most often" produces the "most accurate overall results". (Best compromise)

 

Even in Auto, the track still picks up wandering errors, especially when you are stopped for any length of time. The wandering adds up. In that case, setting your track log to track by distance of .01 miles (~52 feet), you end up with a track that doesn't necessarily follow the shape of every turn (especially problematic on trails with tight turns and switchbacks), but you end up with less wandering error for those times when you need to take a break.

 

There's no one right answer as all modes introduce some form of error, whether it be in the track shape, or adding extra points or wandering signal. This may be less important if Garmin continues to include the feature being able to turn the track log on and off with the quick tap of the screen (or button) as they've done with the Oregon 600 series. Of course, you can always load a track into Basecamp and edit out or even move points that are obviously out of place.

[+Team CowboyPapa]

It seems that there are two error sources considered here:

1. the straight line distance of two points on an arc is less than the distance along the arc, and

2. the random errors associated with each point and the characteristic of those errors. Regarding the random errors;

 

......

When logging interval is set to 1/sec, absolutely every bit of GPS error is added .....

Are you sure that the errors are not normally distributed about the average error of zero? If so, would not the errors cancel with the resultant sum of the total error being zero?

[+Mineral2]

It seems that there are two error sources considered here:

1. the straight line distance of two points on an arc is less than the distance along the arc, and

2. the random errors associated with each point and the characteristic of those errors. Regarding the random errors;

 

......

When logging interval is set to 1/sec, absolutely every bit of GPS error is added .....

Are you sure that the errors are not normally distributed about the average error of zero? If so, would not the errors cancel with the resultant sum of the total error being zero?

 

So, that would be true when estimating the location of a waypoint with multiple sampling (waypoint averaging). But, when hiking, a single point estimate can be off by as much as 30 feet in any particular direction. In addition, when stopping (either for a rest or to geocache), the distance may jump around in a 30-foot diameter error field, but a distance is recorded between those points regardless, and you end up with this birdsnest on your track that can be several hundred feet "long." Those add up making your track much longer than the actual distance travelled. And that's just if you put the GPS on the ground and leave it in one spot. The birdsnest will be even larger if: 1. you're moving around looking for a cache, or 2. you're in an area with decreased signal reception.

[39_Steps]

It seems that there are two error sources considered here:

1. the straight line distance of two points on an arc is less than the distance along the arc, and

2. the random errors associated with each point and the characteristic of those errors. Regarding the random errors;

 

......

When logging interval is set to 1/sec, absolutely every bit of GPS error is added .....

Are you sure that the errors are not normally distributed about the average error of zero? If so, would not the errors cancel with the resultant sum of the total error being zero?

In the World According to Garmin - oops I meant Garp - Grasscatcher seems to know whereof he speaks in regard to boots on the ground track recording while hiking. As he and others have posted, the theory goes out the window on a tree lined winding trail on the side of a mountain. Mineral2 infills with additional pertinent observations. On the other hand I have seen quite accurate distance recording at one second intervals with Delorme GPS devices at bicycling speeds on straight and open streets on a clear day.

[+Redwoods Mtn Biker]

Set the tracklog to record a point once per second for the greatest accuracy.

 

Rich, I respectfully disagree..... and you can physically prove your statement is incorrect for yourself by traveling an accurately measured path using different logging intervals. Perfectly straight paths don't seem to exist in the real world.

 

Yes, trackpoint interval set to 1/sec will produce the most accurate "path traveled" curvature or shape wise, but the length of the track, or distance traveled, will always be longer than "actual distance traveled".

Accuracy better for shape yes, but not for distance.

 

When logging interval is set to 1/sec, absolutely every bit of GPS error is added to length which results in "over distance" being reported. Most points possible being logged results in largest error. Arguably,"auto" method, and interval of "most often" produces the "most accurate overall results". (Best compromise)

 

That may be, but once per second works well for me, and seems to give the best elevation gain accuracy too, as it forces an elevation reading every second as well.

[+Team CowboyPapa]

...... On the other hand I have seen quite accurate distance recording at one second intervals with Delorme GPS devices at bicycling speeds on straight and open streets on a clear day.

If so, the errors are equally distributed between positive and negative in your direction of travel.

 

Consider walking along the sideline of a football field aligned N-S, at 1 fps constant, and recording every second:

1. If the errors were all positive solely in the north direction,

2. Would not the cumulative, sum total of the errors be essentially equal between the first 50 yards and the second?

3. Would not the sum of the 100 yards errors be essentially double of each of the 50 yard errors?

4. Would not the recorded speed for the 100 yards be greater than 1 fps?

5. If, after a completion of 100 yards to the north, making a 90 degree left turn, would the recorded track be an arc curving to the north?

 

Outside of that, why are the individual errors not essentially distributed equally between positive and negative?

[+fishgeek]

Post Deleted. I need to ponder this some more.

Edited November 4, 2013 by fishgeek

[+Team CowboyPapa]

 

....

 

Yes, trackpoint interval set to 1/sec will produce the most accurate "path traveled" curvature or shape wise, but the length of the track, or distance traveled, will always be longer than "actual distance traveled".

Accuracy better for shape yes, but not for distance.

 

When logging interval is set to 1/sec, absolutely every bit of GPS error is added to length which results in "over distance" being reported. Most points possible being logged results in largest error. Arguably,"auto" method, and interval of "most often" produces the "most accurate overall results". (Best compromise)

Help me out here, I am having difficulty accepting this:

1. The recorded distance travel will always be longer than the actual distance.

2. The result of the recorded track being greater than the actual distance must be the result of positive, as opposed to negative errors.

3. There is no condition on shape of travel, straight or curved.

4. If straight, there is no condition of direction, any direction will result in the sum total of the errors being positive.

 

For example:

1. Visualizing an X - Y graph where x increases positively to the right, then,

2. Recording once per second for 1,000 seconds while walking due East at a speed of 1 fps,

3. Results in an actual distance traveled of 1,000 feet,

4. If the error for every recorded point is a positive 10%, the total error is 100 ft, and,

5. The total recorded distance of travel is 1,100 ft, or greater than the actual as stated in the quote above?

 

However:

1. If the tester snaps a uueeee after 1,000 actual feet and now returns walking due West, and

2. The recorded distance is always greater than the actual distance as stated in the above quote, then,

3. The cumulative error recorded on the Westbound walk must also be positive, consequently,

4. After walking back West at 1 fps for 1,000 seconds with the same 10% error, then,

5. The actual distance is 1,000 ft and the recorded track is 1,100 ft, and,

6. Viewing the recorded track, the walker not only sees that he is back at the origin, but he truly is.

 

Oh-oh:

1. Two walkers start at the same time, same speed, same recording interval, same GPSr, same exact straight line path, but opposite direction,

2. They both see 1.1 foot recorded for each 1.0 ft of actual walk, regardless of direction?

3. The BIG GPS ERROR CAHUNA IN-THE-SKY always resets your GPSr error generator to record positive errors whenever you 180 degree change in direction?

[+Mineral2]

 

....

 

Yes, trackpoint interval set to 1/sec will produce the most accurate "path traveled" curvature or shape wise, but the length of the track, or distance traveled, will always be longer than "actual distance traveled".

Accuracy better for shape yes, but not for distance.

 

When logging interval is set to 1/sec, absolutely every bit of GPS error is added to length which results in "over distance" being reported. Most points possible being logged results in largest error. Arguably,"auto" method, and interval of "most often" produces the "most accurate overall results". (Best compromise)

Help me out here, I am having difficulty accepting this:

1. The recorded distance travel will always be longer than the actual distance.

2. The result of the recorded track being greater than the actual distance must be the result of positive, as opposed to negative errors.

3. There is no condition on shape of travel, straight or curved.

4. If straight, there is no condition of direction, any direction will result in the sum total of the errors being positive.

 

For example:

1. Visualizing an X - Y graph where x increases positively to the right, then,

2. Recording once per second for 1,000 seconds while walking due East at a speed of 1 fps,

3. Results in an actual distance traveled of 1,000 feet,

4. If the error for every recorded point is a positive 10%, the total error is 100 ft, and,

5. The total recorded distance of travel is 1,100 ft, or greater than the actual as stated in the quote above?

 

However:

1. If the tester snaps a uueeee after 1,000 actual feet and now returns walking due West, and

2. The recorded distance is always greater than the actual distance as stated in the above quote, then,

3. The cumulative error recorded on the Westbound walk must also be positive, consequently,

4. After walking back West at 1 fps for 1,000 seconds with the same 10% error, then,

5. The actual distance is 1,000 ft and the recorded track is 1,100 ft, and,

6. Viewing the recorded track, the walker not only sees that he is back at the origin, but he truly is.

 

Oh-oh:

1. Two walkers start at the same time, same speed, same recording interval, same GPSr, same exact straight line path, but opposite direction,

2. They both see 1.1 foot recorded for each 1.0 ft of actual walk, regardless of direction?

3. The BIG GPS ERROR CAHUNA IN-THE-SKY always resets your GPSr error generator to record positive errors whenever you 180 degree change in direction?

 

I think there are a few problems with this line of reasoning.

 

1:

If the error for every recorded point is a positive 10%, the total error is 100 ft,

 

The error at every point on the track is somewhat independent. Every point has an estimate of Lat., Long. +/- var. and we can assume that the expected deviation is the same at each point, but the actual deviation from point to point is variable. Even if the error is always the same distance from the actual coordinates, it may vary in the direction from the coordinates accounting for variable track segment lengths.

 

So, each length won't be consistently 10% greater than the actual. I would expect that as the actual distance increases, the % error on the track decreases. Thus you may get to a point where no matter how far you travel, the track length will always be a mile greater than actual distance for example.

 

I've noticed this phenomenon occurring consistently with my Oregon 450t. If I take a few steps (10 feet) forward, the GPS may tell me I've moved anywhere from 20-50 feet. If I walk a mile, there may be a discrepency of around .2 miles, If I walk 9 miles, I might get home and find I've really only walked 8. On the other hand, the odometer on my Nuvi is consistently 10 miles shorter than the odometer in my car each time I fill up for gas.

 

There's a third option for discrepencies, and that depends if distances also include elevation changes. There are always differences in distance between my trip odometer and track length, and I attribute that partly to the trip odometer sampling more often the track, so it's recording more of the wandering error, but I'm also suspicious that the trip odometer is incorporating changes in elevation where the track distance is not. I've not actually tested this hypothesis with data, but it might be a neat experiment to try.

[39_Steps]

Since the gps takes a finite amount of time to calculate and record points, would there not always be a consistent lag behind in the display if walking towards a waypoint or geocache? But isn't that irrelevant except for the first and last recorded point in any recorded track?

 

Seems like the only way to get added distance if trying to walk in a straight line is if Pythagoras staggers randomly. Maybe Pythagoras needs a bicycle for the gyro effect?

 

Back when Delorme was recording points at 10 foot intervals, seems like the needle used to swing back to a passed over waypoint anywhere between two and twelve feet past ground zero. This is likely OT, but I just thought I would toss this two foot delay at walking speeds of 5-6 fps into the mix for those of you who are comfortable discussing statistics.

[Grasscatcher]

Theorize all you want to.....all you'll do is wear out your brain cells and you still won't know any more than when you started. The sunburn, the cuts & scrapes, the tired muscles, the dust from the trail is where the real education happens.

 

Auto & Most often will "more consistently,when under real world conditions" produce more accurate results when using "actual" as the standard.

 

When anyone starts talking about "a" specific result, remember, "one in a row" does not make a trend.

[+fizzymagic]

Sigh. You're both wrong. If I have the energy I will explain tomorrow.

 

Choosing a universal number like once a second, etc. is not appropriate, since the optimal value depends on a lot of variables.

 

Choosing a shorter interval will always give a longer track length, but not necessarily because of position errors.

[+Mineral2]

Sigh. You're both wrong. If I have the energy I will explain tomorrow.

 

Choosing a universal number like once a second, etc. is not appropriate, since the optimal value depends on a lot of variables.

 

Choosing a shorter interval will always give a longer track length, but not necessarily because of position errors.

 

Sampling more often will also pick up more of the curvature in the path that is lost when sampling less often. But the position errors are partly responsible for track lengths being longer than the real-life actual length, say against a good old-fashioned survey wheel.

[+fizzymagic]

Sigh. You're both wrong. If I have the energy I will explain tomorrow.

 

Choosing a universal number like once a second, etc. is not appropriate, since the optimal value depends on a lot of variables.

 

Choosing a shorter interval will always give a longer track length, but not necessarily because of position errors.

 

Sampling more often will also pick up more of the curvature in the path that is lost when sampling less often. But the position errors are partly responsible for track lengths being longer than the real-life actual length, say against a good old-fashioned survey wheel.

 

Not by enough to worry about. Position errors tend not to be stochastic, so the effect is reduced significantly. I would be more worried about file size than errors from oversampling.

 

BTW, there is an easy way to correct for any oversampling issues. The velocity information is not calculated from positions, but rather from Doppler shifts, so you can use it to double-check the next position measurement. Most good-quality handheld GPS units do that internally, using a Kalman filter, but I suspect that smartphone GPS implementations don't bother with it.