Fix Elevation - Free monthly API usage exceeded

[Jörn R.]

FYI - I just checked the problem that the "Fix Elevation Data" function is not working.

Root-cause is the fact that the free monthly API usage was exceeded. According to

the documentation here: https://developer.mapquest.com/plans ist 15000 calls to the API.

Since the error handling logic of the API seems to have changed, there is no message

to the user what happened - and even the existing elevation data is overwritten with "0"

(if you save it).

I will add an updated error handling, so that existing data is not overwritten if the API

usage is exceeded. Besides that - not much we can do.

Cheers.

Joern

[Alex Harsanyi]

In a hobby project of mine, I implemented elevation correction by averaging the recorded elevation from neighboring GPS points form different activities.  This produces really good results as long as there are multiple activities along the same routes.  It even works where the elevation change is sub 3 meters. The algorithm does not require any external API, as it just uses the data from previous activities.

You can find the implementation below.  It is not in C++, so it is not directly usable in GoldenCheetah, but the code is heavily commented and I can also explain how it woks, if you are interested:

     https://github.com/alex-hhh/ActivityLog2/blob/master/rkt/elevation-correction.rkt

Maybe the GC project could implement something similar?

Best Regards,
Alex.

[Yuri Sá]

Hi! I was having this issue too... I like this feature very much since elevation data from GPS is sooooooo off.

Cool thing GC have such  vibrant community...

My question is, it is possible for each user to use a API key, since the plan is free...

So, is there any interest in GC Dev to add a API KEY in the athlete settings, so we all can have our own API consumption???

If so, I would be more than happy to help implement it.

[Jean Div]

Very smart! I like the idea of not having to dial-in to auto-correct values, and this makes a lot of sense - cyclists are creatures of habit when it comes to routes, so I'd expect that 95% of routes would have some reference (just dragged in a local hill, and the GC asked me if I wanted to include the other 284 rides:-).

The 2 other 'more simple' auto fixes that would be good for altitude are:

1. Set start and end elevation the same where GPS points show start & finish at the same place (saves those slowly downward creeping profiles for cold early morning rides that end in the midday heat)

2. Set minimum altitude to zero, and where altitude suggests lower apply the offset to all values

[Guy Melville]

Hi Alex,

How are you?

This sounds like a great workaround.

I tried  following your link, but I got a 404 error. Have you taken it down?

It would be good if the GC team could implement such a fix. I tried to fix the elevation early afternoon GMT on the 1st Feb and the API usage had already been used up. 

Your fix doesn't work for new routes from what you say so perhaps being able to enter the user's own Mapquest key at runtime might be a good solution if the Mapquest licence allows?

Any comment from the GC Developer team on this? The feature becomes redundant if the usage quota is used  up on the first of the month. 

This is such a great feature as the low vertical resolution of Strava elevation data makes a nonsense of the Power Estate calculation in GC.

[Ale Martinez]

El miércoles, 3 de febrero de 2021 a la(s) 12:07:22 UTC-3, guy.t.m...@gmail.com escribió:

Any comment from the GC Developer team on this? The feature becomes redundant if the usage quota is used  up on the first of the month. 

From https://developer.mapquest.com/devblog/2015/08/17/mapquest-free-open-license-updates-and-changes/

>Why are you moving away from offering Open services? We are not moving away from offering our users access to Open Data.

>We are making changes to our Open APIs and SDKs to ensure we can continue to offer our users the best possible product.

>We’re removing unlimited access and requiring people to sign up for an AppKey based on their specific needs.

>We still offer free access through a plan that limits users to 15,000 transactions per month

The previous model was a good match for GoldenCheetah, the new one not so. After that the ability to configure your own AppKey at build time was introduced so,

If you are a developer or at least can build from source, you can apply for your own AppKey, add it to gcconfig.pri, and your private build will have its own quota.

Technically, it would be easy to change the AppKey from a build time parameter to an optional parameter for the Fix Elevation data processor,

but I don't know if it is a fair to the service provider, personally I am not comfortable with that decision but I am not in charge either.

[alexha...@gmail.com]

On Wednesday, February 3, 2021 at 11:07:22 PM UTC+8 guy.t.m...@gmail.com wrote:

Hi Alex,

How are you?

This sounds like a great workaround.

I tried  following your link, but I got a 404 error. Have you taken it down?

The project was re-organized in the last 3 years, and the file is now located here: elevation-correction.rkt

 

It would be good if the GC team could implement such a fix. I tried to fix the elevation early afternoon GMT on the 1st Feb and the API usage had already been used up. 

Your fix doesn't work for new routes from what you say so perhaps being able to enter the user's own Mapquest key at runtime might be a good solution if the Mapquest licence allows?

Well, the algorithm can use data from any routes or partial route sections that the new route covers.  This means that, 

  * If the new route is "out and back" it already has two sets of data and the "out part" can be matched with the "back part" and vice-versa  

  * If the new route is a loop that runs three times, there are already 3 sets of data to average from.  

  * If a section of your new route was covered by another ride or rides, it can correct elevation on that section (after many years of riding around my city, even if the route is "new", all portions of it would be covered by some previous ride).

  * If you ride the same route a second time next week, you can go back to the first one and correct the elevation with the new data you have.

The algorithm works better the more data you have from previous rides, but the only time it does not work at all is when your ride is a once-in-a-lifetime ride from point A to point B with no overlaps.

And when it works, it works really well.  The image below is from an "out and back" run along the coast, which I've done many times.   The top graph is the original elevation and you can see that it is slowly dropping and the finish is about 5 meters lower than the start -- this is because we had a weather front passing and the barometric pressure was increasing, so the barometric altimeter in the watch was fooled.  The bottom graph shows the corrected elevation, and you can more clearly see that the second half is a mirror of the first.

Barometric altimeters are affected by weather.  The highest 1 hour "altitude change" for a fixed position (where altitude didn't actually change) was 14.5 meters or about 47 feet.  I analyzed my altitude data from barometric readings here: Barometric Altitude Measurement (alex-hhh.github.io)

Alex.

[Nigel Van de Velde]

I really miss this function as well. Elevation data coming from garmin connect exports (Garmin FR735) are awful.

For anyone interested, you can find an alternative on:

https://www.gpsvisualizer.com/convert_input

Takes some extra time, but works well.

Kind regards,

Nigel

[TWINGSISTER TWINGSISTER]

I think I bumped into this limit and cannot use Fix Elevation anymore. Got a 403 error! I have a strong feeling about it. Both the Mapquest key and possibly also the URL (so that Mapquest is going to be an option every user has to choose or not) should be exposed as user-level parameters/variables to configure.

Cheers

[TWINGSISTER TWINGSISTER]

To overcome this situation (error 403 in connecting to mapquest)  where I have to cycle on a flat land (is this too bad?) I found this

https://www.gpsvisualizer.com/elevation

that did a great job.

[Ale Martinez]

El domingo, 13 de junio de 2021 a la(s) 15:30:52 UTC-3, twing...@gmail.com escribió:

To overcome this situation (error 403 in connecting to mapquest)  where I have to cycle on a flat land (is this too bad?)

Error 403 seems to be a transient service error unrelated to the quota problem.

To avoid the transactions limit error the API Key will be an optional parameter for Fix Elevation to be set like any other data processor parameter in the next build, that is, in the dialog for interactive execution of configured in https://github.com/GoldenCheetah/GoldenCheetah/wiki/UG_Preferences_Data-Fields#processing.

https://github.com/GoldenCheetah/GoldenCheetah/commit/061cb9328c62b4689041dd8d39f734ab47b0aaad

[Poiz Phil]

Considering the bad quality of the open elevation data and their service limitations, would using local stored DEM reference an possible enhancement for GC?

As an example, QMapShack (QMS) software permits to correct elevation data either with local stored DEM reference (tiles as .hgt files, .vrt description) or web-based services (.WCS description).

Yours sincerely,  

Phil

[Ale Martinez]

El lunes, 19 de agosto de 2024 a la(s) 11:49:54 a.m. UTC-3, Poiz Phil escribió:

Considering the bad quality of the open elevation data and their service limitations, would using local stored DEM reference an possible enhancement for GC?

As an example, QMapShack (QMS) software permits to correct elevation data either with local stored DEM reference (tiles as .hgt files, .vrt description) or web-based services (.WCS description).

If you want to give it a try we accept patches, guidelines for contributions are in https://github.com/GoldenCheetah/GoldenCheetah/wiki/Developers-guide 

[Ale Martinez]

BTW, this feature could be implemented entirely in Python without the need to change GC code nor build from source: https://github.com/GoldenCheetah/GoldenCheetah/wiki/UG_Special-Topics_Custom-Data-Processors-in-Python