Feedback on Run Tags and Moving Time/Pace Calculation

Strava,

What is the difference in tagging a Run Activity as one of these Run Types?

1) Run

2) Race

3) Long Run

4) Workout

5) Treadmill

The one difference I see is that by tagging a Run as a Race, Strava modifies the Pace to be the actual Pace instead of the Moving Pace. On all other tagged Run Types, the Moving Pace is used for mile splits (but labeled as Pace). Also, the Elapsed Time is shown at the top of the overview in large vs small font and presumably calculates the pace from the Elapsed Time.

 

1) I don't see any KB Articles on Run Types, so please elaborate on them

2) Strava should not be using Moving Pace on Run mile splits - its misleading and not accurate. If Strava wishes to display the Moving Pace vs the actual Pace, then Strava should label it as such.

3) I should not have to switch my run to a Race just to see the actual Pace mile splits.

4) IMO Strava should not even use Moving Pace, its not useful. But if they wish to use it, it should be labeled so people are not confused if it is a Moving Pace or the regular Pace. By tagging a run as Race vs Run we are somehow suppose to know that the Pace has been changed from Moving Pace to Pace? Just label the Pace always and show both. For mile splits, GAP and Moving Pace (labeled as just Pace, misleadingly) are of no interest and the true Pace is not shown (unless the run is tagged as a Race)!

 

Strava - please straighten out your usage of Moving Pace. We need to see our real pace for mile splits - not a massaged # that looks great even if we stopped at every drinking fountain.

Also, on the Run overview page, the Moving Time shown is not the actual Moving Time, its the Time. Garmin defines the following times; Time, Moving Time and Elapsed Time. Strava is overloading the usage of Time and Moving Time. The label on the web page is Moving Time, but the value is Time. Change the label to Time. And in the mile splits, you do the opposite, label the pace as Pace when its really the Moving Pace. Both of these are misleading, and in the case of mile splits do not even have the actual Pace per mile. iPhone App displays Pace as Moving Pace with no option to see the actual Pace and does not label the Pace as Moving Pace either. This needs to be fixed too.

Quite simply - label the correct values - and show the real mile split Paces. Label Moving Time as Moving Time. Label Moving Pace as Moving Pace. Label Time as Time. Label Pace as Pace. And show the actual mile split Paces (not moving pace) despite how the Run is tagged.

 

connect.garmin.com labels these values correctly and includes both regular and moving times/paces.

 

 

 

96

評論

217 條評論
  • Even when using the Strava app on my phone, the moving time is always lower than my elapsed time. Even when I push the start button after I've started moving, and stop it within 10 seconds of stopping, it will be 30-60 seconds difference between moving time and actual time.

    Please, let this be optional through user settings. Everything else about Strava is great, but this is a deal breaker for me. 

    0
    評論操作 永久連結
  • I used to be a premium Runkeeper and Strava member. Tried to use Strava more since Suunto started supporting posting to Strava which made it easier to get runs on here. But since it's pretty much useless on Strava now I'm going through the pain again of exporting and reimporting on Runkeeper. At least the data I see there is a reflection of training and time. 

    Appreciate the comments from Strava on this thread but would love to hear that there's either something in the pipeline to address this or it's time to give up on it. I'm sure this thread is just the tip of the iceberg, the few people that actually took the time to voice concerns over the issue. 

    0
    評論操作 永久連結
  • Armand D. : Use https://tapiriik.com/ to sync data between runkeeper and Strava effortlessly.

    0
    評論操作 永久連結
  • I use copymysports.com -- it syncs Garmin Connect and runkeeper as a free service.

    P.S. in Garmin Connect you can also set 3 separate heart rate training zones. One default, one for running and one for cycling! Strava only has one for all activities. Any athlete knows MHR is activity specific, so the premium heart rate analysis feature and Suffer Score for running is also useless if you set set your zones for the bike. :(

    0
    評論操作 永久連結
  • Those look very useful! Does the data come out clean even if it hit Strava? 

    0
    評論操作 永久連結
  • OK. I think Strava has a very serious problem here and I've completely lost trust in the numbers it reports! Today I had a trail run in one of gnarliest conditions I've ever head - dozens of creek crossings, slick rocks and roots, a lot of fallen trees, steep snow fields, a lot of elevation change. Strava tells me that the average pace for the run was 12:48/mile and that it was my best estimated 5K effort!

    This is simply ridiculous! In reality the average pace was closer to 27-28 minutes per mile. And it is one problem when it lies about the pace. It is completely another thing when Strava pulls a best estimated 5K effort out of thin air! That will now be displayed on my profile. Are best estimated efforts based on moving time too? Does that make any sense?

    Here is the run link: http://www.strava.com/activities/159796107

    0
    評論操作 永久連結
  • Best efforts are no doubt also tied to Moving Pace. All my estimated best efforts are far better on Strava than on Runkeeper or Endomondo, and I run on roads without stops at all. Best 5K effort on Strava is more than 1 minute better than on Endomondo for the same run where I had both Strava and Endomondo running simultaneously on my phone.

    0
    評論操作 永久連結
  • An interesting experiment would be to take the results from e.g. Ryan Sandes's Transgrancanaria win or even Kilian Jornet's recent win at the Skyrunning World Champs in Mont Blanc and see what times Strava concocts on import. Both are superhuman athletes and although the TG had some checkpoints the MB run was 'non-stop'.  

    http://www.movescount.com/moves/move11293648

    http://www.movescount.com/moves/move34742532

    0
    評論操作 永久連結
  • It seems that the consensus is that Strava is not calculating pauses correctly. I've been trying to figure out what the problem is.

    I recieved a confirmation from Strava support team that Strava does not use the meta data supplied by Garmin devices. Whether it's gpx or tcx data, they ignore the meta data and just use the gps track points. This was actually for a different problem i was having with max speed that was different in Strava than Garmin. But what does this mean? And why am I mentioning this?

    GPS track points are recorded on the device in intervals and basically track your gps position at that given time. Depending on the device it could write a trackpoint every 1 second or every 4 seconds etc. Some devices allow you to set the intervals manually. This position-in-time data is used to calculate speed, logically.  

    This is where problems start to arise: If your devices' GPS receiver is not so good, or the sensitivity is low or you have bad reception, it could happen that over a few seconds of recording, your GPS position could appear to have not changed. A few seconds later, suddenly jump to another position. This sporadic GPS data needs to be analysed and smoothed out. And I think this is where Strava is failing, and apparently others are getting it right. -- How?, I don't know

    After looking at or viewing the tcx files imported to Strava, I can actually see the track points where over several seconds the GPS position or distance in meters remains exactly the same. Strava quite simply sees this as a pause in my activity and removes those seconds from my "moving time". In my opinion this is very naive because it doesn't take GPS drops into consideration. 

    However, since we can't change Strava. I've been doing some experimenting and trying to see if I can find a setup that gives me better, smoother GPS recording. Here are my suggestions based on my findings

    1. Use a dedicated GPS device like a watch, instead of the smartphone tracker, if possible.
    2. Fiddle with the GPS settings in the device to set the recording interval to as low as possible (i.e. 1sec) I can't say that this makes a difference but imagine that more track points increase accuracy  
    3. If you don't have a dedicated GPS watch or device and use a smartphone to record, use Stravas own app. It gave me better results in Strava than GarminFit, for example. (However, GarminFit recording showed accurate results in Garmin Connect but not in Strava after import)
    4. On your smartphone turn on "High accuracy" for GPS. It might use more battery, but I found it helps.
    5. It may be possible that the GPS on your smartphone needs to be recalibrated and or reset. There are instructions on the web for this.

    Perhaps this helps others. 

    0
    評論操作 永久連結
  • Tom B - I think you are spot on, I'd concluded the same thing myself (albeit in a less technical way).

    I use a Garmin Forerunner 110 - pretty much bottom of the range - And when I look at my graphs on Strava they are very up and down and in no way smooth (like you would actually run). I therefore suffer badly from a big difference between moving time and elapsed time on Strava (whereas things are always pretty much spot on on Garmin Connect, which I guess knows how to work with its own devices better)

    Most of the people I follow on Strava use much higher spec watches 310's or 620s and they don't seem to suffer this same difference.

    Unfortunately on my spec watch there are no settings that I can change, so I think I am stuck with this problem unless Strava choose to do something about it.

    0
    評論操作 永久連結
  • I have disabled "auto-pause" on my Garmin for that exact reason. When I do want my time to be paused for gear changes or food breaks etc then I will intentionally pause my Garmin. This allows me to accurately reflect my running time on trail and extend this to determine splits across longer distances. This is particularly relevant as over the next couple of weeks I will be establishing times across segments for a 50 miler in August. Because of the way strava have determined pause time my split times across kilometers is badly skewed and this means that my summary data is less relevant. As a software engineer I am very familiar with the file formats and data offered by different devices and have written a FIT file parser of my own so I understand that its a Strava engineering and product decision to display times like this and am disputing this approach as the sources files uploaded contain all the relevant data to display splits as they should be. I've subsequently cancelled my premium membership as a result.

    0
    評論操作 永久連結
  • Tom B - That's an interesting response from Strava. Does this mean that any pace data from a footpod would be completely ignored by Strava?

    0
    評論操作 永久連結
  • I was really disappointed in Strava yesterday, we ran quite a gruelling trail in Mauritius which involved crossing four steep mountains and with all the climbing and walking involved as I was really hoping to beat Ricky Lightfoot (2013 IAU World Trail Champion)'s time in the end. Unfortunately Strava only took away one hour thirty which wasn't enough to even get a top ten finish. Do I have to buy premium again to get a top 10 finish time? 

    PS. I really walked and climbed a lot so was really expecting a faster time.

    0
    評論操作 永久連結
  • Adam, I don't think so. The data from sensors is written in the individual gps track points. My information is the only data ignored is the meta data written at the top of the file.

    From looking at my tcx files this would be
    Total time
    Distance
    Max speed
    Calories
    Intensity 

    0
    評論操作 永久連結
  • So I just looked at a run I did with my new Garmin Forerunner 220 and the cadence or steps per minute from my foot pod are recorded. However only for the foot that the sensor is on. -_-
    GC shows the correct doubled amount. So i guess we just have to double the amount to get the right cadence. 

    0
    評論操作 永久連結
  • Ok thanks for the reply. Sorry to get off topic, but I just wanted to know if it'll help smooth out big spikes in pace seen when GPS reception is lost as is often the case on some of my regular routes. Sounds like it's worth a try at least.

    I've heard of the the 'one-foot-cadence' issue on Strava before and unsurprisingly there's another support thread for that, which has also resulted in absolutely no action!

    https://strava.zendesk.com/entries/25594625-Display-Garmin-Footpod-data-correctly-for-Runs-on-Strava

    0
    評論操作 永久連結
  • I DO think that the foot pod makes a difference. But I'm only basing this on one run so far.

    Strava only had a 10 second pause in my last run with the foot pod activated. This is pretty much in line with the results on GC.! But I don't know if this improvement is related to the new Garmin Forerunner 220, or just the foot pod -- perhaps both. Fact is, the older runs had pauses of a minute or more over a 30 minute run. So I can live with 10 seconds. 

    I will definitely keep looking at the results. Maybe I'll test with the foot pod on one of my other GPS devices that were getting bad results (Edge 510 and smartphone) and see if there's an improvement there.

    0
    評論操作 永久連結
  • A really great discussion on here - thanks to all of you for your insights and feedback about both our moving time calculation and it's accuracy issues, and the request to calculate pace from total time instead of moving time for all run types. 

    I particularly liked @Tom B.'s comments regarding GPS coordinates that struggle with accuracy issues and cause false resting time to be detected. GPS accuracy is a much larger issue for run data that it is for cycling data because of the lower speeds, and it is an obstacle that Strava has not yet been able to tackle. I agree that tackling GPS accuracy is imperative for quality run data! A quick note to add - even with "strong" GPS devices, running on trails with heavy tree cover or in cities with tall buildings causes accuracy issues with the GPS signal. 

    @Reid Bremner's comment is also helpful and true: If you have a Garmin run device, turn off auto-pause, and use the manual "Stop/Resume" button at least once during your run, the Strava will NOT overwrite your time data with it's algorithm for detecting resting time. Instead, Strava will display the time data according to the "timer time" of using the Stop/Resume action. In theory, you could use this button for a brief instant at the beginning or end of your run and then you would see pace times that reflect your total time. 

    @Adam - I'm aware of that forum regarding run cadence. No action yet - but I'm a supporter of getting that fixed! Should be plenty easy. 

    As always, I'm sharing this feedback with our Product team. Thanks for your continued feedback! 

    0
    評論操作 永久連結
  • I must say that after I got a TomTom MultiSport GPS watch, the issue haven't really been noticeable at all. This watch has a 1-second GPS tracking interval by default and it seems to track my runs quite well, even in places where my phone with Strava app fell out briefly and properly messed up the moving time calculations. 

    0
    評論操作 永久連結
  • Elle, thank you for responding as it is nice to know that this thread is not being completely ignored...
    But I’m confused...

    I think I’m right in surmising that in Strava “actual pace” works fine for running, but “moving pace” has problems...

    You said above:
    “GPS accuracy is a much larger issue for run data that it is for cycling data because of the lower speeds, and it is an obstacle that Strava has not yet been able to tackle”
    &
    “I agree that tackling GPS accuracy is imperative for quality run data!”

    So if you think that quality run data is important, but you are aware that Strava can’t calculate “moving pace” accurately... Then why do you insist on defaulting to “moving pace” (which you can’t calculate correctly) rather than “actual pace” (which you can calculate accurately)?

    If your development guys do actually manage to crack “moving pace” for running at a point in the future, then yes there would be an argument for using it... But surely until such a point as they can get it right they should default to a data field that is accurate i.e. “actual pace”?

    0
    評論操作 永久連結
  • @Steve, we've worked hard on our formula for moving time (and thus moving pace) for runs on Strava.  It is our best attempt at this time and for a large percentage of activities it works as intended/designed. I would phrase your question a bit differently - we don't insist on defaulting to "moving pace", it is just how our run analysis was designed by the Strava team. Nothing is set in stone, and input like yours is part of a feedback trend that is being fed back into the development cycle. We are listening, and hope we can consider the suggestions discussed here going forward. 

    0
    評論操作 永久連結
  • @Elle, why would you deliberately design something that depends on totally accurate GPS positioning, when that is something that never will be achieved? What are the design goals behind moving time?

    I made a run with my Samsung S4, which for some reason started to double-log coordinates or something. The GPS track looked good but my pace became 2:15 min/km, which is somewhat above my running abilities. I had to mark it as race in order to make it appear reasonable, which isn't very good either. This is a somewhat normal GPS error, and your algorithm totally failed. Or would you say it was correct?

    Even top-notch Garmin 620 struggles whithout a clear sky view.

    Why not just use elapsed time, since that would be most natural anyway? And respect any manual start/stop actions of course.

    0
    評論操作 永久連結
  • Thanks for adding your support Calle! 

    0
    評論操作 永久連結
  • The fact that Strava pays attention ONLY to GPS track points, and not anything else, tripped me up in a race situation recently. I ran a 5:09 1600m race on a track, but Strava reported it as a 5:07, even after I marked the activity as a race. When Strava support responded to my query, they noted that the GPS track points for start and finish were separated by exactly 5:07, not 5:09. What that means is that the Garmin 620 failed to pick up satellite, or at least chose not to write a GPS track point, for 2 seconds at the start of the race. It had been on and locked on satellite during my warmup, so it wasn't a power-on lag. Presumably just GPS flakiness.

    What I'd suggest is that the easiest solution to all this is simply to let the user overwrite the time and distance fields. That way, if there's any error (GPS or human), it's easily rectified, and the user can be sure that the data matches what is known from external sources (such as an official race time or distance). Failing that, the only real solution is to delete the activity entirely and create a new one that has the correct time and distance (but no other information whatsoever). That's a lot of extra work for the user, and a bad user experience, so allowing data edits would seem to be a much better approach.

    0
    評論操作 永久連結
  • Hey Guys,

    I am a brand new user (just signed up and imported all my data from a competitors product today) and was totally flummoxed by moving time (which led me to this thread)

    Elle - is it possible to re-frame this to your product team/developers perhaps?

    Rather than talking about bugs or worrying about how the moving time is calculated - can you suggest a functionality change that:

    1. Removes the existing link between run type (Run, Long Run, Workout, Race etc) and the time field used in calcs (Total Elapsed TimeTimer Time or Moving Time) which seems somewhat arbitrary

    2. Allows the user to select which time field should be used in calcs per logged event

    3. Allows the user to set default time fields per run type (as these will most often not need to change per logged event per user) which when you sign up is setup as the system works now.

    I think as a functionality change this will:

    1. Allow all those who like how it works now to have it keep working that way

    2. Provide a mechanism for all those who don't like the way it is now to change it.

    i.e. make everyone happy.

    Cheers.

     Damien

    0
    評論操作 永久連結
  • Hi Elle... Me again (sorry!)

    I have made my opinions clear on this thread (more than once) and so I am not going to do it again. At the end of the day I am just a user and my opinion is no more important than anyone elses... Also I feel like I am shooting the messenger (By messenger I mean you Elle and I am sorry for that :-) )...

    So I am not going to express my opinion... But from time to time I might just highlight the odd example run... Hopefully Elle you could be kind enough to pass these examples on to your developers so that they can make up their own mind as to whether or not they are displaying data in the best way.

    Saturday’s run as displayed on my Strava Android app:
    Distance = 15.1km
    Time displayed in Strava = 59:16

    Achievements within that run:
    PR for 15km
    Time displayed in Strava = 1:00:50

    If they would like to view the activity they can here:
    http://www.strava.com/activities/167887388

    As I said... I’m going to refrain from giving opinions... But would just like to point out that a segment of this run appears to have taken longer than the entire run???
    (And no, I did not stop for a break anywhere)

    0
    評論操作 永久連結
  • If anybody is interested, I might have found a work around to this problem with Strava adding pauses. I've found a program that allows you to edit raw .gpx files. I was able to delete the duplicate entries that show little or no movement. This does not change the total time or distance but only the moving time and hence the pace is corrected.

    http://www.routeconverter.de/releases/en

    After you download the program you can load your gpx from garmin and then under the menu "Positions" choose "delete duplicate positions" and then enter a value in meters under "Select all redundant positions with a threshold of  XX meters" hit "select" and then hit "Delete selected positions". Close that window and then under "Positionlist" choose "Export to file" save it and then upload to Strava. You should have a more accurate moving time

    In my test file tried using different thresholds of from 0.5, 1, 1.5 and 2 meters. Basically the higher the threshold the closer the moving time is to the elapsed time. At 2 meters I got a fairly close pace to what GC gave me for the run. I didn't try higher thresholds than 2 but perhaps someone wants to play around there.
    Basically it shouldn't affect total time and distance, as i said. But I imagine that other problems could arise for example heart rate sensor data could get messed up or have gaps if you remove to many trackpoints

    Disclaimer: use at own risk ;)

    0
    評論操作 永久連結
  • @Damien - helpful indeed. Thanks for adding your insights! 

    @Steve - no worries, thanks for the extra examples. 

    Good tip @Tom! 

    0
    評論操作 永久連結
  • Here's an another example of why Moving Time for especially trail is a terrible concept. This run http://www.strava.com/activities/171470778 was 120km of hard jungle, swamp and mountain running. My finish time was 24h, Strava graciously gave me an 11:46. The winning time was just under 22h so on Strava I won with a 10h lead...

    0
    評論操作 永久連結
  • I think I have finally seen a benefit to “moving pace”... Inspired by the Commonwealth games I went out yesterday to try and break my PB for 5 miles... Setting off a bit over-enthusiastic I blew up after about 2 miles, but struggled on eventually stopping my Garmin Forerunner 110 after 5 miles at 30:55... Unfortunately that was a fail for the PB :-( ...

    Getting home a bit despondent, I downloaded my run to Strava, only to find that rather than displaying the truth, Strava was broadcasting that I had just run 5 miles in 29:18... Fantastic... I knew I was getting faster... Thanks Strava!

    PS - Sorry for making a joke on this thread... But lets face it that’s what moving pace is on Strava.

    PPS - Armand D – Well done on your 120km epic run... A cracking achievement in real time let alone fantasy Strava time!

    PPPS – Please can someone stop me posting on this thread... I’m even boring myself now... Come on Steve, it is what it is, just accept it, move on and get over it...

    0
    評論操作 永久連結

登入寫評論。

不是您要找的?

新貼文