Registered: 03/14/11
Posts: 66
Loc: SF bay area, CA

Quote:

The equation for linear distance between two points in 3-d space is:

d = sqrt(deltax^2 + deltay^2 + deltaz^2)

you would calculate deltax as the difference in latitude between points, deltay as the difference in longitude, and deltaz as the difference in elevation.

That would be the linear approach (assuming you walked in a straight between successive points). I could develop an algorithm the plots a smooth curve over all the data points and then calculates distance traveled from their. I'd have to think about that a bit more. In 2-d space it would be called a cubic spline.

Ooh, pick me!

d = Integral[dt sqrt((dx/dt)^2 + (dy/dt)^2 + (dz/dt)^2)]

where dx/dt is your speed in the latitudinal direction, etc.

I used to get in fights with my boyfriend when his GPS distance didn't match the distance I estimated from the map. Nice to have some backup on why.

We have the lat, long, elevation, and a timestamp to work with.

I'm not sure what format the elevation is in. It can't be feet above sea level because I haven't been that low for a long time, so it must be meters.

We also have to look up how to calculate feet using the lat/lon method shown. I think I might have the math for that in some code I was playing with for my radar web app.

I think it'd be fun to give it shot. You're never going to be boots on the ground accurate with the civilian grade GPS we have now, but it'd be fun to measure distance with a home rolled algorithm

Registered: 02/07/07
Posts: 3837
Loc: Ozark Mountains in SW Missouri

Below is a perl script that will process track data exported from a Garmin GPS using Garmin's BaseCamp software.

Lines that start with a "#" are comments I've made to help explain the logic flow

I've added the routines to count the total elevation gain and loss (Up and Down) and the necessary variables are loaded to do the math to calculate the total on the ground mileage for a track. All we need is the math.

If you guys can show me how to do that I'll try and write the code for it.

---------- code starts below ----------

#!/usr/bin/perl

############################################################# ############################################################# # # Calc Miles Hiked v1.0" # ############################################################# # We use these fine modules... use strict; use warnings;

# an example of tab seperated values that we can export from a Garmin GPS # the values are: lat long elevation timestamp # we add each line of the data to an array of data

# the number of lines of data in our data file my $number_of_lines = @input;

# we subtract by one so we can sync this number up with array order (it's a perl thing) $number_of_lines = ($number_of_lines - 1);

#set our total up and down values to zero my $totalUp = 0; my $totalDown = 0;

#create a line counter so we know when to exit the while loop. my $line_counter=0;

# now we start going over the data # on the first pass we grab the first and next lines # we increment the line number we start with on each pass while ($line_counter < $number_of_lines) {

my ($latA, $lonA, $eleA, $timeA) = split(/\t/, $input[$line_counter]);

$line_counter++;

my ($latB, $lonB, $eleB, $timeB) = split(/\t/, $input[$line_counter]);

# now we have our data. here's the routine to count the total feet down we climbed

if ($eleB < $eleA) {

my $difference = ($eleA - $eleB);

$totalDown = ($totalDown - $difference);

}

# here's the routine to count the total feet up we climbed if ($eleB > $eleA) {

my $difference = ($eleB - $eleA);

$totalUp = ($totalUp + $difference);

}

# here's where we need the math to figure total miles actually hiked.

Registered: 03/14/11
Posts: 66
Loc: SF bay area, CA

Unfortunately, path length cannot be calculated directly from total horizontal and total vertical distance (unless you're moving on a perfectly straight line), so you'd have to calculate the increment gained each time the GPS collects data (say, every 30 seconds, or so?), and add up the result:

That's what we're doing with this script. In the first instance of the "while" loop we get the difference from the values in lines 1 and 2. In the next instance we use lines 2 and 3, and so on until we've processed all the lines in the data record.

Okay, I already have the value for delta_z in the $difference variable .

I can get the value for delta_x easy enough, but I've going to need some help with the pathlength math. That's all a foreign language to me. After I get the delta_x value if you all can help me break it down so I can convert it to perl code we'll have the results we're looking for.

After that I can convert this code into a "Web App" that you can upload your track file to and get the results.

These are the results I get using the code I'm running. Distance and Elevation are both converted to feet:

Quote:

Leg 1 - Distance : 10.3625268966932 ::: Elevation : 3.14960630400012 Leg 2 - Distance : 26.9923527802663 ::: Elevation : 12.6312336149999 Leg 3 - Distance : 18.9807255710197 ::: Elevation : 4.72440945599999 Leg 4 - Distance : 4.40460389188256 ::: Elevation : 1.57480315199987

Total Distance : 60.7402091398617 || Elevation Change : 22.0800525269999

That should give you the numbers you need to run your math and compare to the total distance shown. You should probably double check my numbers, but you only need to check two legs of data to confirm if they are good or not, and I'll fix them if they are bad.

I would run that last bit of math myself, but you'll have to explain what "delta_x^2" means. Is there a way to write that in longhand math that I can better understand?

Hopefully you'll forgive me for not being able to decipher the formula you've offered. I never had an opportunity to take any math classes past the eighth grade, schools in LA were pretty overcrowded in the `70s...

Edited by billstephenson (02/17/1203:09 PM) Edit Reason: clarification

Registered: 03/14/11
Posts: 66
Loc: SF bay area, CA

I'm not too familiar with perl, but it seems like it should be able to handle these operations. A quick search shows me that exponents (that I write with a caret) use double asterisks **, so the length of leg 1 would be

or in numbers ( 10.3625268966932**2 + 3.14960630400012**2 )**(1/2) = 10.8306

and then add all the lengths together to get

10.8306 + 29.8016 + 19.5599 + 4.67766 = 64.8697

Sorry if my abbreviations for square and square-root aren't familiar; I spend my days staring at equations and tend to forget that most people don't. Let me know if that doesn't help any!

Registered: 02/07/07
Posts: 3837
Loc: Ozark Mountains in SW Missouri

Originally Posted By squark

and then add all the lengths together to get

10.8306 + 29.8016 + 19.5599 + 4.67766 = 64.8697

That worked!

Here's what I got:

Flat Distance : 60.7402091398617 Adjusted for Terrain Distance : 64.8697213477516

That's a big difference for just 60 ft of travel, and that sample was taken from my GPS track of a hike in the hollow below my house. I did grab that small piece because it had a notable variation in elevation, so it's not an average sample, but what it shows is significant.

If anyone has a track they'd like to run through the code I'd be glad to post the results. For that matter, if anyone wants the code, I'd be glad to send it to you.

Ummm - clearly the unit of measure used will determine the actual distance traveled. This is where CHAOS enters into the equation. Its like how many miles long is the west British coast? Now using a mm long measuring device and going around every rock and nuance, how long is it? The answer approaches infinity as the unit of measure shrinks.

A gps adds the horizontal distance between the points where it takes a data sample. If it is set to sample every minute and you meander, the distance covered will be less than if it samples every half minute, etc.

Of course the GPS will say the two waypoints are .87 miles apart. If you really did travel in a straight line up hill at 30 degrees, it would say .87 miles on its odometer - the sum of the horizontal distances between the data points. Jim

_________________________
These are my own opinions based on wisdom earned through many wrong decisions. Your mileage may vary.

_________________________
"Stand in the ways and see, and ask for the old paths, where the good way is, and walk in it; then you will find rest for your souls."

Registered: 02/07/07
Posts: 3837
Loc: Ozark Mountains in SW Missouri

Quote:

Ummm - clearly the unit of measure used will determine the actual distance traveled.

Yep, a GPS set on it's finest grain of data collection points does not provide a very high resolution picture of what you actually hiked, and the way your milage is calculated by a GPS ignores terrain all together.

There is solid logic behind that approach and your "This is where CHAOS enters into the equation" observation is the root of it.

That logic applies best to things like maps and boats and airplanes, and works just fine for cars on roads, but it's not so good for hikers that want to know how far they actually hiked. So the little app we are working on goes as far as possible with the data available from a GPS to give a better estimate of actual boots on the ground miles.

Still, compared to the most accurate piece of technology we currently have for measuring that, the best GPS still sucks.

Registered: 02/07/07
Posts: 3837
Loc: Ozark Mountains in SW Missouri

Originally Posted By wandering_daisy

There may be some GPS units that have a chip inside that converts, thus allowing you to choose how you want distance presented. I suspect most do not simply because there appear to be many different ways to calculation depending what you want to measure. Anyway Gershon needs to look in his manual and see if there is a setting that allows one or the other.

I'm not aware of one that does that, but companies like Garmin are pretty responsive to users, and if one requested a "Miles Hiked" feature that accounted for elevation I'm pretty sure they'd add it. If they added it to their "BaseCamp" software it'd be free and backwards compatible with their hardware, and it'd be a feature that'd hit their target market for that product.

On their hardware, they could add it with a software update, and if they kept only a running total they could obtain a much finer degree of accuracy while using little processing power or storage space.

Registered: 02/07/07
Posts: 3837
Loc: Ozark Mountains in SW Missouri

Okay, with the help of BZH, squark, and others I don't know, I made and posted a simple app that attempts to answer the question of "How far, including the terrain, did I really hike?"

You can find it with some sparse instructions on how to use it here:

I used a data file created by my Garmin Oregon 200 that was imported into Garmin's BaseCamp software and then exported using the "Tabbed Text" option. I tried to make it as easy as I can, but you still have to open the file and delete some non-track related text that Garmin puts in there before you upload it to the app, and there can't be any blank lines in the file.

For some reason it bombs out on larger data files. The error points to code I didn't write, and I haven't figured out what's causing it yet. I might look for some other code to replace those routines to see if that helps.

I've went over the math and logic this app uses as best I can. I'd be glad to provide the code to anyone that wants it. There is a demo file linked that you can download, review, and then upload to test the app with.

What's most striking to me right out of the box is not the difference in how far I hiked in the mountains as compared to flat ground, though that is notable, but how many feet up and down I hiked.

When I compare my numbers to what Garmin's "BaseCamp" gives for the "Ascent" and "Decent" numbers, there is a big difference.

I simply check to see if you went up or down on a given leg of a track and keep a running total of both. I don't know how they calculate it.

Now, I want to offer this...

I think for our purposes, and for the purpose to best describe what kind of hike a trail will be, the numbers that matter are how far you walked horizontally, and how far you climbed vertically, both up and down.

The reason I think these are the important numbers is because you have to physically move your body that far in those directions.

I think that measuring the angle between the two (distance and elevation) does not truly represent how your body moved, or the exertion required to move it.

Registered: 02/23/07
Posts: 1735
Loc: California (southern)

In the old days, we just ran a trail wheel along the route, and let it go at that. If you were counting paces, there was a formula for adding/dropping paces depending upon whether you were ascending or descending.

But I must say, the original question posed by the OP is far from "dumb;" I can't even begin to comprehend some of the subsequent posts. Does Google have an online Sanskrit translator?

I'm lookin at my Garmin 301 and I have maximum elevation, minimum elevation, total ascent, total descent, average ascent, average descent, odometer, movin time and movin average. I assume that "average" refers to velocity. I doubt that the odometer or movin average take into account elevation, especially since there are 6 other fields dedicated to it, but I could be wrong - happened once before.

This is all fun stuff and progress is great but if you want to quantify an up and downhill hike are you assuming that the trail is uniform and steepness does not matter? Certainly a gradual uphill hike culminating with a scramble up a talus pile to the top and then say onto snow to an overlook is going to be harder to quantify... is there a seasonal algorythme? Icey trail at the top say vs dry near the TH?

Like you can say 5 miles with 800 feet of up and 500 feet of down with some easy rocks near the top, and 57 switchbacks. OR maybe you could say that the trail has a meander coeficient of .23 and will require 57,000,000 ergs of energy per pound of hiker/pack...

Just funnin ya

_________________________
These are my own opinions based on wisdom earned through many wrong decisions. Your mileage may vary.

Registered: 02/07/07
Posts: 3837
Loc: Ozark Mountains in SW Missouri

Originally Posted By JimShaw

This is all fun stuff and progress is great but ....

It really is mostly just for fun, and you're right, you really can't measure a hike in a way that will describe it any detail at a glance.

Still, I think there is a value in the knowledge gained by studying topo maps, graphs, and mileage and elevation numbers. Like most things you count, you must have some real world experience in order for the numbers to have real value and meaning.

We all have some experience so trying to get some value and meaning out of the numbers a GPS records can be worthwhile. Let's look at some and see what we can learn at a glance.

The numbers below are extracted from the same GPS track I linked to on the web app, I rounded them off.

======================== Distance

GPS Distance : 1.49 (miles)

Adjusted Distance : 1.55 (miles)

Difference : 298 (feet)

======================== Elevation

Total Up : 749 (feet)

Total Down : 806 (feet)

Total Elevation Change : 1555 (feet) ========================

Everybody looks at the "GPS Distance" number first. All that number says to me is that this hike is like walking about 1.5 miles on flat ground.

Now let's look at the "Difference", and the "Total Up" and "Total Down" numbers and think about what they mean.

To me they mean I also have to climb the equivalent of 750 ft up, and 800 feet down, and I'll make it about an extra 2 feet forward for every 10 feet I climb.

Experience leads me to believe that hike must have some pretty steep spots, and at the least, I'll want more water than if I were just hiking 1.5 miles on flat ground.

Sorry Bill, I didn't participate in the conversation over the long weekend. (I wish I could say I was hiking but I can't use that excuse). It sounds like you got your math questions answered. Let me know if you have some lingering questions. I didn't quite understand the problem you ran into with your subroutine. I know a bit about coding but I don't know the language you are using. Let me know if I can help further.

p.s. it looks like your question on powers was answered, but I just wanted to add: from a programming perspective it is more efficient to program "x^2" as "x*x" instead of "x**2". It probably won't make any difference for your program, but I thought I would pass along one of the few nuggets of wisdom I have on programming.

Registered: 02/07/07
Posts: 3837
Loc: Ozark Mountains in SW Missouri

Originally Posted By BZH

Let me know if you have some lingering questions

It'd be great if you all would go over the math and logic. I've uploaded the script and linked it to the app. Here's the link to get it.

On that test GPS data I'm not convinced yet that I'm not counting some legs twice. Those "Total Up" and "Total Down" numbers look too high to me. I've went over them several times (and I've hiked that track) so I may be missing something.

I even set the app up to print out the sums for each leg of data but I still didn't see it. If there is no elevation gain or loss it doesn't add or subtract anything.

I suspect, but I'm not sure, that if the lat/long is unchanged (you are standing still), but the elevation is different (as a result in variations in how my GPS calculates elevation), then it does add or subtract the difference. If that's the case, it shouldn't, and I should write a test to see if the lat/longs are the same and skip over that leg. Not all GPS units would register a change, some have a built-in altimeter. Mine, I think, estimates elevation with the satellite signals, so it varies quite a bit when you're standing still.

The code looks good. If it is reporting too much elevation gain/loss then I guess I have to agree with you that it is do to adding elevation errors while you are standing around.

You could skip points with small distance changes, what might be better would be to skip points where the elevation is greater than the distance change. That would be walking up a slope greater than 45°. I guess anyway you do it, you might have to play around with the limits on your filter until you get good results.