Auto Edit Elevation

[justintime]

In the software that came with my old Polar S710, that has a barometric altimeter, there is a possibility to set start and finish elevation the same, while the software "tilts" the whole graph accordingly (i e calculates a linear shift in between the start and the finish elevation.

Now witn the 910XT coming out, that has a baro altimeter, I'd like to see the same functionality in the Edit - Datatracks window for elevation. And I'd like to have it even better: let us (re)set the start value, an optional intermediate value, and the finish value, and have the software recalculate the in between data linearly.

I hope I'm making sense, and am actually understood!

[admin]

A better solution already exists:

Elevation Correction Plugin

[justintime]

A better solution already exists:

Elevation Correction Plugin

I am well aware of the elevation correction plugin. I have used ST for 6 years, and have been using the EC plugin for several years to correct the lackluster GPS elevation data, which it is good at.

But elevation correction by GPS location is not the best correction solution for devices with baro altimeter.
- The grid is 90/90 (30/30 in the the US, but most of the world isn't in the US, and still that's a relatively large area)
- It is dependant in the first place of a correct-ish GPS track.
- It cannot handle small shifts.
- It cannot handle overpasses or underpasses, or other changes by man or mother nature.

Baro altimeter is superior to elevation correction, if one can compensate for pressure changes due to weather changes.
- The grid is the device's sample rate (MUCH better than 90/90 in any case).
- It is independant of the GPS track (which means it even works without GPS, eg with the footpod).
- It handles small shifts easily.
- It handles overpasses and underpasses, and other changes by man or mother nature, of course, since it doesn't even have to know about them to work anyway.

This is why I wrote my suggestion, and I maintain my suggestion (I'm sorry I didn't specify my motivation in the first post).

[Stumpjumper68]

I vote for it too.

My Edge 705 sometimes doesn't find the correct elevation at start (OK I don't wait any longer than 5 minutes, hey I would like to bike). During the first 30 minutes it auto adjust the elevation, I'm trying to adjust it later on by changing the data
track in ST, but it's very cumbersome.

So if there's a chance to implement that feature I'll very much appreciate it.

[old_man_biking]

This IS already implemented - by Waypoints and Courses plugin.
The plugin provides an Add/Fix elevation action which tries to determine the type of elevation error first:
1. "noisy" GPS elevation with
2. drifed barometric elevation

In case 1 the plugin will replace the elevation track by DEM elevation - with all its limitations
In case 2 the plugin will use DEM elevation to remove the drift but maintain the fine resolution of the barometric elevation
The next plugin version will add another compensation: when there's a waypoint near the activity start, it will use its elevation as the start elevation.This can compensate drifts of the barometric altimeter while the GPS was turned off.

[justintime]

This IS already implemented - by Waypoints and Courses plugin.
The plugin provides an Add/Fix elevation action which tries to determine the type of elevation error first:
1. "noisy" GPS elevation with
2. drifed barometric elevation

In case 1 the plugin will replace the elevation track by DEM elevation - with all its limitations
In case 2 the plugin will use DEM elevation to remove the drift but maintain the fine resolution of the barometric elevation
The next plugin version will add another compensation: when there's a waypoint near the activity start, it will use its elevation as the start elevation.This can compensate drifts of the barometric altimeter while the GPS was turned off.

While your plugin probably does very well what it is designed for, it still does not seem to do what I'm requesting (by looking at the description). It is still relying on GPS, and (thus) still (AFAICS) does not handle over-/underpasses or changes from the grid data that has happened in a secure way, or does it? How does it distinguish between a bridge and baro drift?

Comments?

[langlaeufer]

the baro drift error has a very low frequency, bridges, woods, buldings are high frequency errors. the plugin filters out high frequencies and only correct the low frequency part. So baro track is realy keept and corrected and not simply replaced.

[old_man_biking]

I couldn't have explained that better
@justintime: try it out, it works well

[justintime]

I couldn't have explained that better
@justintime: try it out, it works well

Yes, again, I'm absolutely sure it is superb at what it's designed for, but:

"In case 1 the plugin will replace the elevation track by DEM elevation - with all its limitations"
"In case 2 the plugin will use DEM elevation to remove the drift but maintain the fine resolution of the barometric elevation"

I still don't see how your plugin handles the problem without relying completely on GPS data + DEM elevation? Am I missing something here?

What if the GPS data and/or the DEM elevation data is not there (e.g. just footpod data + baro data) or just plain wrong at some points/areas? Is there a possibility to feed the plugin with MY data (start data, end data, some intermediate data) and have it extrapolate (or should it be intrapolate!) from there?

[old_man_biking]

Try it out and I'll answer remaining questions.

[langlaeufer]

Ok. I think the point absolute no DEM elevation or no GPS Track is a Problem - can not handeled by the plugin.

In this case the user have to define identical points or set some heights manualy. That is not implemented yet?

[dbrillha]

I have the latest W&C plugin, and use a 910xt.

Most of the time, it does not detect that the data is barometric, and simply overwrites my baro data with digital map data. I'm not sure how it determines if it is baro or not. Sometimes it does detect baro and then offers to compensate drift. But the algorithm is unreliable. Not sure if I can check some box somewhere to force baro compensation, since from now on, I'll always import 910xt data with baro information.

Even when it does compensate for baro drift, there are three enhancements that would make this a phenomenal algorithm and much more accurate.

1. If there is Weather data, then it can use the actual pressure change over the duration of the workout, and use this to modulate the drift. For example, 3 hours into a 6 hour ride, a front might come in, with a significant and fast shift of pressure. Knowing that would make the drift compensation much more accurate than assuming a linear drift across all 6 hours.

2. It seems to have logic that says: if the end and start GPS location is very close, force the elevation to be the same. But this logic could be used across the entire data set. For out and back, or loops, or where you cross over the same path (at intersections, junctions), the elevation should be the same. After compensating for atmospheric pressure drift, the second pass could make sure that when you were ever at the same general spot, your elevation was the same. Possibly taking the average of the 2 (or more) readings at the same place.

3. Possibly give an option for the user to enter a KNOWN starting and/or ending elevation, rather than count on initial calibration of the pressure or GPS. For example, I may start a trail run without calibrating my baro sensor. But after the fact, I can determine the actual elevation of my start and end point (might end at a different location). It would be great to be able to tell the correction algorithm my actual start/stop elevations.

[old_man_biking]

I have the latest W&C plugin, and use a 910xt.

Most of the time, it does not detect that the data is barometric, and simply overwrites my baro data with digital map data. I'm not sure how it determines if it is baro or not. Sometimes it does detect baro and then offers to compensate drift. But the algorithm is unreliable. Not sure if I can check some box somewhere to force baro compensation, since from now on, I'll always import 910xt data with baro information.

Even when it does compensate for baro drift, there are three enhancements that would make this a phenomenal algorithm and much more accurate.

1. If there is Weather data, then it can use the actual pressure change over the duration of the workout, and use this to modulate the drift. For example, 3 hours into a 6 hour ride, a front might come in, with a significant and fast shift of pressure. Knowing that would make the drift compensation much more accurate than assuming a linear drift across all 6 hours.

2. It seems to have logic that says: if the end and start GPS location is very close, force the elevation to be the same. But this logic could be used across the entire data set. For out and back, or loops, or where you cross over the same path (at intersections, junctions), the elevation should be the same. After compensating for atmospheric pressure drift, the second pass could make sure that when you were ever at the same general spot, your elevation was the same. Possibly taking the average of the 2 (or more) readings at the same place.

3. Possibly give an option for the user to enter a KNOWN starting and/or ending elevation, rather than count on initial calibration of the pressure or GPS. For example, I may start a trail run without calibrating my baro sensor. But after the fact, I can determine the actual elevation of my start and end point (might end at a different location). It would be great to be able to tell the correction algorithm my actual start/stop elevations.

The plugin ONLY rates an elevation track as barometric, when it detects a SLOW DRIFT of the elevation, compared to DEM data.
So the proper title would not be "barometric" but "barometric with drift".
Re 1: I think I already answered this in a previous post. There are different types of GPS units with and without pressure sensors on board. Some of them already compensate elevation data by comparing GPS elevation and baro elevation. As the plugin cannot know which type of GPS has created the data, it shoud NOT interfere. Suggestions declined. And no, I won't add options to select the type of GPS unit; that would only be confusing for +50% of the users.
Re 2: I'll leave that as a practical part to my Ph. D. thesis.
Re 3: that's already implemented. If there is a waypoint with set elevation set close to the starting point (if I remember right, 50 meters), this elevation is used.

Cheers,
OMB

PS: I deleted your identical duplicate post in the GFD plugin board.

[dbrillha]

Thanks OMB!

I'll quit asking. I understand your reasons.

I do think #2 would be very cool. But non-trivial. Unless you already have a library that detects if you're on the same path you were on earlier, like "finding similar routes".

Just so you know, for some reason, the "detect baro data" doesn't work well for the 910xt. Possibly it is because I live in Florida and there isn't a whole lot of elevation change. I have an opportunity to run in real mountains in about a week. If it still doesn't detect true barometric data and offer to compensate (start/end normalization), I'll let you know.

Cheers!

-- Dave