OFFF-MX 2012 Sports Data Visualization by Dr Woohoo

bolivialodgeInternet and Web Development

Dec 14, 2013 (3 years and 6 months ago)

70 views

1
adiZero: Boston Square Gardens
2
I had the pleasure of being the director of the dev team that worked on the adizero: crazy light online
and immersive (building projection) team in 2012. This project re-invigorated me to begin running
again.
adiZero
adiZero: Boston Square Gardens
3
During the project, I needed a new pair of running shoes vs. my old and worn out pair of tennis
shoes, so I picked these up. It was a dramatic difference!
Training
Sharing
Phase 1: Acquire Data:
Running + iPhone apps + GPS = :)
4
Phase 1: Acquire Data*:
On a run, listening to music on my iPhone, it dawned on me there was probably some
software to track my GPS data. I found several, including EndoMondo (above), and the sports
geek in me, buried since my days when I worked at Taylormade-Adidas Golf, resurfaced.
Without realizing it, I was already in Phase 1 of a pet project to visualize the data I could
now capture.
*Note: The phases are based on the recommended approach by Ben Fry in his incredible
book, Visualizing Data
.
Phase 1: Acquire Data:
Cycling + iPhone + GPS + EndoMondo = :)
5
Phase 1: Acquire Data:
With a preference towards speed, I transitioned from running to cycling...
Phase 1: Acquire Data:
Heart Rate Monitor & Ant+ Receiver > iPhone app
6
Phase 1: Acquire Data:
...and found a set of sensors (cadence, speed and heartrate) that supported an open-source
format that was part of the Ant+ family, which is a wireless protocol that competes with
Bluetooth.
Phase 1: Acquire Data:
Wahoo Speed & Cadence Sensors
Sensor
Magnet
Cadence
7
Phase 1: Acquire Data:
Wahoo API
8
Phase 1: Acquire Data:
Wahoo has a Fitness iPhone app, but also the iOS API for geeks like me to bake their own
custom apps.
http://www.wahoofitness.com/iPhoneApplications.asp
http://api.wahoofitness.com/
Phase 1: Acquire Data:
iBike’s Newton+: Temperature, Wind, Power+++
9
Phase 2: Parse the Data:
iBike’s Isaac
10
Phase 2: Parse the Data:
Parsing the data had a series of challenges in terms of which iOS app(s) allowed me to capture data that could be
meaningful later on. Challenges included merging GPS data with other important variables from 2 different
sources and making sure they were synchronized correctly over the duration of the session.
- iBike0ZHHJ
- GPS not included!
- Must merge data
- Wahoo Fitness
- Intervals: 1 / sec
- Intervals: ~1 / sec
- iBike frame drop outs
- Merge doesn't work
- Image of GPS data… driving over mountains
Phase 3: Mine (Data Analysis):
Cheetah
11
Phase 3: Mine (Data Analysis):
Used a range of different application to convert the raw data into more meaningful analysis in
order to understand what is more important from a data viz perspective. The objective was to
understand how to improve my performance and what factors affected my performance,
e.g., temperature.
Phase 3: Mine (Data Analysis):
Cheetah
11
Phase 3: Mine (Data Analysis)
Inspiration:
Quokka Sports
12
Inspiration definitely comes from the ground breaking work that was done at Quokka Sports
in the late 90s in terms of sports and data visualization.
Phase 4: Representing the Data:
Cheetah > Google Earth
13
Phase 4: Representing the Data:
For this pet project, being able visualize the data based on a realistic geographic
representation provided meaningful information to help improve my performance. Think of
the type of representation as a genre/style of art/design. In this case, it’s realism, but other
genres/styles can changed out based on the final objective, e.g., abstract data visualization.
In the images above, I used GoldenCheetah to convert the raw data to a KML file so that I
could plot the path in Google Earth. Out-of-the-box, the KML plots a single color path of the
ride.
Phase 4: Representing the Data:
Cheetah > Google Earth
13
Phase 4: Representing the Data:
For this pet project, being able visualize the data based on a realistic geographic
representation provided meaningful information to help improve my performance. Think of
the type of representation as a genre/style of art/design. In this case, it’s realism, but other
genres/styles can changed out based on the final objective, e.g., abstract data visualization.
In the images above, I used GoldenCheetah to convert the raw data to a KML file so that I
could plot the path in Google Earth. Out-of-the-box, the KML plots a single color path of the
ride.
Phase 5: Refinement:
Google Earth (Walls)
14
Phase 5: Refinement:
As part of an iterative process, I began to explore the different parameters of Google Earth’s
API to increase the amount of data that could be conveyed in a geographic data viz of my
cycling data.
In the image above, I elevated the data above the ground as a line chart, customized the color
and added a polygon wall to improve the visibility of the data.
Phase 5: Refinement:
Google Earth (Custom Paths)
15
Phase 5: Refinement:
The Heart rate path has color variations: 2 color stripes represent going up the hill and the
reversed color stripes for coming back down the hill. Variations on the y-axis represent
different heart rates.
Phase 5: Refinement:
Google Earth (Everything)
16
Phase 5: Refinement:
Subtle refinement to the Speed path includes a semi-translucent vertical plane connecting the
path to the ground.
Phase 5: Refinement > Phase 1: Acquire:
ContourROAM camera++
17
Phase 5: Refinement > Phase 1: Acquire:
During the refinement phase it – and multiple rides – it became obvious that there was data
that was impossible to capture with the current sensors, e.g., coyotes running directly
towards me on the bike trail which definitely affects the ride. Enter the Contour and later the
GoPro cameras to help capture this type of information.
Phase 5: Refinement > Phase 1: Acquire:
ContourROAM camera++
17
Phase 5: Refinement > Phase 1: Acquire:
During the refinement phase it – and multiple rides – become obvious that there was data
that was impossible to capture with the current sensors, e.g., coyotes running directly
towards me on the bike trail which definitely affects the ride. Enter the Contour and later the
GoPro cameras to help capture this type of information.
Phase 2-5: Integrating video w/data
HTML5 + Base64 > JSON w/GZip & web workers
18
Phase 2 - 5: Integrating the video with the data
The Canvas Video experiment was born from the need of having a video player that could be used everywhere, especially on the iPad, with a low-level set of controls and the ability to add
effects to it. 
The initial concept was based on the idea of rendering individual frames into a canvas element and fiddling with it there. The problem with that idea is that we'd still have to go through
browser detection and choosing which video format to use for the playback. Also, it would never start playing automagically on an iPad because of Apple's restrictions for auto-playing media.
Rendering the individual frames to the canvas element gave us the possibility to add effects to the video. To do that, we have to "cache" the video frames using Canvas' ImageData, that way
we have control over every pixel and can easily create filters for it. But there was still one big problem: It had to be started by the user (because of Apple's restriction). 
That solution worked fine, but it didn't give us much playback control, and the fact that the whole thing had to be initiated by the user was frustrating. We were also losing frames and were
depending on downloading the video, then waiting for it to fully play so we could read/store the frames, then we could play it with the manipulated pixels. So that wasn't the ideal Scenario.
Then, Jay Moretti had the idea to cache the frames into a JSON file with Base64. That gave us more room to control stuff like video FPS, playing it in reverse, have a "buffer" for non-
destructive filters without using all the browser memory. But that also opened a bigger door: It would work with everything, without user initiation. That also meant that we could have GZip
compression on our frames, and that we could render the video to a div if we really wanted it to (think Video Playback on IE6). 
Jay then started to experiment a little further with how many frames we could playback efficiently, or how big those frames could be. Well... that was half a disaster as if almost fried Jay’s
laptop. We tried to run the non-destructive frame processing scripts with webworkers, which increased the performance a lot (on the iPad 2 it jumped from 8fps to 40~45fps) and it cranked
the temperature on the box up to 90º c/194ºf. LOL
There’s still potential with this approach, but it needs to bake in the oven longer. No pun intended. :)
Phase 4: Representing the (new) data:
Video Conversion: Sorenson++
19
Phase 4: Representing the (new) data:
With the video + data, to share the experience online on desktops and tablets, we had to
compress the video in 4 flavors, including: Sorenson, MP4, WebM and OGV.
In an ideal world, synchronizing the frame-based data with each frame would be as simple as
asking the video API for the current frame and retrieving the respective frame-base data out
of the database. Unfortunately, similar to Flash, it’s difficult if not impossible to get an
accurate current frame. To solve this, we wrote code to generate a binary graphic that’s
hidden out-of-view. The graphic is updated on a frame-by-frame basis and when it’s
decoded, it reveals the current frame, therefore resolving the problem of synching the video
and data accurately over time, regardless of how well the end-user's computer performs.
Phase 4: Representing the (new) data:
Heroku: Django. Python. Postgres DB. CSV in, JSON+
20
Phase 4: Representing the (new) data:
The backend consisted of a Django app running on Heroku with a Postgres DB, thanks to the
brilliant Joshua Thorp. This app parses incoming iBike CSV files and can output both JSON
and KML data types. Heroku completes the picture with a quick and painless system for
hosting Django apps (among many other web frameworks such as Ruby, Java or Node.js).
Phase 4: Representing the (new) data:
Backbone.js, Require.js, dat-GUI, Three.js, Toxiclibs.js ++& WebGL
21
Phase 4: Representing the (new) data:
Kyle Phillips glued the data and video with a custom Javascript Stack and WebGL and created
several visual representations of the data with controls to control the different parameters.
Phase 4: Representing the (new) data:
Backbone.js, Require.js, dat-GUI, Three.js, Toxiclibs.js ++& WebGL
21
Phase 4: Representing the (new) data:
In this image, the data is exposed as numbers and as a simple bar chart in the top right
corner.
Phase 4: Representing the (new) data:
Video + Data: Synchronization
22
Phase 4: Representing the (new) data:
Building on top of the previous bar chart, Kyle used an Arc Graph to visualize the data in a
different way. The video player, scrubber at the bottom allowed the user to adjust the current
time in the video and the data would continuously be in sync with the current frame. The UI
controls on the right hand side controlled a wide range of variables including which data to
display at any given point in time.
Phase 4: Representing the (new) data:
Video + Data: Cube Line Graph
23
Phase 4: Representing the (new) data:
The final visualization experiment Kyle did was plotting the data (gps, cadence, etc.) inside of
a 3d Cube Line Graph that the user could interact with by rotating the cube around, etc., in
order to get a better understanding of the data associated with the ride.
24
25