Elevation data recorded from your phone is often very inaccurate, so we decided to NOT use it and instead generate elevation for each lat/lng point in your ride. This is what many other ride tracking sites like Strava also often do.
Note that the elevation-adding feature will erase any existing altitude data (for example, from a GPS). Often, this is desirable; profiles made with DEM data are usually "smoother" looking than GPS, and typically contain fewer gaps or suspicious readings.
We currently use our own elevation API service, similar to Google's data and is sometimes (but not always!) more accurate than the SRTM databases. We however hope to someday improve our DEM (digital elevation model) using all the ridelog data we are collecting. But until then we've decided to re-generate all ridelog elevation data, even if it came from a Strava synced activity. This way all the ridelog data on Trailforks is at least somewhat comparable with each other and to the trails mapped on Trailforks.
Ride statistics like elevation gain or descent are not a given value like distance, but something that is calculated with a formula. Each GPS app will use different criteria and formula to calculate their numbers. This often involves some cleanup of the elevation data first, smoothing out the data, then usually there is a minimum distance between GPS points for a point to be counted towards the rides cumulative climb or descent. Some apps might also have a better more accurate source of elevation data for some areas of the world.
Because of this if you record a ride on 5 different apps or devices, you will likely get 5 very different totals for climbing elevation. Trailforks has tried to make our elevation processing somewhat match those of Strava rides recorded with their app. But the results will vary.
You can read more about GPS elevation here:
- http://www.gpsvisualizer.com/elevation
- https://support.strava.com/hc/en-us/articles/216919447-Elevation-for-Your-Activity
Note that the elevation-adding feature will erase any existing altitude data (for example, from a GPS). Often, this is desirable; profiles made with DEM data are usually "smoother" looking than GPS, and typically contain fewer gaps or suspicious readings.
We currently use our own elevation API service, similar to Google's data and is sometimes (but not always!) more accurate than the SRTM databases. We however hope to someday improve our DEM (digital elevation model) using all the ridelog data we are collecting. But until then we've decided to re-generate all ridelog elevation data, even if it came from a Strava synced activity. This way all the ridelog data on Trailforks is at least somewhat comparable with each other and to the trails mapped on Trailforks.
Ride statistics like elevation gain or descent are not a given value like distance, but something that is calculated with a formula. Each GPS app will use different criteria and formula to calculate their numbers. This often involves some cleanup of the elevation data first, smoothing out the data, then usually there is a minimum distance between GPS points for a point to be counted towards the rides cumulative climb or descent. Some apps might also have a better more accurate source of elevation data for some areas of the world.
Because of this if you record a ride on 5 different apps or devices, you will likely get 5 very different totals for climbing elevation. Trailforks has tried to make our elevation processing somewhat match those of Strava rides recorded with their app. But the results will vary.
You can read more about GPS elevation here:
- http://www.gpsvisualizer.com/elevation
- https://support.strava.com/hc/en-us/articles/216919447-Elevation-for-Your-Activity
- By canadaka
Trailforks - #90 - 4,839 views