A Rat Race, or a Great Way to Start the Day
Recently, during a particularly severe patch of winter weather and much too much shoveling of snow off my driveway, I decided, with help from the Wolfram Language, to bring back memories of fairer weather by looking at commuting to work on a bicycle.
This past year, I finally succumbed to the increasingly common practice of recording personal activity data. Over the last few years, I’d noted that my rides had become shorter and easier as the season progressed, so I was mildly interested in verifying this improvement in personal fitness. Using nothing more than a smart phone and a suitable application, I recorded 27 rides between home and work, and then used the Wolfram Language to read, analyze, and visualize the results.
Here is a Google Earth image showing my morning bike route covering a distance of a little under 11 miles, running from east to west.
To transfer data from the smart phone, I used GPX (GPS Exchange Format), a file format supported by major GPS device manufacturers and available in many software applications. A typical GPX file includes time-stamped location and elevation data, and the Wolfram Language returns this data as a list of rules, descriptively named Geometry, PointElevation, and PointTimestamp.
This displays a fragment of one of the GPX data files:
Taking advantage of new geographic data and computation functionality in the Wolfram Language and the available time and position data, I quickly and easily created an animation of the day’s ride (for details of functions, position, and time, see the Initializations in the attached CDF). Click the Play button to view animation.
More interestingly, and with just a bit more effort, I next compared all the morning rides of the season in a single animated race, in effect a rat race to work! The season’s leader is shown in yellow, of course!
The results of this rat race are as follows:
Now for a quick peek at ride times in chronological order. This clearly supports my earlier observation that ride times improved as the season progressed, and as I logged more miles on the road bike.
While the preceding calculations and visualizations are nice, we can do much more. The GPX files contain time-stamped elevation data, so not only does this allow easy visualization of the common road profile, but even better: detection of downhill and uphill segments of the route via new signal processing peak detection functionality.
First, here is the standard road profile:
Prior to locating the peaks and valleys, I smooth the elevation data so as to capture only the large-scale local maxima and minima in the signal. To accomplish this, I first use uniform linear resampling to correct for the highly irregular intervals at which the data was captured, then blur it with a GaussianFilter.
The smoothing operation removes spurious peaks and valleys in the elevation data. I determine the remaining large-scale peaks using FindPeaks and segment the route into ascending and descending sections.
This shows the uphill and downhill sections of the morning ride on an elevation plot:
For an arguably even more useful visualization, here are the rising and falling segments of the ride on a map:
The approximate distances of the uphill and downhill sections are readily available from the ascend and descend lists computed earlier. The following result confirms the simple truth that going to work is always harder (i.e., uphill), and therefore less pleasant than the return trip.
I am already looking forward to the next season of riding and more fun in analyzing my data using the Wolfram Language.
Download this post as a Computable Document Format (CDF) file.
Nice post Mariusz. I started to do some work on something similar a few days ago actually. Now I can cut some corners by using your code. :-)
I used to do this sort of analysis with heart rate data, but transferring the raw data to Mathematica became enough of a hassle that I stopped. My HRM can upload automatically to RunKeeper, and Mathematica can download data from runkeeper but, for whatever reason, not the HRM data. I wish that would be fixed.