Written by Alex Code, March 30, 2015
If you’ve read our About Us page you’ll know that I’m an outdoors guy. I love being outside and doing just about anything. I was fortunate enough to make friends with a great guy in college who had similar ambitions (or perhaps obsessions) and we took a lot of amazing trips to amazing places. Interestingly enough, he was the one who usually carried the map…
As with any hobby you turn into a job, you have to step back and have fun with it every once in a while. So, I had the idea a couple weeks back that Andrew (roommate and adventurer friend) and I should team up to make a map. I reached out to him about our trips and about things he’s doing now (he’s an ultra-marathoner, by the way) and we discussed options. As I suspected, he’s been collecting data (he’s a bit of a data/stats geek) on his running habits, routes and all the fun stuff that training watches and gadgets let you do these days.
Perhaps we will do maps about our trips some other day, but this time I wanted to follow the process of mapping Andrew’s runs.
by Alex Code & Andrew “Giff” Walters
Andrew is a Suunto guy at the moment and fortunately most of the data here is collected in an app by Suunto and provided through an interface with good export options at MovesCount.com
Andrew provided me with GPX and KML versions of the file.
KML is a file type used (and popularized by) Google Earth. This gives us a quick and easy-to-use view of the data and is pretty fun to work with. Clicking on the track shows that it has some good information associated with it. The stuff that excites me includes heart rate, altitude and speed. We could dive into some of the other factors to further analyze this run in comparison with others, but we’ll keep it simple for now.
Google Earth is great for simple maps, visualization and information consumption. It isn’t a full featured GIS program though.
For more options we’ll turn to the GPX file which is a GPS exchange file that is widely used with consumer grade GPS and monitors like Andrew uses. To display and convert the GPX file to common GIS file formats, we’ll use one of my favorite programs QGIS. It’s an open source program that has a lot of cool capabilities.
When you first upload the data, QGIS tries to detect the coordinate system and projection for the file. GPS units record data in a worldwide latitude and longitude system (WGS84). We’ve set my map to sense this and apply a default projection.
Right now the map is pretty boring, so in order to save some time we will import a set of pre-made basemap layers that help provide geographic context. QGIS provides several options, but we really like the OpenLayers Plugin, which makes a number of basemaps layers available. From this we’ve selected a OpenStreetMap (kind of like Google Maps) layer that we like.
Zooming into the layer shows that his trail is made up of two parts; 1. a green line, and 2. a ton of dots. In order to better understand what we can do with this data we want to look at the underlying data stored in tables.
After pulling up the data for both the lines and the points, we find that the line generated in the GPX export is one continuous polyline. The real data is in the points.
Here is one point’s data, with it you can see the available fields.
Here the important fields are:
- Ele (Elevation)
- gpxtpx… (This looks like heart rates to me, mixed with tags)
In order to use the heart rate data, we will need to remove the tags. The tags are likely there so that Suunto’s programs know what kind of data it is looking at.
Removing the tags requires a short expression. There are a number of expressions that could work here, but I’ve chosen a sub-string selection expression. I’m running it against the “gpxtpx_Track….” column and passing the result into a new “HeartRate” column. This will give me clean integers.
This operation turns the field from “<gpxtpx:hr>142</gpxtpx:hr>” to “142”. Which will be easier for users to read and for us to use in mapping functions.
There are also a lot of fields that have Null values, so we’ll get rid of those since they’re just cluttering things up anyway.
With our data clean, we can start looking at the ways we can use it. Changing the data has made the tables easier to read but doesn’t change our ability to quickly see patterns (unless your a genius like Douglas). What we want to do is see if we can figure out if there are patterns that provide more information about Andrew’s running and his interaction with this course.
To do this we get into data visualization and analysis through mapping.
Going back to the map it just looks like a green dot covered line. We’ll change that by looking at Andrew’s heart rate first. To do this we’ll tie the appearance of the dots to some of his heart rate statistics.
Here we’ve made 10 beat per minute (bpm) intervals that cover the range recorded. This required a little tweaking. We’ve applied a nice orange/red color scheme to it and cleaned up the legend entries, just in case we want to make a print/pdf map at some point.
When we apply this styling, the result is interesting but the point style (left image) causes discontinuity and since a heart should not be discontinuous…. we don’t want that.
In order to smooth things out and make it easier to see contrast between the two styles, we remove the outer line. Now you can actually read into the image a bit.
Looking at the topography contours we can tell there is an elevation change along the trail as it goes toward 20th Avenue. Using heart rate we can tell the direction of travel along the line.
Looking at this picture we have to question something about the data quality. Either Andrew was drunk (probably not) or delirious (possibly) OR his watch has a degree of drift (most likely). Consumer grade GPS units are generally accurate in the 5-20+ meter range. Checking with Andrew revealed that the squirrely nature of the line at the end was a watering station (actual water, not booze) After he turned around, the line crossed back and forth over itself, which could easily be the result of the GPS or variations in his path.
At another spot we see a blank area and some speed change. Here, either his GPS wasn’t able to receive signal for a moment due to the canyons blocking out satellites or something else was at play. From the topographical map above, it doesn’t look like there is any extreme relief.
With aerial imagery you can clearly see that there are several gaps in point collection near sections of steep relief. This may be from the steep walls which can create satellite shadows and deteriorate satellite data. I also talked with Andrew about this section and he noted that the larger gap in the upper right quadrant of the picture is where the start line is, which explains why you see the color ramp from left to right in the line. This is also reflected in the numbering of the points from the GPS.
I selected all of those data points in the map and then filtered them in the table view. The data set is composed of 23,960 points so it confirms both the first and last point in the race (and data collection series).
As a side note, it is worth explaining why the map with the contour lines doesn’t show the cliffs on the aerial image. This is because because the data that was used to map the contours is publicly available digital elevation data. A large amount of this data is in 30m-90m (sometimes 100m) grids with the content of each square being averaged. These little indentations in the cliff line measure only about 90m and would then be smoothed in the process used for contour creation.
What does all this mean? Cliffs often don’t really make it on topography maps. Runners beware! (This also used to be a great source of aggravation for Andrew and me when trying to seek out new areas for rock climbing.) It also means that aerials are excellent resources for mapmakers, but nothing replaces having some on-the-ground knowledge.
That’s it for now! We’re hoping to get back at this data set again in the near future and demonstrate calculations on distances, speed and elevation. Here’s a teaser:
Or maybe Andrew will serve us up with something else fun!
If you want to explore the heart rate data in an interactive map, check this out: http://www.line-45.com/runmap/
(It’s slow to load and the symbols still have the black outline because I haven’t optimized it for the web yet, so I apologize if you’re using a slower connection. BUT, you can read all 23,960 points to see what his heart rate was, if you so desire.)
- Welcoming Douglas to our Team
- Python for Quick and Easy GIS Data Manipulation
- Updates from the Line 45 Team
- Fetch and Combine CSV Files from the Web
- Resources for Water, Wastewater and Stormwater Utilities