Calculate vertical gain in track statistics

[PowerUser64]

It would be very nice if the vertical gain for a track could be displayed as a statistic in the tracklist. Displaying the current vertical gain in the track tab would be an idea too.

PS: Thanks for the great software!

[GrazianoCapelli]

Hi, how do you define the vertical gain? For example:

• the sum of ascent and the sum of descent (2 separed values)
• the difference between the heights of the start and the current point
• the difference between minimum and maximum height of the track

[PowerUser64]

I think the "proper" definition vertical gain is the sum of every gain in altitude throughout a route.

Here's an idea of how to implement it:

1. Loop through elevation values until you find one that is larger than the previous
   • Take note of the previous altitude in variable low
2. Loop through values until you find one lower than the previous
   • Take note of the previous altitude in variable high
3. Add the difference between high and low to the vertical gain
4. Repeat until you run out of altitude values

This will return the vertical gain in situations where, for example, you go down and up a valley in a route, as well as situations like tracking a skier who is going up and down a lot.

It might be good to smooth the data with something like a moving average function before processing to remove inaccurate or noisy reads.

[PowerUser64]

This might also be a good statistic to add to the Track tab.

[GrazianoCapelli]

The app already calculates and stores the altitude gain and loss of every track (and already implements a filter in order to flatten the spikes), but the two values are used only to calculate the real length of the track (where the precision of it is not so critical). The two values are not shown into the app interface.

We choose this approach because the GPS altitude is not suitable to obtain good values for vertical distances, specially when the altitude increases and decreases many times. If you want a confirmation of it, you could simply open some GPX tracks with many online services (or apps) that try to calculate them basing on altitudes: you will have senseless values, that can be also completely different basing on the filters applied.

I think that at this time we should stay stick to that approach.

For information, we have in plan to implement the possibility to use the barometric altitude where the barometric sensor is present (issue #166): the barometric altitude is good to calculate altitude gain and loss, thus - if you agree - we would leave this issue open in order to evaluate and consider the implementation of this feature if/when the barometric altitude will be implemented.

[PowerUser64]

That is very interesting. Since GPS isn't a good way to get the elevation, we could instead use the projected ground elevation of the GPS coordinates as provided by a service like Open-Elevation, which pulls data from the SRTM Digital Elevation Database. Since the barometer isn't always a good source of accurate readings (due to weather changes), it may not be suitable as the primary method of collecting readings.

Instead, we could use the barometer data to help find which locations to lookup with an elevation API (we only need to lookup the peaks and valleys of the data). To do this, we could run the vertical gain algorithm I described in an earlier message on the barometer data, taking note of all the peaks and valleys in the data. Then, look up the elevation at the coordinates where the barometer elevation reaches a peak or a valley. Additionally, we should look up some nearby measurements to check if the perceived altitude change was simply a result of the weather changing, so we can check the barometer elevation with gradient descent on the real elevation.

Alternatively, we could use the GPS altitude in place of the barometer data for this. It may not be as accurate, but it should at least give an idea of when elevation gain/loss changes directions. We can then look up the elevation of these changes with an API. Although, if we don't mind looking up the elevation of every coordinate in a track (or at least every coordinate separated by X distance), we could just do that instead.

Another approach would be to use the barometer in conjunction with the less accurate GPS elevation to get accuracy of the barometer, and then sanity check the barometer data with the GPS data to find places where the weather could be influencing the data. These places could be checked against an elevation API or ignored. This approach also has the benefit of working offline, as well as while not on the ground.

An idea that combines both of these approaches would be to use the option that doesn't use an API when tracking is active, and then provide a menu option in the Tracklist to "re-calculate" the vertical gain, which could use an API to do so.

It's a tough problem.

I know from experience that the barometer can be a bad source of elevation data if a storm rolls in while taking measurements, so these are some potential countermeasures to hopefully help mitigate problems caused by weather.

[GrazianoCapelli]

We can use online services to obtain the elevation only if we assume that all the users record the track following the ground, but it is often a wrong assumption; for this reason we would not use any of them.

Another approach would be to use the barometer in conjunction with the less accurate GPS elevation to get accuracy of the barometer, and then sanity check the barometer data with the GPS data to find places where the weather could be influencing the data. These places could be checked against an elevation API or ignored. This approach also has the benefit of working offline, as well as while not on the ground.

In issue #166 we are implementing a fusion between Barometric and GPS altitude, in order to compensate the barometric errors due to wheather changes. We have already opened the issue-166 branch, where we implemented the sensor reading, the recording of the barometric pressure into the database, and we are testing different fusion filters with SciLab in order to obtain the best results during the exportation of the tracks. You can watch some data into the PostProcessor/BaroSensorFusion/Scilab folder, when you can view also some PNG/SVG of the graphs. Obviously it is a work-in-progress; we cannot plan when/if it will be implemented into the production app.