Posts for this topic...
-
Post your comments.... Sign In to Post
-
Paul Toigo Monday 17 Oct 2022 14:08:42
That's great news! I can hardly wait until the DEM incorporates these other sources.
-
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 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 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.
-
plotaroute admin Tuesday 27 Sep 2022 09:14:03
Sure Paul, we'll certainly add it to the list to look into. It's quite an obscure one though, so I have a feeling it will be hard to track down and fix.
-
Paul Toigo Monday 26 Sep 2022 11:38:14
OK, set aside the virtual elevation method. There's still the matter of something wrong causing the model to back in time and I suspect the code, not my configuration.
-
plotaroute admin Monday 26 Sep 2022 09:12:48
Thanks for that analysis and your offer of help Paul. We've got a vast number of things already on our feature requests list and while we'd love to promise to do them all, realistcally this isn't something we'd be able to find time to look for the foreseeable future I'm afraid.
-
Paul Toigo Friday 23 Sep 2022 15:45:37
I retract my notion that "the model can create a negative time interval on some downhill sections." If my math is right, with a flat speed of 22 km/hr, a downhill grade would have to exceed 21.6% to model a negative time with my steep downhill setting of "Every 1m down equivalent to -4.75m". I altered the setting to the fastest allowed of -10.00m which requires a downhill grade to exceed 45.45% to model a negative time interval. This had no impact on the number, 22, of negative time intervals.
All this said, perhaps it is time to create a more realistic model for cycling. A "simplified" Chung (Virtual Elevation) Method would be darling. I'm willing to consult on the algorithm.
-
plotaroute admin Thursday 22 Sep 2022 09:13:00
I think you're right Paul - the time adjustments for downhill sections are probably creating this anomaly. I think this would be very tricky to resolve. Reducing your Downhill adjustment from -13.42 would probably help.
-
Paul Toigo Wednesday 21 Sep 2022 17:22:00
@plotaroute admin It happens at the following points in the route. I'm thinking the model can create a negative time interval on some downhill sections. I'll think about it more later.
[IMAGE REMOVED DUE TO SIZE]
