I have written a web app which enables you to load a GPX file and view the accumulated elevation along the route. All works well except for the fact that the accumulated elevation I get is treble what Strava tells me it is.

I am calculating accumulated elevation by checking whether the elevation is > than the previous elevation (eg going up) and then adding the delta to the running total?

If this is correct I think the massive difference could just be because of the spikey elevation data in the GPX file?

GIGO

I think you’re relying too much on the (in)accuracy of recreational GPS devices.

(FWIW I also think you’re overthinking the whole elevation thing).

(FWIW I also think you’re overthinking the whole elevation thing).

Every foot of elevation gain counts! I’m having sleepless nights 😯

In all honesty, it would be useful, but without smoothing it doesn’t work very well.

Try resampling the GPX file (e.g. Using every 3rd reading) and compare that to the the strava DEM data.
Z values in consumer gps units tend to be poor and only marginally improved if there is a built in altimeter – OK for showing trends though.

Resampling is too crude. Run something like a Douglas-peucker algorithm on it.

I am calculating accumulated elevation by checking whether the elevation is > than the previous elevation (eg going up) and then adding the delta to the running total?

There’s a lot of noise in GPS elevation data, if yours hasn’t got a barometric altimeter. Ride along a flat trail with tree cover and see what the elevation data gives you. Or compare the profile of your route against one created in bikehike.co.uk.

If you do your calculation on every sample point, you’d be adding up all the positive noise signals.

Depending on your skillz/software available, get your z values from SRTM DEM data which is probably what strava uses, or something better like OS open data DEM. Should give you close to strava in terms of z so you can check your methodology. I doubt the z from the GPS is very useful.