Script to Upload GPX Tracks to Strava
For recording of GPS tracks for my roamings, I use Garmin Etrex 20 - a good choice for a tourist. For a cyclist, more appropriate devices exist, like those of Garmin Edge series. For me, I attached my navigator to a handlebar (Garmin sells a matching mount) and was done. No need to waste money on another terribly expensive gadget.
Since last vacation I learned about Strava from friends, and created an account there. The service allows to upload GPS tracks of trainings from devices. For Garmin Edge, there is a plugin (I suspect Windows-only) to automate the process - when a device is connected, new data is transfered without user interaction. Obviously, nothing similar was ready for Etrex device series and Linux Os series.
There is a manual method to upload GPX files to the website. And it turned out Strava also provides API to work with the service. And there are examples on the Net on how to use that API from Python. The next step was obvious.
I spent some time to write a script, upload-gpx-tracks.py. It accepts one argument - a device name, like /dev/sdb.
Implementation and usage details follow.
- The script is written in Python 2.7
- It uses DBus to mount/unmount a filesystem from specified character device. The script looks for new files are inside Garmin/GPX directory.
- It re-uses code from https://github.com/dlenski/stravacli to communicate with Python bindings to Strava API, and it depends on https://github.com/hozn/stravalib to be installed. Also, obviously relevant DBus bindings for your distro have to be present.
- Authorization to Strava is done the same way it is done in stravacli. The token is saved in \$HOME/.stravacli file.
- To ignore old tracks which have already been uploaded, a timestamp of the latest successful synchronization is kept in the same file. Then, only files created after the recoded timestamp are considered for uploading. There is also a lower size limit to keep from uploading very short tracks of waypoints (which are also GPX files but store no tracks)
- The script uses DBus desktop notification mechanism, so quite a few messages pop up informing user about the process.
Things to Improve
I could have done it better. Several ideas for improvement.
- Run the script automatically on device attach. I tried to add an udev rule to start the script on a storage device attachment. But there have been some problems with DBus session - it was really picky, wanted \$DESKTOP to be defined and valid, a DBus-session file defined, maybe some other problems, I cannot remember all of them now. Oh yeah, figuring out parameter passing conventions to Dbus methods was a separate adventure to undertake. In the end, it failed to detect an FS or something, giving just one more cryptic error about a missing method. Maybe that was a timing issue, or my non-understanding of its complaints, but I was really tired at that moment and gave up.
- Instead of relying on udev mechanism, maybe it should hook up on desktop-level notifications. It can be be either something DE-specific, like only for KDE (I don’t care much about Gnome/Xfce/Unity/whatever these days), or Freedesktop-compilant. The latter approach is of course preferable.
- If not automatically started, then the script should at least detect which device to mount instead of being told so. This will improve user experience when there is a lot of storage devices.
- The script should not fail if a filesystem has already been mounted. Just use the existing mount point.
As usual, the script has been only tested on one computer. Be warned that it can destroy your data, your device, your miserable life, or just fail for no reason for you. No guarantees.
It’s licensed under GPL3, the same thing stravacli uses.