UKC

I went exploring the Peak forest canal the other day from Ashton, going towards Marple. Checked the elevation graph afterwards and it jumps from 50ft to about 550ft, almost vertically. Now I don't know much about canals, but I know they tend not to do that. On the return journey it drops down again at the same spot.

Put it down to a glitch, but the same thing has happened again today. Never had this happen before... Have I discovered since sorry if spacetime Rift? 

Any ideas? 

Elevation from GPS is notoriously sketchy, it's usually the first to go weird from any signal variance. This is why many better GPSs have real barometric altimeters on them. Even these can be a bit unpredictable if the weather changes quickly.

I've just never had any weirdness at all with strava. I've had it lose GPS for a bit, pick it up again, and then draw a straight line between the two points, but never this. Ho hum. I was hoping for the spacetime rift. 

I get this if I run along the sea front near us. It’s dead flat and sea level the whole way, but garmin think I am jumping up and down all over the place. By the end of a flat 5k run they reckon I’ve racked up about 400m ascent. 

I don’t get it anywhere else, but it’s consistent on that route. I can only think there is something off with the mapping they use there. It doesn’t seem like GPS variability as the track is always correct and I’m quite far from anywhere where their max elevations would be possible. The GPS would have to be out by a mile or two. 

That would assume they are using surface snapping to a DEM database. That's fairly unlikely, and it's more likely they're just logging GPS 3D fixes; the GPX profile should show that.

You may be getting multi path off the sea... assuming when you say 'dead flat', you mean there are no sea cliffs in the area.

Marple locks are pretty steep.

Yes, no sea cliffs nearby.

Interesting. Am I right in crudely interpreting that as signals possibly being reflected off the sea causing issues with the estimate of altitude? I’d often wondered how the watch calculated altitude, hadn’t thought of 3D GPS fixes. That’s kinda cool.

I was assuming that garmin’s “corrections” to the watch’s altitude reading used some kind of mapping. If I disable their post hoc corrections on the online platform, the altitude as recorded by the watch on this route is much closer to reality. The errors are also very consistent which led me to think it couldn’t be iffy GPS readings. I do know next to nothing about the workings of GPS though. 

Edit: Just had a look at garmin’s literature. The “corrected” elevation feature, which seems to be the issue, throws out the watch’s recorded elevation entirely and pulls elevation from “professional survey data”. 

This was only about 4 or 5 miles along from Ashton so no where near Marple. Don't know the place names so it's irritating not being able to pin it down. Need to investigate further... 

My comedic dulcet tone that I wrote it in doesn’t really travel well over the internet Lovely route on the whole though, grew up in Hyde/Gee Cross so spent my youth between Dukinfield and Bredbury!

That's the exact problem; the reflected signals lengthen the time of flight for the signals from some satellites (those that are 'opposite' the cliff). If the receiver is on the side of your body facing the cliffs, it is likely to obscure (shadow) the direct path to the satellite, and, with the advent of very sensitive receivers, the reflected signal is 'accepted' into the computed solution. what will usually happen in this circumstance is that the receiver will compute a 'goodness' figure for the fix (usually with a proprietary algorithm). This is sometimes expressed as an error circle.

This shadowing & reflection effect can be quite significant in mountainous areas, and is one that is well worth being aware of. It can easily shift a computed fix by a few hundred metres.

And, no, WAAS/EGNOS won't help, as they are intended for airborne use, to correct tropo/iono disturbances. They have no knowledge of your reflection/multipath/shadowing environment, so cannot provide any correction for that.

[edit: oh, bugger, I missed the 'no' in your reply... yes, water acts as a pretty good reflector. Your body may still be providing a shadow that allows the sea reflection to be used. But, since you're not very high, the additional path length can't be very large, so I'm tending towards the granularity of the DEM, but, if there are no cliffs or hills nearby, that should not have any large errors. hmmm....]

Think of the computed 3D solution as finding the intersection between spheres centred on each of the satellites (radius of each sphere being the distance from satellite to your receiver). Multilateration (true and pseudo-range...)

https://en.wikipedia.org/wiki/True-range_multilateration

https://en.wikipedia.org/wiki/Multilateration

Interesting. My guess would be that they are using the SRTM data; OruxMap on Android can use the SRTM DEM files. Those are multiple hundred MB, so I doubt they are stored on the watch, but they might be used by post-processing software (and may even use a web-paged query engine). And that DEM data may be in error, especially at cliffs, because it's only on a 90m or 30m grid (depending on whether it's the 3arcsecond, or 1 arcsecond survey data).

Sorryyyyyy.... Right over my head that time. Doh 

Yeah the data for the corrections are definitely not stored on the watch, the corrections are only applied after the file is uploaded to Garmin’s servers if there aren’t barometric readings.

Really interesting. Something for me to do a bit more reading on, thanks for the links and the explanations. Regardless of whether it’s the explanation in this case or not, the GPS stuff is fascinating and good to know.

Interestingly Strava also apply a “correction” to data from watches without a barometer, and on this route give a believable output based on the same file so presumably use different survey data. I’ll be seeing if I can find out what survey data garmin use and try to see what’s going on (although not holding out much hope that they publicise that! I’ll see if I can look into the data you mentioned though). 

Welcome to the new sport of extreme narrow boating.

Location (X,Y) on the earths surface vs Location (X,Y,Z - where z = altitude) is a good deal trickier to calculate with GPS.

Location (X,Y) needs at least 3x GPS satellites in view in order to pinpoint an exact position.

Location (X,Y,Z) needs at least 4x GPS satellites, one of which needs to be close to overhead for accuracy, in order to pinpoint an exact position.

There are, I think, 31 GPS satellites in the constellation ... so on the face of it easy.  Remember though that those 31 satellites need to cover the entire surface of the earth.  In practice, if you were running along say a tree lined canal ... you might only get a couple at any one time.

As a result, most consumer GPS calculate your Location (X,Y) then perform a lookup in a table for the known altitude at that (X,Y) location.  In most cases, for runners, this is more than sufficient.

Perfect spot for an Everesting attempt on your bike

That is some lock flight!

It certainly makes me feel good when I look back and think “wow, I’m really picking up the pace on those hilly runs”. At least until I look at the map and realise which route I’m looking at. 

Loads of entertainment value in trying to get decent elevation data from Garmin! 

I entered a virtual race which had a specific course but offered those unwilling to travel the chance to create a local copy - needed to be 16.45 miles with at least 200 metres of ascent - so I plotted the original course plus a local one using Garmin Connect. Original course seemed to have 265 metres of ascent in 26.5km. Loaded it to my Fenix 6 to get pace and navigation instructions.

Ran the course, watch recorded 321 metres of ascent. Garmin Connect downloaded the data and said 359 metres of ascent (with elevation corrections disabled, as normal for a barometric instrument). Enabling corrections then gives a figure of 310 metres - pretty close to the watch. Unfortunately, if you run a preloaded course it seems as though it ignores the watch value and replaces it with an invalid calculated value - and not even the 265m value given at course creation. None of this would matter too much if the watch value overrode the calculated one. 

PS  just inspected the 30km course I ran last week - watch says 269m, map says 271m or 261m with corrections enabled - pretty acceptable. Must be some duff data points in the original course elevation map - there is a theory that crossing bridges inserts false level data (down then up) and 3 crossings of the A14 might explain the differences...

No they don't, and never have. They don't have the storage required for a DEM to do height lookup. It's easy enough to get four satellites in view, in a reasonable configuration. Especially with a modern receiver able to fuse GPS, Glonass, Beidou and Galilleo.

I've just turned on my phone's GNSS receiver, and it's reporting seeing 31 satellites, and computing a fix from 20. I'm indoors, sitting on the shitter...

At least in the early days the GPS seemed to x-ref with mapping data for a sanity check. Don't know if it still does. The mapping data wasn't always 100% - climb around the corner from my house used to show with a downhill stretch in the middle - tell that to my legs - that data has been sorted out now.

Those monthly 'Run Climbing Challenges' and stuff are dominated by people with either private profiles or live in Holland and climb the height of K2 every morning

I'm sure I read somewhere that either the Garmin or Strava corrections were made p by averaging the height data from devices with barometric altitude (Garmin Edge etc). The problem with this being if only one or two people use that section with a barometer and their device throws a wobbly by having rain get in the barometer hole or something then it messes up the other elevation. I've definitely seen this on segments where it's flat or downhill and it's telling me it's a beastly climb

That's interesting, don't think that's what was happening with my hill. It's had 1000s of ascents - I've done about 500 too many

GARMIN

https://support.garmin.com/en-US/?faq=dRY70Lc6yv2oY3eam1ZWxA#:~:text=Device....

"Devices without a  barometric altimeter:

Devices will rely upon Garmin Connect to provide elevation information.  The GPS data gathered from your activity is calculated using professional surveys which contains elevation plots.  This allows Garmin Connect to give you an estimated elevation reading for the activity that you recorded." 

Maybe this one is better?

GARMIN

"GPS heights are based on an ellipsoid (a mathematical representation of the earth's shape), while USGS map elevations are based on a vertical datum tied to the geoid (or what is commonly called mean sea level). Basically, these are two different systems, although they have a relationship that has been modeled.

The main source of error has to do with the arrangement of the satellite configurations during fixed determinations. The earth blocks out satellites needed to get a good quality vertical measurement. Once the vertical datum is taken into account, the accuracy permitted by geometry considerations remains less than that of horizontal positions. It is not uncommon for satellite heights to be off from map elevations by +/- 400 ft. Use these values with caution when navigating."

https://support.garmin.com/en-US/marine/faq/QPc5x3ZFUv1QyoxITW2vZ6/

I was looking at Finlay Wild's and Doug Harvie's  epic Cuillin run from last year  on Strava (by way of route research rather than emulating it!) and there is a huge difference in their elevation data: 4202m for FW and 2587m for DH with 600m being piled on top of Gars-bheinn - which grew to over 1300m!     

Incredible effort by the way  - a mind blowing 2.5 hr ridge time within a 30k total run in under 5 hours 43 minutes...

That's talking about post-processing of captured GPS data: "This allows Garmin Connect to give you an estimated elevation reading for the activity that you recorded."

The GPS receiver itself does not use terrain data. The 3-arcsecond SRTM data for the UK alone is 275MB. That gives a grid size of about 90m. Since a GPS receiver has global coverage, you can imagine the size of store required for a global DEM. Whilst that level of storage is now eminently possible, it certainly was not when GPS receivers were first introduced  Besides which, GPS also works in the air...

A GNSS receiver computes a 3D fix.

A mapping app that uses GNSS receiver fixes might also use a DEM to provide an estimated snap-to-ground height. OruxMaps will do this on Android, but that's because I have the SRTM DEM data installed on my phone, and Orux is able to use that data. A modern GNSS receiver, equipped with adequate storage, and filled with the relevant DEM data, may also be able to provide that function, but it would have to make it clear it was doing so, given the general purpose nature of such a receiver, and the possibility that it is not a ground-based receiver.

Geoid transformations are routinely performed by GNSS receivers. GPS natively uses the WGS84 geoid. If you are using OSGB mapping, it will transform to the OSBG36 Airy geoid, provided you have told it to do so, although most receivers will automatically so this if you select OSGB as the coordinate system.

OP:  "Strava GPS Elevation weirdness.  Checked the elevation graph afterwards and it jumps from 50ft to about 550ft, almost vertically."

I didn't say it was calculated on device nor did I say the receiver uses terrain data ... but I can now that's what you've understood I meant.

Unless I'm mistaken the OP is talking about their experience in the Strava app after completing his/her run.

I meant only to highlight that it is a fact that many users experience of their altitude (through Strava [1] or Garmin Connect[2] for example) will have been calculated or adjusted using a terrain map.

This is a fact - irrespective of whether or not your cell phone/gps watch might have been able to find 30 satellites or not - it will still get adjusted/corrected when it's brought back into Strava.

[1] https://support.strava.com/hc/en-us/articles/115000024864-Strava-s-Elevatio...

[2] https://support.garmin.com/en-US/?faq=dRY70Lc6yv2oY3eam1ZWxA

Hi, yeah - sorry that was exactly how it was.  It's only when I get back after a ride (and eat and drink and shower and rest and sleep) that I have a look at what's gone on.  Strava normally takes a few seconds to process everything once you've clicked finish / save to be able to see your route / distance / elevation.

Going to head down there again at some point and do a smaller run, see if I can pinpoint where the spacetime rift is actually happenning .  Which isn't a problem...it's a lovely area

I did, because you mentioned the difficulty of seeing enough satellites, and 'consumer GPS'. I took that to mean the actual receiver, rather than post-processing.

Still, we've got to the bottom of it...