More Crazy data

I have a Garmin 910xt a triathlon type watch but I am a runner and cyclist. It supposed to have barometric altimeter in it right? Well the data is seriously in conflict. I notice all the time when I upload to Garmin connect then Strava the elevation gain is way less than RIde With The GPS. I don't use RWGP but it uploads since I have an account. My Ride with the GPS always shows much more elevation gain. Today I went 53 miles and on Garmin the gain was 1165 and Ride with the GPS it was 1630. That is fair amount of off and usually that is close to what will be. I normally don't track this stuff I live in the flatlands but the data is suspect for sure. More fake news from something.

Deacon Mark

On Monday, April 5, 2021 at 2:29:05 PM UTC-7, Mark cleary wrote:
I have a Garmin 910xt a triathlon type watch but I am a runner and cyclist. It supposed to have barometric altimeter in it right? Well the data is seriously in conflict. I notice all the time when I upload to Garmin connect then Strava the elevation gain is way less than RIde With The GPS. I don't use RWGP but it uploads since I have an account. My Ride with the GPS always shows much more elevation gain. Today I went 53 miles and on Garmin the gain was 1165 and Ride with the GPS it was 1630. That is fair amount of off and usually that is close to what will be. I normally don't track this stuff I live in the flatlands but the data is suspect for sure. More fake news from something.

I don't have the watch but the barometric pressure altimeter is dead accurate. The problem I have with my 810 is that for some reason it gives me absolute ridiculous "max altitude" and "min altitude" of 35000 and 15,000 ft. But the change in altitude is correct.

On 4/5/2021 2:29 PM, Mark cleary wrote:
I have a Garmin 910xt a triathlon type watch but I am a runner and cyclist. It supposed to have barometric altimeter in it right? Well the data is seriously in conflict. I notice all the time when I upload to Garmin connect then Strava the elevation gain is way less than RIde With The GPS. I don't use RWGP but it uploads since I have an account. My Ride with the GPS always shows much more elevation gain. Today I went 53 miles and on Garmin the gain was 1165 and Ride with the GPS it was 1630. That is fair amount of off and usually that is close to what will be. I normally don't track this stuff I live in the flatlands but the data is suspect for sure. More fake news from something.

Deacon Mark


Elevation gain is inherently a tricky subject, and I suspect even more
so for a rider in a relatively flat area.

Say rider August lives on a route over a mountain pass. The road has a
steady uphill grade, which he rides to the summit and back to his house.
Pretty much any reasonable elevation-gain calculation strategy will
work well for August: Summit Elevation minus house elevation, or
elevation differences every 10 seconds accumulated (and throw out
negative differences that mean he's going downhill) or lots of
variations on those themes.

Contrast rider Bertrand who lives in an area that most cyclists would
call "flat" though in fact the elevation varies by as much as 20 feet at
different places in the county. In fact, the actual elevation is
undulating in a very narrow range. Now the choice of elevation-gain
calculation starts to matter. Suppose you add up the differences every
10 seconds (again throwing out negative differences). If Bertrand
crests a ten-foot-tall hill right in the middle of one of those
ten-second intervals, the net elevation difference over that ten seconds
might end up positive and count, or negative and get thrown out, and in
no case will the height of the "summit" be reflected accurately. It's
reasonable to assume that Bertrand is going to miss a fair bit of
elevation gain if those undulations are frequent.

Now let's grant that the 10-second interval method is a bad method and a
straw man. A one-second interval is probably much more realistic for
modern GPS systems. That will still miss some elevation gain, but
probably not that much.

Oh, but wait - what if the undulations are quite small but high
frequency. Suppose cyclist Conrad was on a route that went up a half
inch in one foot of travel, then down a half inch the next foot,
repeatedly, for 10 miles. Again a weird example, this is gonna feel
like washboard, but how much elevation "gain" does Conrad experience?
Half an inch every two feet for 52,800 feet or 1100 feet of elevation
gain. Should we count that as elevation gain on what's an unnaturally
flat course otherwise? (Highest point minus lowest point is a half inch!)

As for RWGPS, it's not clear to me if RideWithGps is using your GPS
elevation data or just your GPS coordinates and then their own internal
elevation data for those locations. I would actually expect that if
they use their own elevation data, they aren't accumulating elevation
every second, but rather "netting out" elevation gain every ?100 feet?
or so, or perhaps longer. So all sorts of elevation gain could be missed.

As for a GPS device measuring altitude gain, remember that GPS altitude
measurement is prone to significant measurement errors, and even though
the best GPS devices have barometers that "smooth" out the data, GPS
data is going to have tiny random, jiggly errors. Those errors in
once-per-second measurements (a guess at frequency) can add up just like
Conrad's weird elevation "gain."

All that said, I would not expect RWGPS figures to be *higher* than the
Garmin figures, but maybe I'm just mis-estimating the magnitude of each
issue, for which my illustrative examples are intentionally extreme.
Still, I suspect that these are some of the issues that are involved.

Finally, there's an inherent problem in the original "question" of
elevation gain. Route profiles are probably fractal if we look closely
enough. Measure (accurately) many times per second or per foot, and we
will accumulate lots of ?superfluous? elevation gain like Conrad. It
will get worse as frequency of measurement goes up. [1] In this way,
Conrad's example illustrates my central point - we have to decide /what
counts/ as elevation gain. Our rough estimates can agree "well enough"
for generous values of "enough," but they are never going to agree
exactly unless we have a fixed measurement method.

[1] Google "How long is the coastline of Britain" to find articles about
fractals and Mandelbrot, etc.

Mark Janeba

On 4/6/2021 7:24 PM, Mark J. wrote:
On 4/5/2021 2:29 PM, Mark cleary wrote:
I have a Garmin 910xt a triathlon type watch but I am a runner and
cyclist. It supposed to have barometric altimeter in it right? Well
the data is seriously in conflict. I notice all the time when I upload
to Garmin connect then Strava the elevation gain is way less than RIde
With The GPS. I don't use RWGP but it uploads since I have an account.
My Ride with the GPS always shows much more elevation gain. Today I
went 53 miles and on Garmin the gain was 1165 and Ride with the GPS it
was 1630. That is fair amount of off and usually that is close to what
will be. I normally don't track this stuff I live in the flatlands but
the data is suspect for sure. More fake news from something.

Deacon Mark


Elevation gain is inherently a tricky subject, and I suspect even more
so for a rider in a relatively flat area.

Say rider August lives on a route over a mountain pass.Â* The road has a
steady uphill grade, which he rides to the summit and back to his house.
Pretty much any reasonable elevation-gain calculation strategy will work
well for August: Summit Elevation minus house elevation, or elevation
differences every 10 seconds accumulated (and throw out negative
differences that mean he's going downhill) or lots of variations on
those themes.

Contrast rider Bertrand who lives in an area that most cyclists would
call "flat" though in fact the elevation varies by as much as 20 feet at
different places in the county.Â* In fact, the actual elevation is
undulating in a very narrow range.Â* Now the choice of elevation-gain
calculation starts to matter.Â* Suppose you add up the differences every
10 seconds (again throwing out negative differences).Â* If Bertrand
crests a ten-foot-tall hill right in the middle of one of those
ten-second intervals, the net elevation difference over that ten seconds
might end up positive and count, or negative and get thrown out, and in
no case will the height of the "summit" be reflected accurately.Â* It's
reasonable to assume that Bertrand is going to miss a fair bit of
elevation gain if those undulations are frequent.

Now let's grant that the 10-second interval method is a bad method and a
straw man.Â* A one-second interval is probably much more realistic for
modern GPS systems.Â* That will still miss some elevation gain, but
probably not that much.

Oh, but wait - what if the undulations are quite small but high
frequency.Â* Suppose cyclist Conrad was on a route that went up a half
inch in one foot of travel, then down a half inch the next foot,
repeatedly, for 10 miles.Â* Again a weird example, this is gonna feel
like washboard, but how much elevation "gain" does Conrad experience?
Half an inch every two feet for 52,800 feet or 1100 feet of elevation
gain.Â* Should we count that as elevation gain on what's an unnaturally
flat course otherwise? (Highest point minus lowest point is a half inch!)

As for RWGPS, it's not clear to me if RideWithGps is using your GPS
elevation data or just your GPS coordinates and then their own internal
elevation data for those locations.Â* I would actually expect that if
they use their own elevation data, they aren't accumulating elevation
every second, but rather "netting out" elevation gain every ?100 feet?
or so, or perhaps longer.Â* So all sorts of elevation gain could be missed.

As for a GPS device measuring altitude gain, remember that GPS altitude
measurement is prone to significant measurement errors, and even though
the best GPS devices have barometers that "smooth" out the data, GPS
data is going to have tiny random, jiggly errors.Â* Those errors in
once-per-second measurements (a guess at frequency) can add up just like
Conrad's weird elevation "gain."

All that said, I would not expect RWGPS figures to be *higher* than the
Garmin figures, but maybe I'm just mis-estimating the magnitude of each
issue, for which my illustrative examples are intentionally extreme.
Still, I suspect that these are some of the issues that are involved.

Finally, there's an inherent problem in the original "question" of
elevation gain.Â* Route profiles are probably fractal if we look closely
enough.Â* Measure (accurately) many times per second or per foot, and we
will accumulate lots of ?superfluous? elevation gain like Conrad.Â* It
will get worse as frequency of measurement goes up. [1] In this way,
Conrad's example illustrates my central point - we have to decide /what
counts/ as elevation gain.Â* Our rough estimates can agree "well enough"
for generous values of "enough," but they are never going to agree
exactly unless we have a fixed measurement method.

[1] Google "How long is the coastline of Britain" to find articles about
fractals and Mandelbrot, etc.

Mark Janeba

Nicely done. About halfway through that, I decide to bring up fractals
and coastlines. You beat me to it.

--
- Frank Krygowski

Am 07.04.2021 um 01:24 schrieb Mark J.:
As for a GPS device measuring altitude gain, remember that GPS altitude
measurement is prone to significant measurement errors, and even though
the best GPS devices have barometers that "smooth" out the data, GPS
data is going to have tiny random, jiggly errors.Â* Those errors in
once-per-second measurements (a guess at frequency) can add up just like
Conrad's weird elevation "gain.

GPS-based altitude gain in flat area is dominated by measurement errors.
After one hour Stand-up padlling on a lake, my mobile phone tells me
of an altitude gain around 20-40m.

This is why Strava recommends to use a map-based elevation gain: take
the x,y coordinates from GPS, align the route to road travel where
meaninguful nd calculate elevation gain from the map altitude data.

Even this map-based elevation gain gives a significant error on my way
to work (but apparently the algorithm has been improved):

In 2017, Strava estimates 52m altitude gain for my route home from work,
including on non-existing hill of almost 20m altitude after 4.5km where
there is nothing
https://www.strava.com/activities/1025358538.

In 2021, Strave estimates 20m altitude gain for the same route
https://www.strava.com/activities/4949599170
The fake hill is gone, and the "sprinting dip" after 10km is measurable
as downhill 3-4m at 4% grade followed by a 2% climb of 2m, just as my
estimations by altitude comparisons with the parallel railroad track are
(1-2m above track level to 2m below track level, to at track lavel).
All the precision I've been looking for in the last years has finally
arrived.

On Tuesday, April 6, 2021 at 4:24:42 PM UTC-7, Mark J. wrote:
On 4/5/2021 2:29 PM, Mark cleary wrote:
I have a Garmin 910xt a triathlon type watch but I am a runner and cyclist. It supposed to have barometric altimeter in it right? Well the data is seriously in conflict. I notice all the time when I upload to Garmin connect then Strava the elevation gain is way less than RIde With The GPS. I don't use RWGP but it uploads since I have an account. My Ride with the GPS always shows much more elevation gain. Today I went 53 miles and on Garmin the gain was 1165 and Ride with the GPS it was 1630. That is fair amount of off and usually that is close to what will be. I normally don't track this stuff I live in the flatlands but the data is suspect for sure. More fake news from something.

Deacon Mark

Elevation gain is inherently a tricky subject, and I suspect even more
so for a rider in a relatively flat area.

Say rider August lives on a route over a mountain pass. The road has a
steady uphill grade, which he rides to the summit and back to his house.
Pretty much any reasonable elevation-gain calculation strategy will
work well for August: Summit Elevation minus house elevation, or
elevation differences every 10 seconds accumulated (and throw out
negative differences that mean he's going downhill) or lots of
variations on those themes.

Contrast rider Bertrand who lives in an area that most cyclists would
call "flat" though in fact the elevation varies by as much as 20 feet at
different places in the county. In fact, the actual elevation is
undulating in a very narrow range. Now the choice of elevation-gain
calculation starts to matter. Suppose you add up the differences every
10 seconds (again throwing out negative differences). If Bertrand
crests a ten-foot-tall hill right in the middle of one of those
ten-second intervals, the net elevation difference over that ten seconds
might end up positive and count, or negative and get thrown out, and in
no case will the height of the "summit" be reflected accurately. It's
reasonable to assume that Bertrand is going to miss a fair bit of
elevation gain if those undulations are frequent.

Now let's grant that the 10-second interval method is a bad method and a
straw man. A one-second interval is probably much more realistic for
modern GPS systems. That will still miss some elevation gain, but
probably not that much.

Oh, but wait - what if the undulations are quite small but high
frequency. Suppose cyclist Conrad was on a route that went up a half
inch in one foot of travel, then down a half inch the next foot,
repeatedly, for 10 miles. Again a weird example, this is gonna feel
like washboard, but how much elevation "gain" does Conrad experience?
Half an inch every two feet for 52,800 feet or 1100 feet of elevation
gain. Should we count that as elevation gain on what's an unnaturally
flat course otherwise? (Highest point minus lowest point is a half inch!)

As for RWGPS, it's not clear to me if RideWithGps is using your GPS
elevation data or just your GPS coordinates and then their own internal
elevation data for those locations. I would actually expect that if
they use their own elevation data, they aren't accumulating elevation
every second, but rather "netting out" elevation gain every ?100 feet?
or so, or perhaps longer. So all sorts of elevation gain could be missed.

As for a GPS device measuring altitude gain, remember that GPS altitude
measurement is prone to significant measurement errors, and even though
the best GPS devices have barometers that "smooth" out the data, GPS
data is going to have tiny random, jiggly errors. Those errors in
once-per-second measurements (a guess at frequency) can add up just like
Conrad's weird elevation "gain."

All that said, I would not expect RWGPS figures to be *higher* than the
Garmin figures, but maybe I'm just mis-estimating the magnitude of each
issue, for which my illustrative examples are intentionally extreme.
Still, I suspect that these are some of the issues that are involved.

Finally, there's an inherent problem in the original "question" of
elevation gain. Route profiles are probably fractal if we look closely
enough. Measure (accurately) many times per second or per foot, and we
will accumulate lots of ?superfluous? elevation gain like Conrad. It
will get worse as frequency of measurement goes up. [1] In this way,
Conrad's example illustrates my central point - we have to decide /what
counts/ as elevation gain. Our rough estimates can agree "well enough"
for generous values of "enough," but they are never going to agree
exactly unless we have a fixed measurement method.

[1] Google "How long is the coastline of Britain" to find articles about
fractals and Mandelbrot, etc.

Mark Janeba

The one problem with barometric altimeters is there can be two sources of errors: 1. When a front moves through the barometric pressure changes and you can show errors. 2. As you point out the sampling rate is important for accuracy. Usually not for absolute altitude for which they are surprisingly accurate (Over the years I've had perhaps a dozen different barometric pressure altimeters and they are all in very close agreement.) but the sampling rate really does screw up the rate-of-climb or grade calculations. On all of my bike computer type altimeters they show 12% in several spots and all are in agreement. The Garmin usually shows 10% in these same spots and occasionally 11%.

As for using maps to calculate altitude. What makes you think that these altitudes weren't measured with the standard aircraft barometric pressure altimeter?

On Wednesday, April 7, 2021 at 2:26:12 AM UTC-7, Rolf Mantel wrote:
Am 07.04.2021 um 01:24 schrieb Mark J.:
As for a GPS device measuring altitude gain, remember that GPS altitude
measurement is prone to significant measurement errors, and even though
the best GPS devices have barometers that "smooth" out the data, GPS
data is going to have tiny random, jiggly errors. Those errors in
once-per-second measurements (a guess at frequency) can add up just like
Conrad's weird elevation "gain.
GPS-based altitude gain in flat area is dominated by measurement errors.
After one hour Stand-up padlling on a lake, my mobile phone tells me
of an altitude gain around 20-40m.

This is why Strava recommends to use a map-based elevation gain: take
the x,y coordinates from GPS, align the route to road travel where
meaninguful nd calculate elevation gain from the map altitude data.

Even this map-based elevation gain gives a significant error on my way
to work (but apparently the algorithm has been improved):

In 2017, Strava estimates 52m altitude gain for my route home from work,
including on non-existing hill of almost 20m altitude after 4.5km where
there is nothing
https://www.strava.com/activities/1025358538.

In 2021, Strave estimates 20m altitude gain for the same route
https://www.strava.com/activities/4949599170
The fake hill is gone, and the "sprinting dip" after 10km is measurable
as downhill 3-4m at 4% grade followed by a 2% climb of 2m, just as my
estimations by altitude comparisons with the parallel railroad track are
(1-2m above track level to 2m below track level, to at track lavel).
All the precision I've been looking for in the last years has finally
arrived.
On courses where the grade never exceeds 5% I never count that as climbing because while rolling waves can easily add up to your altitude errors it isn't as if you're working for it.

Am 07.04.2021 um 16:35 schrieb Tom Kunich:
As for using maps to calculate altitude. What makes you think that
these altitudes weren't measured with the standard aircraft
barometric pressure altimeter?

I don't care how the maps were created (my uncle is a retired geodesist,
he would know if I'd ask him).

My point was that GPS of mobile phone quality sucks for "altitude gain"
calculations.

Rolf

On 4/7/2021 10:35 AM, Tom Kunich wrote:


The one problem with barometric altimeters is there can be two sources of errors: 1. When a front moves through the barometric pressure changes and you can show errors. 2. As you point out the sampling rate is important for accuracy. Usually not for absolute altitude for which they are surprisingly accurate (Over the years I've had perhaps a dozen different barometric pressure altimeters and they are all in very close agreement.) but the sampling rate really does screw up the rate-of-climb or grade calculations.

I'm not much into riding data. But long ago, I was given a Nike watch
(Lance Armstrong model) with a barometric altimeter and electronic
compass. I had some fun with it, but it lost its mind after a few years.
The altimeter began acting as if I were riding upward in a hot air
balloon. Several attempts at disassembly yielded no fix. It now sits in
my workshop hoping for a miracle.

--
- Frank Krygowski

On 4/7/2021 2:26 AM, Rolf Mantel wrote:
Am 07.04.2021 um 01:24 schrieb Mark J.:
As for a GPS device measuring altitude gain, remember that GPS
altitude measurement is prone to significant measurement errors, and
even though the best GPS devices have barometers that "smooth" out the
data, GPS data is going to have tiny random, jiggly errors.Â* Those
errors in once-per-second measurements (a guess at frequency) can add
up just like Conrad's weird elevation "gain.

GPS-based altitude gain in flat area is dominated by measurement errors.
After one hour Stand-up padlling on a lake, my mobile phone tells me of
an altitude gain around 20-40m.

I recall owning an Avocet 50 bicycle computer with a barometric pressure
based altimeter. It was not great. The GPS apps that determine your XY
position then look up the altitude are very accurate.

I have one mobile app that displays 3 altitudes at once, GPS-based, map
based, and barometric pressure based. They are way different.

This is why Strava recommends to use a map-based elevation gain: take
the x,y coordinates from GPS, align the route to road travel where
meaninguful nd calculate elevation gain from the map altitude data.

Even this map-based elevation gain gives a significant error on my way
to work (but apparently the algorithm has been improved):

Isn't there an app that uses location based altitude? It would use more
mobile data to grab the elevation based on longitude and latitude but it
would be very accurate.