Would it be possible to automatically estimate and display projected distance for time-based workouts (similar to how estimated duration is calculated for distance-based workouts using target pace/zones)?
Having an estimated distance for time-based runs would help with two things:
Route Planning: Makes it easy to choose an appropriate route before heading out
Weekly Volume Tracking: Displays projected weekly mileage alongside time and load, making it easier to manage progressive volume build-ups and avoid sudden spikes in run volume
While time and load are great metrics, weekly distance remains a primary benchmark for running progression and injury prevention.
Thanks for checking. It works when the workout explicitly specifies an interval with Pace, but not automatically. For example, ‘- 30m Z2’ doesn’t estimate distance. It only does when you add ‘Pace’ to the end of the line.
It just seems a little inconsistent. Load and duration are always calculated, regardless of the way you specify your workout, but distance isn’t.
I had a similar question and from what I recall the gist is that everything in ICU is time based because cyclists do not seem to get much use out of distance (which makes kind of sense as in that sport, coasting, wind, elevation habe much higher impact than in running, relatively speaking). The dev team are cyclists and presumably the majority of users as well (I don’t know). Hence why it is as it is and why the priority is possible not very high.
All of that said, for runners a conversion between all metrics based on simple regressions over historic workouts is mathematically possible and pretty accurate in my experience, and the argument that ICU cannot know the elevation is moot - nobody expects that, and a runner usually knows whether the much shorter routes they are running matches their usual profile or not.
Best of luck, I’ve upvoted.
BTW, I’ve gone the opposite route, I’m planning all my runs with distance instead of time. Distance is generally my primary planning metric and I find that much better suited for my needs. Irrespective of ICU.
Of course I can estimate my pace, my zones are all aligned. The HR zone lags compared to the power and pace, and the pace zones aren’t accurate over elevation, so I get that power is the default for some things, but generally speaking it should all work out the same.
And as I mentioned above, it does work that way when it’s the other way around (when I specify a distance and a power zone, it uses my pace zones for a predicted duration).
Perhaps this makes more sense for me than some others because I’m in a very flat area (Netherlands) where pace and power go very much hand in hand?
Can you point to a known robust algorithm which can be used without violating any trademarks or licences?
I don’t think that the devs have time to build one from scratch…
I’m not sure I understand, wouldn’t this simply be the exact inverse of the existing math?
Currently, for distance-based steps, the system uses the pace associated to the specified power to estimate duration (Duration = Distance / Speed). For time-based steps, wouldn’t it just multiply time by target pace (Distance = Duration * Speed)?
Are there complexities under the hood that make calculating it this way harder than I’m realizing?
