Improved Elevation Profiles
- More sample points used
- Distance measurements provided for the x-axis
- Gross elevation gain and loss calculated
- Horizontal sampling interval and vertical exaggeration shown
- Climbs and descents marked with distance and elevation change
And here’s what it used to look like:
Using the data rendered for custom DEM shading, I was hoping to update the elevation profile with slope and aspect data as well. I’ve seen some cool circular plots of elevation v. aspect and slope angle v. aspect, and thought those would be a nice addition. However after playing with an elevation v. aspect graph, I’ve concluded that they’re only useful for a narrow subset of routes. On ridgelines, summits and valleys the aspect can bounce around dramatically over very short distances. This leads to a graph that exaggerates aspect swings at best, or turns into a useless and confusing mess at worst.
Instead, I’ve incorporated that data into a “point info” feature that will give you elevation, slope and aspect readings for any spot in the continental US. I don’t know how useful this will be, but it’s more of a temporary bridge until I find a better way to provide this data in graph form. Note that because the point info feature uses CalTopo’s elevation data and the profile graphs rely on Google’s elevation service, there may be small discrepancies between the two.
|Selecting the Point Info tool.|
Matt – I just discovered caltopo, and I love it – thanks very much for providing such a valuable service.
I've been creating some elevation profiles, and am realizing that a long route gives me less of a total vertical gain than the same route subdivided into sections – sometimes by thousands of feet (for a 100 mile route, for example). I assume that it's an effect of the sampling resolution. Is there a way to control the sampling resolution used to calculate elevation profiles?
Hi Alex –
I'm currently using the Google Maps elevation API for showing profiles. Although there isn't a hard limit, when you get above 250 points or so you start running the risk of exceeding the maximum allowed GET request size, so I only do about that many samples. The sampling interval is shown on the profile dialog, which should give you a rough idea how accurate it is.
A smaller sampling interval wouldn't really help the elevation graph any (unless you have a ridiculously wide monitor) but as you noted it would make the gross gain/loss calculations more accurate. I could break the route up into chunks and send separate requests for each one, but that adds a lot of complexity and I'm not sure it would help for a 100mi route – you really want 10x or 20x as many samples, not 2x-3x.
I have elevation data for the lower 48, and I've thought about spinning up my own elevation service with it – the code is already written so that I can generate elevation profiles in an offline environment for SAR. The issue is that I don't want to fully replace Google's API, so that people in Canada or elsewhere can still do profiles, and I'm not sure how to have both options live conveniently in the same UI. Open to suggestions there.
Hey thanks for the response. What you're saying makes sense. It's working fine for me to split routes, and sum the gain for each leg. I'm still loving caltopo – thanks again.