Calculating a Strava Route's estimated moving time

Your estimated moving time for a Route is calculated by your 4 week average pace. On your profile you'll see your average distance per week, and your average time running per week based on your last 4 weeks of activities. We take that average and apply it to your estimated moving time. 

If you share the route, the person will see their own personal estimated moving time based on their stats, not yours. 

Was this article helpful?
13 out of 14 found this helpful
Have more questions? Submit a request

Comments

22 comments
  • When creating a riding route, does the Est Moving Time inc turbo / stationary trainers? My calculated avg speed is really low. As I don't use speed/distance on my turbo but I log the tine I think this skews the avg speed total

  • Hi Christian, This very well could be a problem with Est. time for Routes. 

    Could you please start a support request directly with our support team to log this issue? Click "Submit Request" at the top of this page or click here: https://strava.zendesk.com/requests/new.

    Thanks! 

  • Your current model is the following:

    time = A × distance

    I recommend the following model:

    time = A × distance + B × climbing - C × descending

    This is 3 parameters instead of 1, but they don't need to be derived without constraint.  For example:

    1. Derive A0 = riding time / riding distance for sample period

    2. extract portion of rides which are "climbs"

    3. calculate riding time / riding distance for this portion

    4. extract portion which are "descents"

    5. calculating riding time / riding distance for this portion.

    Then it's a simple algebraic equation to calculate A, B, and C in the model.

    Computationally, the added cost is the "portion of the routes which are climbing".    This doesn't need to be perfect, of course. and it's fun to think about possible algorithms, including using segment data instead of working with the raw data.

  • I think you could take the idea I model for seeding: https://strava.zendesk.com/entries/26365425-Seedings-calculated-by-Strava-

    And just modify it to give you really really accurate time estimates. 

  • Thanks, Andrew.  I commented there.

    I'm not sure about your specific seeding algorithm, although I know what VeloViewer does.  The key here is simplicity.  So how many parameters do you need to characterize how a rider rides?  I proposed 3 here: flat riding, climbing, and descending.  There's enough uncertainty in comparing one route versus another that too much precision doesn't make much sense (urban, rural; dirt, paved; headwind, tailwind; commuting, racing; group, solo...).  But clearly ignoring climbing and descending results in gross errors. 

    It even need not be the case A, B, and C are independently derived for each rider.  A global extraction to determine B/A and C/A could also be done.

  • As an aside, here's an algorithm I developed for estimating riding time from a route profile (it's not constant power, which is obviously unrealistic for typical riding):  http://djconnel.blogspot.com/2013/01/customization-of-cycling-heuristic.html

  • I agree at least having flat, uphill, downhill, would increase the accuracy dramatically.

    My thinking was that Strava has so much great data to work with, they could build a really cool model of each rider, and just blow the competition away. 

  • I completely agree!  But I don't think that's their business model, unfortunately.  A lot of the innovation on data processing (heat maps, rider score, etc) has been driven by independent API developers.

  • I agree, I'm surprised that they haven't exploited ways to analyze the data more in their business model. Consider how much a Tour de France team would pay for real deep insight into their teams (I'm sure the TdF teams have data analytics people already, but Strava could take it to the next level and be a lot more scalable), or better yet a team could use it for scouting new and up coming talent. (because I'm sure there are great riders out there that are not on the racing circuit due to money or geographic reasons, they just need to be found).  

  • Hi, this function was super handy for estimating return times (to meet family kerfew), however it's been thrown out by me doing some gravel grind type rides and MTBing. Ideally the time estimate would consider the type of route or bike being used?. i.e. is it offroad/MTB, Gravel/CX route or sealed roads on the road bike. 

  • It would be nice to know if it 4 week avg includes turbo trainer sesssion. My Turbo pace is always higher than my road pace so this would give skewed results

  • No, this ist not the way I would like to plan time by Routplanner. Mutch better is, if I can expect the Time I use by myself. Time by 4 week average peace ist mutch too short, if i plan a only uphill Route. Then this estimated time must be manually corrected or it will be very bad to estimate, on the way, my target arriving time.

  • I would say the most accurate would be to split the route into segments and estimate moving time per segment:
    - If the rider already completed the segment, use it's passed time (or average if he did it many times)
    - Else, get all others riders who did the segment and check for common segments with the current user passed activity. If current user time on segment A was 130% the time of rider "Tom", then most likely current user's time on segment B will also be 130% of the time it took "Tom" to do it
    - Finally, if no common rides are found, then use current user average time.

  • Another issue using average time over last 4 weeks is that many of us split our time between Mountain Bikes and Road. On a mountain bike (where I spend 90% of my time) my avg speed is low, therefore the time estimate for a road ride is basically unuasable

  • Pablo: You point out a weakness in my previous suggestion, which was, in the spirit of KISS, time = A × distance + B × climbing - C × descending. In picking segments to characterize the route time one could use, for example, a goodness function which rewards a combination of larger fractional route coverage and a smaller number of segments. But rather than try to match the particular rider's times to particular segments, an extension of your idea (indirect comparisons) would be to give each rider a speed score of how he tends to do relative to the mean. For example, if I characterize each segment by climbing, descending, and distance, and assign the rider a normalized time score for each segment (1.000 for "average", >1.000 for slower than average), then I can do a 3-parameter linear fit for how his normalized speed tends to vary with segment type (can alternately fit to logarithm of time to avoid negative times). Then for any given segment I can predict his relative speed, whether or not he's ridden in before.

    Is all of this worth it? I don't know. In some cases I care about my personal speed, in other cases I care about the speed of a group. And contexts vary so much: if I'm tooling around on my commuter bike in running shoes my time is going to be very different than if I'm doing a competitive group ride in race kit.

  • BTW, an example of this might be the following, all the segments the rider has ridden (3), with time in seconds:
    segment climbing descending rider_median general_median
    A 5% 0% 900 1000
    B 5% 5% 2000 2000
    C 0% 5% 1100 1000
    where "5% climbing" is for example 50 meters of climbing per km of distance and I'm using median instead of average to exclude outliers.

    So here the rider's time is changed 10% per 5% climbing - descending. So the rider's coefficients would be:
    flat: 1.000
    climbing: -2%/1%
    descending: +2%/1%

    With this sort of model I could predict how the rider would do relative to the average on any segment based on that segment's total climbing and descending. So partitioning a route into segment components would result in a decent prediction for how long it would take the rider. Then portions of the route not part of these segments could be extrapolated.

    This is grossly simplified, of course, especially if a logarithmic transformation were used instead.

  • Was Joshua's question answered about bike type? That is my biggest question. MTB rides obviously take longer than road rides.

  • No. There has not been any response to this idea.

  • And now that you can mark a ride as 'Indoor', those rides should not be part of the calculation. Strava is giving me an average speed of 7 km/h right now. That's a bit condescending now, init?

  • I need to exclude rides with the kids. I just noted my average speed is down to 4mph, owing to my 5 years new bike and getting out a lot.

  • Wouldn't it be an option to enter a desired avg. speed to calculate the estimated move time on a route? I would love this when cycling in a group where you want an estimated based on a planned average speed.

  • For me, this is great, I'd do enough distance in a 4 wk period that taking kids out or variations in ride types do not affect overall speed. Given these pain points, might be better to take a previous X km avg as well as last X weeks avg then get an avg between the two.

Please sign in to leave a comment.