12345

Calculate grade (Read 2573 times)

Trent


Good Bad & The Monkey

    Interesting. Why does your version of the motionbased come up with 2496 feet of elevation change each way, while the motionbased run profile you linked to has over 4000? FWIW, this is my motionbased profile from Monkey 2007 - http://trail.motionbased.com/trail/activity/4468919 RA may ultimately have elevation data more frequently than every 200 m.
    gmaclin


      Interesting. Why does your version of the motionbased come up with 2496 feet of elevation change each way, while the motionbased run profile you linked to has over 4000? FWIW, this is my motionbased profile from Monkey 2007 - http://trail.motionbased.com/trail/activity/4468919 RA may ultimately have elevation data more frequently than every 200 m.
      MotionBased might be calculating accumulated elevation gain/loss with every GPS data point. Also, the spacing of these data points will vary as the runners speed up or slow down. As you know, the closer your datapoints are when accumulating altitude gain or loss, the more you are going to get. As I mentioned earlier, the sampling frequency from the GPS route I looked at varied widely, but averaged roughly 0.008 miles apart (mine are exactly 0.1 miles apart). That alone will make a huge difference in total elevation gain/loss calculations. Also, my testing shows that any small elevation errors coming from the GPS will cause a large descrepancy in your total elevation gain/loss calculations with such a small sampling frequency. (GPS devices are notorious for issues with elevation accuracy.) The spreadsheet I'm using minimizes these issues because it samples an interpolated elevation point at exactly the same specified intervals (every 0.1 miles) along the entire route. Doing it that way allows me to get a better "apples to apples" comparison because I know my altitude samples are being calculated with exactly the same frequency, no matter which route it is analyzing, or the frequency of the data samples it is using (within reason). Greg
      Trent


      Good Bad & The Monkey

        You are correct, motionbased does give an elevation point for every point it records, which is about once every 3-10 seconds during movement. The device records a point whenever it believes you have moved far enough from the last point. The distance between points stays fairly even (although not exactly even), it is the timing between them that changes with pace. As I see it, the question is this : is it accurate to calculate overall elevation change by including every 1-2 foot rise and fall in the road? If you think not, then you need to smooth. If you think so, you need to keep them in. Setting an arbitrary 1/10 or 1/30 or 1/100 mile spacing between points can eliminate a lot of the small rises and runs that you cover during an outing. Indeed, Monkey is on a course that has a huge number of small and large rolling hills. Even a 1/10 mile precision will miss many of them. But the runners feel them, all the same. Also, FYI, Motionbased "Gravity Service" corrects for artifact and error, and the profile you used for monkey had Gravity Service applied.
        gmaclin


          On the MotionBased graph here: http://www.pbase.com/gmaclin/image/97522108/original Did you notice the "bumpiness" of some of the hills? In particular, look at the uphill stretch between mile 7 and mile 8. Does that look correct to you? If not, then all these extra "bumps" are causing the total elevation gain/loss to be higher than it should be. The other charts don't have these extra "bumps" on them. Unfortunately, I have to go to bed now because I'm getting up for a half marathon early in the morning! I'll check back later this weekend when I get a chance. Have a great holiday weekend! Greg
          gmaclin


            ...As I see it, the question is this : is it accurate to calculate overall elevation change by including every 1-2 foot rise and fall in the road?...
            I would agree with that only if we were sure our altitude data was very accurate and had a fine enough resolution to support sampling the data with that kind of frequency. I think the most critical thing, when comparing different marathon courses, is to use the exact same sampling frequency with all of them and to be sure that the accuracy of the elevation data coming from all of them supports the frequency you pick. Greg
            Trent


            Good Bad & The Monkey

              Good luck tomorrow!! Yeah, those bumps are most certainly on the course. Not bumps so much as nasty unforgettable rolling monsters. They are the same bumps you see between miles 17 and 18, but headed in the opposite direction on the road. Those bumps are killer. There are a bunch of up/down rollers on the way up the hill at mile 10 that are not showing up very well. Go back and look at the elevation profile on my GPS of the course, it should show you where the hills and rollers are. In terms of elevation data resolution, the motionbased Gravity Service uses USGS reference elevation derived from a true altimeter to replace the GPS elevation estimates, the same as mapmyrun and runningahead. It is as accurate as we have. It does the replaces based on the recorded Lat and Long data, which as accuracy to ~98%+. It should be pretty good, even at every 3-10 second sampling. Sampling frequency consistency is not necessarily an equalizer. A flat course like Chicago, or one with a steady consistent grade, like Grandfather Mountain, would give the same estimates whether the sampling were done every 0.1 mile or every 0.01 mile. A rolling course, by contrast, would have its elevation estimate trimmed down by sampling that is too infrequent. I think the goal is not necessarily to be consistent so much as to be true; make sure that every change in contour is captured. With the USGS reference data, which is at high resolution, we should be able to do that. Kick that Halfer down!!!


              Why is it sideways?

                Don't let Trent fool you. On average, the course is flat as a pancake.
                gmaclin


                  Don't let Trent fool you. On average, the course is flat as a pancake.
                  Yes - I've heard that about Trent! Wink
                  Trent


                  Good Bad & The Monkey

                  gmaclin


                    Kick that Halfer down!!!
                    The good news is that I ran my best half marathon ever this morning and beat my old PR by almost 5 minutes (finished in 3:33:15)! The bad news is that I can't really count it as a new PR because it was an untimed/informal race put on by my running club on an unfinished stretch of freeway near where I live. Oh well, I'm still very happy with my performance and hope to repeat it at an "official" race sometime soon.
                    In terms of elevation data resolution, the motionbased Gravity Service uses USGS reference elevation derived from a true altimeter to replace the GPS elevation estimates, the same as mapmyrun and runningahead. It is as accurate as we have. It does the replaces based on the recorded Lat and Long data, which as accuracy to ~98%+. It should be pretty good, even at every 3-10 second sampling.
                    So, Trent, do you think MotionBased has the most accurate elevation data available from a site that let's you map races? If so, I'll start using their data.
                    Sampling frequency consistency is not necessarily an equalizer. A flat course like Chicago, or one with a steady consistent grade, like Grandfather Mountain, would give the same estimates whether the sampling were done every 0.1 mile or every 0.01 mile. A rolling course, by contrast, would have its elevation estimate trimmed down by sampling that is too infrequent. I think the goal is not necessarily to be consistent so much as to be true; make sure that every change in contour is captured.
                    I agree that with some courses the sampling frequency does not make much diffference. But, if you want a tool that will accurately compare a wide variety of courses (flat to hilly), I'm convinced that it must use the same sampling frequency on all of them. The key is to use the highest sampling frequency possible while taking into account the resolution of the elevation data you have to work with. Also, for this to work accurately on a very hilly course like the Flying Monkey, I think the map should be generated manually to follow the roads as accurately as possible. Using a GPS-generated map is going to introduce a lot of "false" hills because it cuts some of the corners and can put your position lower or higher on a hill than you actually are while you are traversing it. Interesting discussion! Greg
                    Trent


                    Good Bad & The Monkey

                      Good work on the half! I think the optimal solution would be a mapping tool that: 1. lets the user decide how often to plot points 2. allows GPS upload and gives the user the ability to edit the points once uploaded 3. gives elevation data regularly and at a high resolution Currently: - RA does #1, but does not reveal elevation for all the points at a high resolution - MB does neither 1 nor 2, but does allow GPS upload and reveals elevation for all the points, almost doing #3 - MMR does #1 and kinda does #2, but does not reveal elevation for all the points (I believe) I do know that RA will be able to do #1 and #2 soon, and possibly increase the point resolution to comply with #3 before long. Eric has been working hard to get this functional. Soon, I hear. Soon! I agree that a regular standardized elevation sampling rate would be optimal, but I think it should be far more frequent that 0.1 miles since you can miss a lot on rolling courses at that resolution. What is the correct resolution? I do not know, but probably somewhere between 5 and 10 meters.
                      Trent


                      Good Bad & The Monkey

                        BTW, I ran on the Monkey course and thought of your profiles as I passed the rolling hills that look like the little bumps between marathon miles 7 and 8. My running partner (who is from Indianapolis, flat) actually complained about how nasty they were. I responded, "they are just little bumps". Wink But there are many more of these little bumps than show up on the profiles.
                        eric :)


                          Yes, I've been working my tail off to get the next version of the log completed. I'm actually working on the map editor right now. It will be able to support higher resolution elevation data. I have all the pieces to allow for ultra high resolution elevation data. All I have to do is hook everything up. As for course grading, I do not think that you need precise data so long as the comparisons are made using consistent data. I don't think we can reduce a course's difficulty down to a single meaningful number. The next best thing is to say that course A is harder than B. Once I get the log completed, then I can play with this some more.
                          12345