Elevation Gain Information

There are some older threads with similar but not same content. So I need to ask here.

When I create a route in BC I get an information aout the length and the altitude gain at the bottom of the map. HOwever when I open the graphic elevation profile and measure the between he start and the end point I get a different number of the total elevation. If I convert the route to a track, which I normally do, then the elevation info is the same as at the bottom of the map. Most times however I found the the elevation profile information of the route is more accurate and matches the climb altitude of the ride itself. I use the "Velomap" together with the adequate contour lines. But this can't explain the difference in BC. Example see below.

0 BTLAAKE over 2 years ago

Gernerally speaking, differences in data fields like total distance, ascent and descent are do to differences in the number of data points used to determine these values..

For example, the trip computer page of a device will use the position update frequency to determine things like distance, speed etc and this will be added to the log file. However, the actual number of points log will usually be far less. This will result in a difference in total distance if only the logged points are used.

With regards to BaseCamp and your observation, I can only make a guess. I don't think BaseCamp stores elevation data with Routes. If the map has a dem, then it may store a summary. This could be based on all of the route points or it could be base on points from a route to track conversion. (Note: the via points and point numbers in the summary data do not represent all of the points stored for a non-direct route)

I think the graphed data is done on the fly. But again, it may use all of the points in the Route or use points from a route to track conversioin. Once you convert the route to a track, then the summary data and the graph data must agree because they will be determined using the same set of data of data points (i.e the same number of points).

If something like this is happening, you might notice a visual difference in the plots between a route and a converted track in a mountainous area were there are lots of changes in elevatioin.

0 YK56NJ4 over 2 years ago in reply to BTLAAKE

Thank you BTLAAKE for your answer. It took me a while to think that through. Basically I think this is the right track.

While the elevation numbers in the route list and track list match completely the measurement between identical points give me the same values, regardless how many system created points are in between.

I also noticed that the numbers given are all integers. When I create a position point on the map I alway get a real number. This means that there can be differences between the value in the list and on the map can be up to clos to 0,5 m.

The track of the above shown route gives me 2798 individual points.

I have then created a route from this track commanding 1000 via points. The total elevation gain rose from the initial 1319 m to 1503m. Then I created again a track from this route which gave me 3293 points. An additional route created from that track should have used 2000 via points. The resulting elevation gain is 1607m.

So I assume that you are right that the number of points is importatnt for the listed elevation gain.

Interesting enough is that the elevation values taken from the various route plots do slightly decrease with the number of route points.

The only explanation for this is seems to be that the values for the route plot are taken directly from the map and give interpolations between the elevation lines in the map. Therefore these are the more trustworthy values.

0 9940508 over 2 years ago in reply to YK56NJ4

The above correspondent is probably right. However, I have always had a simpler understanding (and am open to correction). I have always assumed the Route gets its data from the contours of a map. This provides a very good estimation of walk length and elevation, but for all sorts of reasons is inaccurate. When you walk it, you create a Track, which gets its data from the satellites. There will be a difference with map data. In my opinion, neither is totally accurate, both need interpretation because the data will be inflated (e.g., if you go over a stile; - is that accumulative ascent and descent?).

David

0 YK56NJ4 over 2 years ago in reply to 9940508

I'm afraid, your assumption about the accuracy of satellite data is not qute correct. In all applications where altitude information is importatnt like mountain hiking, bycicle riding or aviation the air pressure is a more reliable value than satellite data. And if you look at a track (trace) from a ride, you will always notice some distance of the course to the road on the map. This depends on the accuracy of the GPS measurement.

Elevation lines in a map, at least in "Velomap" (https://www.velomap.org/download/odbl/) come from Lidar measurements of different, specialised satellites and provide the most accurate elevation model available for the odd user. like myself. So taking these values from the map with all their interpolation seems to me the most accurate information.

I'm with you if you say that neither is totally correct. But I am not that much interested in absolute correctness. I was only curious how several hundred elevation meters difference in various measurements occure and which one is more reliable.

0 BTLAAKE over 2 years ago in reply to YK56NJ4

I wouldn't worry about seeing integers in one place or floating point numbers in another. Chances are all calculations are done with floating point numbers and then a decision is made as to what to display. What's display is no indication of what is stored, what is calculated when needed or what is exported.

Total distance, speed ascent and descent for Garmin tracks are always based on the stored points. A point consists of latitude, longitude, UTC time and elevation (for device collected track). Total distance is the sum of point to point distance calculated from the lat/lon data. Ascent/descent is calculated by point to point change based on the elevation data.

A caveat is that a device that can display real time information will probably download a summary table along with the actual track data. The summay tends to be based on a running totals of the real time information. This is done at a one second interval, but, if the device things you are stationary, it does not update the running total.

You can take one of your saved tracks and duplicate it. Cut the duplicate in two and then rejoined the two halfs. The summary in the new track will be determined from the saved track data. Compare the two summaries to see if they are the same.

The contour lines you see are your map are just lines. The elevation data is probably contained in a digital elevation model (DEM). You can think of this as a grid with a lat/lon/elevation at each corner of a grid square. A point that falls within a grid square will have its elevation determined by interpolation of the stored data.

With regards to track/route data created in BaseCamp, I would suggest this experiment. Find a spot where there are signifcant changes in elevation. If you have a mountain chain, that would be great. Creat a waypoint on one side and another on the other. Change to the global map set the route method to Direct. Don't use the waypoints, but create a two point route by clicking in the vicinity of the waypoints. Create a two point track the same way. They don't need to match.

Now switch to the map with the elevation data and check graphs for the track and route. If you don't see anything for the track, go to Edit>Advanced>Set Selected Track to Map Elevation. With the route profile Direct, convert the track to a route and see what happens.

With a real track, I would suggest making two duplicates. Do a cut and join on one duplicate, convert that duplicate to a route. For the second duplicate, use the edit>advanced ... to assign map elevations to the collected track points. Decide which you think is best and go with it.