Virtual Partner goes back in timeFORUMS HOME SEARCH FORUMS

I have many instances where my Virtual Partner in my TCX is going back in time. I'd like to insert images (and attach files) to demonstrat this problem, but can't. Here's a simple route that exhibits the issue.
https://www.plotaroute.com/map/2034642
Virtual Partner settings --
Flat Speed 22.00 km/hr
Uphill: 1m up = 14.15m flat
Downhill: 1m down = -13.42m flat
Steep downhill: 1m down = -4.75m flat

Thanks for reporting this Paul. At what point in the route do you see this happening?

To insert an image, just copy/paste, like this screenshot .... 

Starte a new thread ... How do I Insert an Image or even a File

@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]

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.

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.

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. 

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.

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.

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.

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]

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.

That's great news! I can hardly wait until the DEM incorporates these other sources.