Analyzing Skiing Data
My favorite sport would have to be skiing by far, nothing can match the awesome thrill and relaxation that it provides. Over the past few years I have begun skiing with a handheld GPS so that I have been able to record things like distance traveled, max speed ect.
While this has provided some interesting stats over the years such as and overall top speed of 88.8 km/h or a total distance traveled in a single day as 81km, I have always wanted to be able to see more detail on my day's skiing.
This year I have finally got around to having a crack at making a program to analyze GPX file that my GPS records and trying to separate data from lifts and ski-runs. After a few hours procrastinating during exam week and a few hours on a bus on the way to our school ski trip i have managed to come up with a woefully inefficient but reasonably effective program that is able to do just that.
My program takes the GPX file and outputs a range of statistics on runs and lifts as well as outputting a KML with the ski-runs separated from lifts. Here is some example data from my current version of the program generated from last day of skiing on the trip.
Runs: | 28 Lifts: | 24 ------------------------------------------------------------------------------- Max run speed | 94.06 Ave run speed | 10.035 ------------------------------------------------------------------------------- Max run length: | 3568 Min run length: | 49 Ave run length: | 1459 Total run length: | 40877 ------------------------------------------------------------------------------- Max lift length: | 1763 Min lift length: | 389 Ave lift length: | 921 Total lift length: | 28319.7737391
This data is reasonably accurate except for the maximum speed which is only measured as an inaccurate point speed (I will soon average speeds over a few data-points) and the discrepancy between the number of runs and the number of lifts is caused by things like the loss of GPS reception when I went into a restaurant for lunch.
To accompany the raw data here are some screen shots from within Google Earth. In the pictures chairlifts are represented by the solid read lines and the runs are represented by the squiggly blue lines. The pins in the middle of each lift are click-able and provide statistics on the lift when clicked.
Direct top down view
A slightly side on view
A closeup of the lift data
Unfortunately there is no version of this program that i deem suitable for download at the current time. In the future i plan to work on this further making it more efficient as well as turning it into a website where people are able to upload their skiing data to generate their own maps and statistics as well as including some social aspects into the process.
Add to
pyGitBook
As part of doing the report for my Software Design and Development project i tried to find an easy tool that i could use to convert all of my git history into a basic (but nice looking) logbook that i could hand in as part of the project.
Unfortunately i couldn't find any tools that would do this for me. The closest i could find was the commit log that git-hub provided something similar to what i was after but provided alot of stuff such as avatars and commit hashes that i didn't need.
So i decided to quickly whip up a script to pass output from git-log and turn it into a nicely crafted logbook.
To interface with git i originally looked into GitPython but it proved to be rather buggy and hard to work with so i ended up going the much more low tech method of just parsing the output of a standard git-log command.
For the output i decided that using HTML via Jinja2 would be the easiest method as it would allow the template to be updated very easily down the track.
Eventually i came up with a system that i am reasonably happy with, it could do with a bit more work but it will do for now, at least until i have got all my projects out of the way.
An example of the output can be seen HERE
The script is available on github at https://github.com/Hugoagogo/pyGitBook
Add to
Cleaning up the itunes media directory
In the process of moving my iTunes library to my new laptop (well its not so new anymore), iTunes has somehow managed to duplicate my entire library, creating a copy of every track, movie, tv show ect, and giving the duplicate some obfuscated name, i.e. ABCD.mp4
Besides being a large bunch of unnecessary files, they eat up a lot of HDD space, around 100GB.
After finally finding out what was eating up my HDD space it was easy to write a quick little python script to find and remove all of these files.
import re, shutil, os
CLEAN_FROM = r"C:\Users\Hugh\Music\iTunes\iTunes Media"
CLEAN_TO = r"C:\Users\Hugh\Desktop\junk"
FILETYPES = ["mp4","m4a"]
if not os.path.exists(CLEAN_TO):
os.makedirs(CLEAN_TO)
pat = re.compile("[A-Z]{4}[.](%s)"%"|".join(FILETYPES))
print "Starting"
for dirpath, dirnames, filenames in os.walk(CLEAN_FROM):
for fname in filenames:
if re.match(pat,fname):
shutil.move(os.path.join(dirpath,fname),os.path.join(CLEAN_TO,fname))
print "Moved: "+fname
print "Done"
I do not guarantee this script will work for you and check what you actually delete before you actually do it
Add to
Enter Squiglet
The graphics style i have chosen for the game i am working on, Saga of Sol, is very simple. The majority of the graphics such as ships, buildings, will be composed only of plain old white on black lines, with some "highlight" or "feature" lines being drawn a different colour to denote what team it is on.
I didn't think that it was appropriate to go for a full on vector/SVG library for pyglet such as Squirtle. So i have begun the creation of my own much simpler vector library "squiglet" that will handle the graphics for my game.
As of yet i have the basis of most of the vector classes complete (no functions yet to draw them into the game) and am about 80% of the way done on my own editor for the vectors.
If your interested in the project it can be found on GitHub at https://github.com/Hugoagogo/squiglet or you can follow along on my blog HERE
Add to
Weeks Unknown – Scaling Troubles
After many disruptions, holidays and general laziness i finally got around to doing some more work on Saga of Sol. To start off the term i had begun setting up the framework and basics of the local planet view. This is the view that when you are playing the game you are going to spend the most time in, building your armies and crushing your foes, and so on and so forth.
However not long into the programming i hit the barrier of software surface transformations. The simple effect being that when zoomed out a long way or scrolling quickly. Looking around at getting pygame to correctly take advantage of hardware surfaces, i quickly found that the general consensus is, dont bother and i got redirected to pyglet.
Pyglet is another python graphics library based around opengl and makes good use of hardware surfaces by default. In learning pylet i stumbled upon some basic guides on game desgin and another guide that provides a basic camera class for me to base my scrolling and zooming upon.
After lots of modification i have got to a point where one is able to zoom in and out towards a point on a map and scroll around in general RTS style. More difficult was trying to convert between screen and opengl (world) coordinates so you are able to identify whereabouts in game space your cursor is.
A screen-cap of the running trial, the scribble is made by moving the mouse to show correct conversion between screen and opengl coordinates
I will hopefully have some code up soon for those that are interested, as soon as it is tidied up and commented
Add to