Posts for this topic...
-
Post your comments.... Sign In to Post
-
plotaroute admin Tuesday 27 Sep 2022 14:02:00
Hi Paul,
We've had a look at a worked example based on your route: https://www.plotaroute.com/route/2034642 It does look like your settings are causing the small apparent back steps in time. Here's a worked example
Point 1
Distance to point: 86122.97557m
Uphill to point: 1235m
Downhill to point: 1079.08m
Steep downhill to point: 34m
Calculated time: 12814.716 seconds
Point 2
Distance to point: 86146.23569m
Uphill to point: 1235m
Downhill to point: 1081.18m
Steep downhill to point: 34m
Calculated time: 12813.999 (i.e. it appears to go backwards by 1 second once rounded)
Settings
There is no change in uphill or steep downhill amounts, so the only setting that applies is:
-13.42m per m of downhill
Calculation
Distance change between points: 86146.23569 - 86122.97557 = 23.2601m
Downhill adjustment : -13.42 * (1081.18-1079.08) = -28.182m
The negative adjustment applied for going downhill is larger than the distance moved along the route, hence why the time appears to go backwards. I think the best thing is to reduce your setting for downhill so that it is not causing this effect. We should possibly reduce the range that this slider can be set to, to avoid this issue happening, but I think it probably only has a very small impact of a second or two and will then self-correct as the route progresses.
-
Paul Toigo Saturday 15 Oct 2022 03:23:00
Sorry for letting so much time go by, but I've had several rabbit holes to visit. I acknowledge that my advanced setting of downhill can and does cause the model to go back in time. But . . .
1) The fist real problem is that PAR exclusively uses SRTM for elevation. While this once all anyone had, today it not considered not quality data (by people infinitely smarter than me).
2) The other real problem is PAR is using a timer model for trekking model, of dubious value, for cycling.Assuming PAR doesn't want to invest in better elevation data or (cycling specific) timer model at this time, I'd like propose the addition of a maximum speed control to the advanced settings to preclude the timer model from going back in time.
FWIW, I've studied the GPS lat/long/elev data from my 4 runs up and down the lower Poudre Canyon and benchmarked the endpoint elevations to the PAR output. There is very low variability between the runs. Any one of the runs (or the average) is far more realistic than the SRTM. Could/would PAR possibly look at the OSM nodes along a route for an entry in the elevation tag before applying the SRTM elevation data?
[IMAGE REMOVED DUE TO SIZE]
-
plotaroute admin Monday 17 Oct 2022 08:58:12
Thanks for the feedback Paul. I'm afraid we already have far more requests for new features that we can cope with, so it's unlikely we'll be able to look any new ideas for some time. However, we are planning to implement changes to our elevation data in the coming months, along with further investment in our server infrastructure, which we're confident will improve the overall accuracy of our elevation profiles. We're not planning to change our approach of using a Digital Elevation Model (DEM) as the source of our elevation data though, but our DEM will be based on multiple data sources, not just SRTM.
-
Paul Toigo Monday 17 Oct 2022 14:08:42
That's great news! I can hardly wait until the DEM incorporates these other sources.
