The wheel has its own problems on really rock trails.

Wow! What a discussion. I learned a lot. And I am not even a GPS user.

deleted by op

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:

http://navigraphic.com/cgi-bin/navigraphic/CalcMilesHiked.pl

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.

The app attempts to provide those numbers too.

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

When post-holing can you add on the distance into and out of the post-holes?

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.

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.