bicycle, physical training, run, telephone, annex

Antisocial Activity Tracking

A GPS track provides useful a useful log of physical activities. Beyond simply recording a route, the series of coordinate and time mappings allow statistics like distance, speed, elevation, and time to be calculated. I recently decided that I wanted to start recording this information, but I was not interested in any of the plethora of social, cloud-based services that are hip these days. A simple GPX track gives me all the information I care about, and I don’t have a strong desire to share them with a third party provider or a social network.

Recording Tracks

The discovery of GPSLogger is what made me excited to start this project. A simple but powerful Android application, GPSLogger will log to a number of different formats and, when a track is complete, automatically distribute it. This can be done by uploading the file to a storage provider, emailing it, or posting it to a custom URL. It always logs in metric units but optionally displays in Imperial.

What makes GPSLogger really stand out are its performance features. It allows very fine-grained control over GPS use, which allows tracks to be recorded for extended periods of times (such as days) with a negligible impact on battery usage.

For activities like running, shorter hikes and bicycle rides I tend to err on the side of accuracy. I set GPSLogger to log a coordinate every 10 seconds, with a minimum distance of 5 meters between points and a minimum accuracy of 10 meters. It will try to get a fix for 120 seconds before timing out, and attempt to meet the accuracy requirement for 60 seconds before giving up.

For a longer day-hike, the time between points could be increased to something in the neighborhood of 60 seconds. For a multi-day backpacking trip, a setting of 10 minutes or more would still provide great enough accuracy to make for a useful record of the route. I’ve found that being able to control these settings really opens up a lot of tracking possibilities that I would otherwise not consider for fear of battery drain.

GPSLogger

Storing Tracks

After a track has been recorded, I transfer it to my computer and store it with git-annex.

Everything in my home directory that is not a temporary file is stored either in git or git-annex. By keeping my tracks in an annex rather than directly in git, I can take advantage of git-annex’s powerful metadata support. GPSLogger automatically names tracks with a time stamp, but the annex for my tracks is also configured to automatically set the year and month when adding files.

$ cd ~/tracks
$ git config annex.genmetadata true

After moving a track into the annex, I’ll tag it with a custom activity field, with values like run, hike, or bike.

$ git annex metadata --set activity=bike 20150725110839.gpx

I also find it useful to tag tracks with a gross location value so that I can get an idea of where they were recorded without loading them on a map. Counties tend to work well for this.

$ git annex metadata --set county=sanfrancisco 20150725110839.gpx

Of course, a track may span multiple counties. This is easily handled by git-annex.

$ git annex metadata --set county+=marin 20150725110839.gpx

One could also use fields to store location values such as National Park, National Forest or Wilderness Area.

Metadata Views

The reason for storing metadata is the ability to use metadata driven views. This allows me to alter the directory structure of the annex based on the metadata. For instance, I can tell git-annex to show me all tracks grouped by year followed by activity.

$ git annex view "year=*" "activity=*"
$ tree -d
.
└── 2015
    ├── bike
    ├── hike
    └── run

Or, I could ask to see all the runs I went on this July.

$ git annex view year=2015 month=07 activity=run

I’ve found this to be a super powerful tool. It gives me the simplicity and flexibility of storing the tracks as plain-text on the filesystem, with some of the querying possibilities of a database. Its usefulness is only limited by the metadata stored.

Viewing Tracks

For simple statistics, I’ll use the gpxinfo command provided by gpxpy. This gives me the basics of time, distance and speed, which is generally all I care about for something like a weekly run.

$ gpxinfo 20150725110839.gpx
File: 20150725110839.gpx
    Length 2D: 6.081km
    Length 3D: 6.123km
    Moving time: 00:35:05
    Stopped time: n/a
    Max speed: 3.54m/s = 12.74km/h
    Total uphill: 96.50m
    Total downhill: 130.50m
    Started: 2015-07-25 18:08:45
    Ended: 2015-07-25 18:43:50
    Points: 188
    Avg distance between points: 32.35m

    Track #0, Segment #0
        Length 2D: 6.081km
        Length 3D: 6.123km
        Moving time: 00:35:05
        Stopped time: n/a
        Max speed: 3.54m/s = 12.74km/h
        Total uphill: 96.50m
        Total downhill: 130.50m
        Started: 2015-07-25 18:08:45
        Ended: 2015-07-25 18:43:50
        Points: 188
        Avg distance between points: 32.35m

For a more detailed inspection of the tracks, I opt for Viking. This allows me to load the tracks and view the route on a OpenStreetMap map (or any number of other map layers, such as USGS quads or Bing aerial photography). It includes all the detailed statistics you could care about extracting from a GPX track, including pretty charts of elevation, distance, time and speed.

If I want to view the track on my phone before I’ve transferred it to my computer, I’ll load it in either BackCountry Navigator or OsmAnd, depending on what kind of map layers I am interested in seeing. For simply viewing the statistics of a track on the phone, I go with GPS Visualizer (by the same author as GPSLogger).