Something (scale?) wrong with elevation graphs

[eliotb]

The elevation graph does not correspond to the track, both in by time and by distance views.
Both horizontal and vertical scale of graph vs grid seem very wrong - see screenshot.
The marker pin was placed when at the highest elevation. (Pin time seems right, elevation wrong)
The track was a loop that started and finished at the same point.
When viewed in osmand, the exported track is a complete loop, and the elevation is correct. The highest point is about 480m.

The speed graph seems correct (slower uphill until the marker pin, faster downhill after marker)

To Reproduce
View graphs for any track.

If applicable:

Technical information

• Device: samsung s9+
• OS: /e/ OS - Android 10 - 20220406
• OpenTracks version: v3.27.0

[dennisguse]

Thanks for the report.
Some things:

• in the UI OpenTracks presents elevation as EGM2008 (more or less sea level) while the GPS/export provides WGS84.
  Most other applications present just WGS84 - so an offset is expected.
• the marker is always shown on top and not at the computed elevation (if I remember correctly).

Anyhow, the elevation plot should look different if you did a loop.
We apply some filtering to the elevation (as it is noisy due to GPS) - this removes the spikes, but it should look different.

Did you notice this with previous versions as well?

[eliotb]

here is the track opened in osmand, with elevation profile as expected

It has been a problem for a little while, sorry i cant be specific about when i first noticed it

[dennisguse]

I have checked some of my recordings and some of them feel incorrect in the diagram.
They do not go back down to starting elevation although they should have.

This will need some investigation...
Problem might be in the TrackStatisticsUpdater.

[frasty]

Just checked and the elevation graph does not correspond to the real eleavation in most of my workouts. Tbh, I find this level of graph smoothing unnecessary. Maybe it would be helpful in this regard if the y-axis could be scaled down more proprortionally to distance/time.

Compared to GPX Viewer app:

[frasty]

As a second thought, I see that GPX Viewer shows the graphs in WGS84 proj, but the problem here is another I think, as the peak elevation differs way more than the difference between WGS84 and EGM2008.

[dennisguse]

That doesn't sound good. At least the difference should be almost identical.
Might be a problem in the rendering of the diagram / scale as well.
And the smoothing might be a problem.

Anyhow, more than one thing seems to be broken.

[InvncibiltyCloak]

Hopefully this is helpful. I have compared the GPX export from OpenTracks vs the plot shown in OpenTracks GUI and the two definitely do not match at all.

I ran the GPX through Python to get the plot shown, so there is no other software mucking with the elevation data in the GPX. The trail was a there and back, so the final elevation should approximately match start elevation (other than not starting the track immediately).

Because the Python plot appears to be correct, OpenTracks appears to be recording the correct data, it is just displaying it incorrectly. Hope this helps narrow things down.

I have seen the same result for multiple hikes, where the there-and-back hike ends at an elevation very different from the start elevation. They typically end somewhere close to the average elevation during the hike, (which to me suggests a problem in the filtering).

[dennisguse]

Found the problem: for the diagrams only, we have some code that smoothes the altitude.
And that doesn't work properly.

Removing the smoothing solves the issue.