RChung

That's a different problem. Are you saying that if I hold my hand above a table top, there is no "right" distance between my hand and the table top? You can't measure a distance between two points unless they're connected? How about distance in the vacuum of space? In fact, the meter is defined as 1/299792458 of the distance light travels in a vacuum in one second, so we can certainly measure a distance in a vacuum.

There is a distance, and there is a measurement of that distance.

terrymorse 

The accumulated elevation gain is the problem of interest to cyclists, and it’s analogous to the “length of a coastline” problem.

Of course, it’s simple to determine the elevation difference between two points. But the accumulated elevation gain between two points is path dependent. And you will get a different result if you use a different length ruler.

canklecat

Are you using Strava's option to correct the elevation and distance (browser only)?

My hunch is that Strava defers to the data uploaded by our apps and computers. I usually ride with both a computer (XOSS G+ with barometer) and phone app (usually Wahoo Fitness) as a backup. When I upload two files from two different devices the biggest difference is usually in elevation and terrain profile. In particular the XOSS G+ data produces terrain profiles that look like something drawn with an Etch A Sketch, and barely resembles the actual elevation gain, slopes or terrain profile. Other bike computers with barometers might be better. The XOSS isn't bad for $25-$50 but not a precision instrument.

But when I click the option to correct elevation, the elevation gain and terrain profile usually match most rides on the same route, and seems to correspond with what I've seen and measured. On some routes I've used a phone app to physically measure the grade on some of our short, steep climbs that seemed to be double digits -- we have no mountains here, few extended gradual inclines, and many short, steep punchy hillettes. My measurements usually correspond with Strava's data.

Regarding KOMs on some Strava segments, with the earliest segments created by first users, there's a lot of garbage-in/garbage-out. Some of the earliest Strava segments created here are so ridiculous many of us have created modified segments along the same routes to get something closer to reality. There's one in my area that claims to be a 30% or so grade. There's nothing remotely resembling that in this entire area. Other segments were created using GPS traces that were choppy or wildly off -- such as requiring subsequent cyclists to ride on the opposite side of the road against traffic, or riding through someone's front yard. The people who created those segments should have re-ridden the route to create segments closer to reality, but they didn't.

RChung

The accumulated elevation gain between two points must *not* be path dependent, or else you could go up the climb the "short" path and down the "long" path and gain more energy going down than you use going up, and that violates one of the laws of thermodynamics because it's a recipe for a perpetual energy machine. But I agree you get different results if you measure with a different ruler -- that's because there's a difference between a distance and the measurement of a distance.

And the problem of interest to cyclists isn't quite accumulated elevation gain, it's the energy they will need to climb whatever that accumulated elevation gain is, or perhaps the energy per unit time. Because traditionally cyclists didn't have a way to measure or estimate that energy, they got used to a proxy: elevation gained (although that doesn't exactly describe the energy problem because total elevation gained doesn't tell you how steep the road was). Fortunately, we now have devices that allow us to measure that directly, viz., power meters. So that's what I use: I translate the energy expended into an equivalent amount of climbing. I could have called that equivalent elevation but instead I called it virtual elevation. I actually calculate the virtual gradients for each second of the ride and combine it with the speeds for each second of the ride to get cumulated virtual elevation -- because I do it that way, I get not only the total elevation gained but also its distribution along the way, i.e., the virtual road profile.

HTupolev

I think you two are talking around each other. In most cycling conversation, the "elevation" or "elevation gain" of a ride usually refers to the cumulative elevation gained while traveling on positive gradients, not the elevation difference between the start and finish of a ride. The former is path-dependent and is comparable to a shoreline problem*, the latter is not.

*Or at least, it's comparable on a hypothetical level. For practical purposes, riding reasonable paved roads on a road bike is usually a smooth-enough situation that the minimum-ruler-length-that-it-makes-sense-to-use isn't that fuzzy of an issue.

RChung

Shorter: "Robert is an annoying pedant." Hmmm. Guilty as charged.

Iride01 

If I walk up the 8 foot hill in my yard, did I not climb any distance? That section of my yard is between the 350' and 360' foot contour line. The map data doesn't have the elevation data for every square inch of ground. If I mow my grass in then I'm climbing and descending multiple times that 8' of height, but I won't get any credit for climbing going by map data.

As another has said, with barometric sensors, resolution is the issue. Both for the devices ability to sense a certain amount of change reliably and factors that cause noise, unreliable data that have to be taken into account. If I go up and down five feet is that climbing and descending? If I go up and down 1 foot is that climbing and descending?

Getting back to the topo maps, it's possible to ride between the contour lines in places for many miles. That doesn't mean no climbing or descending was taking place unless your resolution has to be 10 feet or more.

RChung

The work it takes to raise a mass m up a height h under the force of gravity g is m*g*h. So that's what I do: rather than measure barometric pressure or GPS elevation gain or worry about resolution, I skip past all of that: I use total work, m, and g, to calculate what h must have been. As a part of that, I get the entire road profile.

So, yeah, I'd say that each time you're mowing your lawn up hill, I count that.

Iride01 

Well I didn't know the discussion is how to calculate the data. The question is more about when to accumulate the data Specifically elevation or the change in elevation.

And even more specifically why some data didn't accumulate to provide the same number.

RChung

I was responding to the claim that there is no "right" height. I demurred: there is a right height, and one can compare various measurements or estimates of that height to the actual "right" height. Terry and others seem to think that height is like a coastline, and that there is no right height, so (presumably) one cannot compare measurements or estimates to it.

I side-stepped the cumulation problem a while back by asking, "how much change in height and what gradients would it take so that the energy expended to get you up those hills and across those distances in the amount of time you took is consistent with the observable data?" and ended up showing how to turn an expensive power meter into a cheap altimeter.

njkayaker

No one was saying that. It's what differences/changes to include or exclude that isn't well defined.

How do you tell the difference in work due to variation in power output versus that due to height? (You'd need speed at least too.)

The link doesn't work.

RChung

The problem is a lot easier to think about if there *is* a right height -- then the right estimation methods are the ones that include/exclude changes/differences so that you end up with the right height. To get back to the coastline problem for a moment, this may be something you already know: you can design a function that is not smooth at any point (so it's not differentiable at any point), like a fractal. In that case, the "length" of a bounding fractal curve may not be easy to calculate -- however, the function may still be integrable so that the area enclosed by the function is finite (sorry, terrymorse). That's kind of sort of related to what I do: I calculate the area bounded by the curve and that's well-defined even if the curve itself causes nightmares.
You're exactly right, and that's why I said you need an accurate power meter, speedometer, total mass, and a few other things (that's why I warned about "hella wind"). What y'all have been mostly talking about is using one sensor (either a barometer or a GPS receiver); I use multiple sensors. I think (but am not sure) that people thought this wouldn't work because they thought that each different sensor introduces errors, so they thought you'd end up with worse estimates due to all the other errors. The surprise (?) was that the data from different sensors can be combined in ways so that they provide a check or constraint on the other sensors' data so that the combined estimate behaves much better than the estimate based on any single sensor.
Sorry. I *think* I fixed it and it should work now. That said, it's not key -- I just linked to it because it had a few visual examples from long ago.
[Edited to add] Dammit. The link still doesn't work. Hmmm. If you want (not that you need to) you could try copying the link and then dumping the "https:" at the front, but I understand if no one has time for that kind of nonsense.

Sy Reene

Tape measure?

terrymorse 

How bendy is your tape measure? The more bendy it is, the more it can follow the tiny contours of the coastline, and you'll get a larger answer.

RChung

The sum of an infinite series can be finite.

But more practically, surely the "bendiness" or scale of relevance is a bicycle wheel on the surface of a road. If you believe you can measure the distance traveled with a bike wheel, you don't have to get caught up in measuring around every pebble embedded in the road surface.

pdlamb

Isn't this focus on the fractal nature of a measurement based on sums of ever-more-microscopic measurements is a bit misleading?

Maybe we should turn the question around. Is there a measurement of altitude gain that is clearly wrong? And I think that's what O.P.'s collection is. The wide, 20% of mean standard deviation, variation of climbs over a half-dozen or so repetitions indicates that the measurement is unstable with the given cell-phone GPS instrument. Terry Morse's Strava case is another bad measurement example.

If we start from the premise that we need to identify and correct bad measurements, surely noisy cell phone GPS tracks are one of the very first things to eliminate from consideration. If someone, for whatever reason, wants to track climbing and is having problems running a cell phone tracker, one of the first responses is "cell phone GPS trackers are often unreliable." A simple corollary would be, "get something else to track climbs on your typical route."

I would be somewhat interested in why the O.P.'s route had such divergence. Did the route go through a downtown or near rock faces that would generate spurious points on the GPS track? Did the phone lose track because of tree leaves? Or was it an example of riding in the left tire track generates a different profile than riding on the shoulder?

njkayaker

Copy the link and replace "https" with "http".

kahn

Ah, you've hit on my walk around the local lake. It is about 4 miles with the dog-leg (lolly pop stem) from my house. But if I walk on the outside gravel or the inside asphalt or meander between both, obviously my distance would change. So estimate the diameter of the, of course, non-circular lake, and add or subtract two or three feet.

This discussion has been both fascinating and completely mind-numbing!

pdlamb

You're missing my point, so I probably didn't explain myself clearly.

If your path is built up, say, 20 feet above the lake, it's possible a GPS track is going to give you a 15' drop on the shoulder as you make go around a right turn. That might not happen if you're on the left side of your path (or lane). Multiply that by a few dozen curves on a bike route, and suddenly you've got spurious climbs amounting to several hundred feet.

Sy Reene

This discussion made me recall a similar type of query and oddity that I experienced, that I never really did understand the answer to. FWIW, link here: https://www.bikeforums.net/19928055-post26.html

terrymorse 

Well, the "size of the ruler" you choose can produce a substantial change in the accumulated vertical gain. So I guess that makes it worth paying attention to.

To keep from recording "silly small" undulations in elevation, devices use a low-pass filter that ignores changes below a certain amount. This filters out small variations due to sensor errors and very small uphills like freeway overpasses.

The de facto standard filter seems to be about 10 meters. If I recall correctly, that was what the Avocet 50 (the mother of all elevation recording bike computers) was set to.

Many arguments ensued over what the "proper" filter size should be, but 10 meters seems to have survived the assaults.

genejockey 

But what about Floridians, for whom freeway overpasses are the ONLY climbs?

tenrec

I'm the original poster and I'm glad that the post has stimulated such an interesting discussion. I just found something else of interest: looking back at my records, I found a couple of rides in 2016 which I tracked using both Strava and the Samsung S Health apps. On the first ride, over a 23-mile course, Strava recorded the elevation gain as 1299 while Samsung pegged it at 1721. On the second ride of 17 miles, Strava recorded a gain of 892 feet, while simultaneously Samsung gave me 1381 feet. The phone I was using at the time was probably a Samsung Galaxy S8. So here are examples of different apps on the same phone at the same time giving wildly different reading of elevation gain.

Darth Lefty 

I don't know what Strava does behind the scenes but they do seem to try to stick your GPS track onto their segments.

Elevation is the least accurate output of GPS just because of the way the system is designed to emphasize location. From your point on the Earth your receiver can probably "see" nine of the satellites, which are broadcasting their location and their atomic clock time. Your device calculates its position by comparing the light speed delay in each clock signal to find its distance from each one. Most of the satellites your device can see will be nearer the horizon, so they don't have a lot to contribute to the elevation, and the ones that are overhead are closer, making a smaller delay to measure.

tenrec

I find that utterly remarkable.