‘ve been working all weekend on putting down a solid visualization of baseball games that gives an informative overview of exactly what happened in a game in the least amount of space available. I want to give a variety of ways to view a game in order to get the most out of it, but first and foremost I want to provide a simplified overview of all game events that shows the flow of the game and allows people to see exactly what happened.

I started by trying to classify events and think of how that I can rank them each in a way that will allow me to show them in a linear way that both unifies them per team as well as shows the magnitude of each event. In this idea I thought about the major possible events and ranked them according to the impact they have on the game, form the perspective of the batting team.

Tier 5: Homeruns,
Tier 4: Triples
Tier 3: Doubles
Tier 2: Singles
Tier 1: Walks/Stolen Bases
Tier 0: Outs

I had to revise this several times after experimenting with it, mostly due to issues wtih classifying walks/stolen bases and singles. At first I thought that I could get away with putting them in the same tier, since they all result in the player moving up one base. I then realized that there is a clear difference between the two. While walks and stolen bases both advance the runner towards scoring position on the diamond, singles put the ball in play, which can result in RBIs. Walks can sometimes result in an RBI if the bases are loaded but even this is restricted to one run, while a single can drive in up to three runs.

After coming up with this classification, I began to work on a circular visualization of events that classified them according to a number of criteria. While in concept this made sense to me, in reality it turned out to look somewhat interesting but really show a lot of nothing with a simple look. I also attempted to create an organic shape from this visualization just to see what it looked like, and while this too proved interesting I dont’ think it was very successful in showing anything.

I then moved on to the next logical step, visualizing things linearly. I continued with my key of dashes and colors, and while linearly things made a bit more sense it was still not working very well IMO. I experimented with representing outs as negative events at this point as well but I don’t think it read the way I intened.

At this point I also created a more organic flow diagram from these charts. I think this actually worked out really well and is a great overall representation of the flow of the game. While it doesn’t really show exactly what I wanted from the first overall view of the game a user is presented with, I think it is a great sub-view and something that I’m going to continue to investigate

This is where I realized I was sorta getting caught up in doing the same thing over and over, so I decided to give it a rest and move on the next day.

Today I started working again and had some major breakthroughs. I spent a lot of time working on various visualizations, trying to bring down the amount of data ink used (as per reading Edward Tufte) and began to really simplify everything. I did a lot of different experimenting, and came up with a visualization I think finally works pretty well. I did some quick testing with a few casual baseball fans I know (obviously need to do more user testing but something is better than nothing and I just finished it!) and I was pleased that they could easily recreate the narrative of a game themselves after a very brief explanation which wasn’t repeated.

All of this needs more work I know, but I put in a crapload of time this weekend and I think that I am definitely making progress. I also worked with a real data set vs just making things up, which was a bit of a pain in the ass at first but really helped me a lot in the long run. I hsould have been working like this before and I’m glad I am doing it now.

Thats it for now, I also did a good amount of work on the otehr sections of the application but I don’t feel like they are ready to show yet so that will be another post.

If you read this please check everything out and give me some feedback!

Thanks,

-Steve

OK this is another post that is more for my own future sanity than anything else. This has been a huge pain in the ass for me many times and I want to document the steps I took to get this working.

First, this is a good general overview
http://cd34.com/blog/programming/python/mysql-python-and-snow-leopard/

So I downloaded/installed MySQL, then I had to add it to my PATH var to get the MySQLdb install to work.

//Open With textmate
mate ~/.profile

export PATH=”/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:$PATH”

then make sure you update your profile or close and open a new terminal window
source ~/.profile

that will let the MySQLdb install work. Then when you run Python and try to use MySQL db you’ll get errors. What you need to do is the following:

change your PATH to export PATH=/Applications/MAMP/Library/bin:$PATH

which links to MAMP mysql, then run this command

sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock /tmp/mysql.sock

Then you should be good to go. Might be able to skip the first step but I don’t know if the MySQL that comes with mamp is 64bit and you need 64 bit for snow leopards install of Python..

Why is python such a pain in the ass?

So I have been doing a lot of research about the data I’m going to need for thesis, and where I should get this. The two main sources of data I am looking at are Retrosheet, which I’ve previously mentioned extensively, and the unofficial MLB xml sources which are used by the official MLB gameday app.

Both of these resources have their advantages/disadvantages, and neither completely suits my needs. I am starting to think that in order to get what I want, I will have to create a hybrid of the two, but the big question is how exactly will I do this? Here are my thoughts on the good and bad about each source:

Retrosheet:
Great resource, a pain to get into a database but once its there its very compete
Data going back to 1951
Self contained, doesn’t rely on resources that may be unavailable in the future
Doesn’t contain any current season data
No great way to get data, have to write custom XML to get data in a usable form

MLB Data:
Completely thorough
Provided in XML format that is really well executed
Updated daily for current games
Not official, no promises that it will be there in the future
Questionable as far as a data source/retrieving data repeatedly.

I have been working on creating an API for Retrosheet games that returns complete data, and I’ve made some headway but its largely a work in progress. After finding the XML based MLB data I can see that they have already tackled this and have the data in a beautiful format that is pretty much exactly what I wanted to make. They do not however have this data stored in a database or any easy way to request a game in a traditional way.

I think that my strategy for this problem will be to combine both resources into a best of both world’s situation that I can make freely available to anyone. I will adapt the MLB XML format and parse all Retrosheet games to this, taking advantage of the format already established by MLB.com as a standard and saving myself some work. I will then write code that does the opposite with the MLB.com data, checking every day of a season and breaking down their XML into data that can be put into the retrosheet database. This will likely be the hardest part of the process but I think I can figure it out. This will provide me with a complete retrosheet database with current game data and an XML format that will provide a full summary of a game in an easy to read way.

Hopefully this works out for me, if I can do this and provide access to it through my web server I think it will be exciting and a great contribution to the baseball data community.

Super Simple Prototype for Thesis.

Game data for MLB seasons 1952-2008 acquired from the site retrosheet.com, parsed into CSV then MySQL formats, read by PHP and converted to XML, then read into openFrameworks.

The size of the ring denotes the length of an inning, the blue represents the home team and the green the away team. Dark colors represent outs, bright colors represent runs. Grey pieces are events I haven’t checked for yet (caught stealing,wild pitch, etc).

Super simple audio events are assigned to each plate appearance as well.

Here are a couple of CV Prototypes I’ve done in school. This semester has been a really big challenge for me. I feel like I learned a lot but at the same time wasn’t able to put the time and effort I wanted into any of my projects, so most of them exist in prototype form only. Hoping that one day I can expand upon these and create something great if I ever have time…

Beehive
Working with Lee Meredith and Justin Blinder we created this experiment that allows users to interact with virtual beehives. When a user knocks into the beehive they are swarmed by bees which continue to attack until they leave the video frame. The bees then return to their hives. Created using CV tracking and particle forces.

Puking
We also created this simple app that is a lot of fun. Basically bend over and you puke. Using CV Tracking and detecting which direction the person is bending in using countNonZeroInRegion() function in ofxCvImage.

After a LOT of work/heavy lifting with C++, audio timing and beat spacing, I finally am relieved to have a sizeable prototype for thesis that is a big step towards my intended project. It may not seem like a lot in the form I’m presenting it, but it involved a lot of planning, coding, and adjustments to my XML in order to create something that I can test.

This test consists of two audio files, both generated live from baseball game information read from a database, parsed to XML, imported into openFrameworks, then associated with certain beats in two different patterns. I associated the same beats with events in each pattern so that they can hopefully be compared in a similar fashion. The beats are as follows:

• Inning Change: Snare Drum
• Top/Bottom of inning: Bass Drum
• Out: Kick Drum
• Hit: Clapping

The first pattern is linear, which means that every plate appearance by a player is mapped to an equally timed beat. This diagram attempts to illustrate what I mean…

This approach is true to the actual rhythm of the game, and spaces the beats as they would occur in actual time. The audio effect that this gives can be quite random at time, and while it represents the game very well

Here is what this sounds like:

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

The second approach I took was to use the constants in the game (9 innings/Top and Bottom to each inning) as steady beats, and then use the variable events within these constants (hits, runs, outs, etc) as sections of variable timing within the the constants. The diagram below attempts to illustrate this:

This approach doesn’t hold as true to the actual rhythm of the game, however I think that the contrast between constant, steady beat patterns and variable events gives both a feeling of the game as well as a better sounding, more rhythmic sound.

Here is what this sounds like:

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

I’d appreciate any feedback you have as well as suggestions, so please review these two tracks and let me know what you think in the comments!

I’ve begun to dig into the Retrosheet database that I recently acquired (see previous post) and have started to plan out a basic format for parsing the immense amount of data into a readable, usable XML format that will let me retrieve game data in a simple, direct way.

In order to do this, I had to first think about how a baseball game is structured. What are the constants and what are the variables? How can I structure my XML around this?

Speaking in terms of a baseball game and not the way that Retrosheet is formatted, the constants in a game are as follows:

• 9 Innings
• 2 halves of an inning
• 1 set of at bats and 1 set of fielding (defense) for each team
• Away team always bats first in an inning
• Each half of an inning consists of 3 outs
• An out always ends an inning

After writing this down, I was starting to see a structure.

I then started to investigate how the game data was stored in the retrosheet database. The database is structured in a somwhat simplistic way, with only two levels of heirarchy: Games and at bats. Within the at bats lies all the other information about where the at bat took place in the game…which inning, which team, how many outs, etc.

This format didn’t quite mix with the way that I was thinking a game should be represented, but for a database structure it made perfect sense. I then began to think how I could merge these two formats, and what information I could gain from a game.

After several attempts, this is the XML format that I have come up with which I think will work quite well in organizing the information that I need.

This format organizes the game around the structure I mentioned previously, then adds in the game events from retrosheet as Plate Appearances within outs. This approach creates an XML document that is very easy to read, which I can use to reconstruct a game very quickly and pull connected data out based on related fields. At this point I am not pulling all the data but a smaller set that will be easy for me to get started with.

Here is a diagram of the overall structure.

The first major challenge of my thesis project has been acquiring historical data, parsing it into a usable format (database), and then going through it and trying to make some sense of it. I’ll try to go over some of the steps I took to get where I’m at (as usual both for anyone trying to do the same thing and for my own sanity the next time I need to do this).

First of all, thanks to the extremely hard work of a few super dedicated individuals, historical data for every baseball game  is available online at the site http://www.retrosheet.com

These files have an insane amount of data for almost every game played for at least the last 50 years (there is more but before then the complete info is a bit hit or miss). Unfortunately, due to the way that they are recording the data (I’m not really sure how, but I assume it involves some sort of spreadsheet), the files are not really in an easily interpreted format. Luckily, again due to the work of a few dedicated individuals, the open source community has a solution for this as well. The tool “Chadwick” (named after the man who is historically credited with inventing the first widely accepted form of baseball scorekeeping) is a command-line unix tool which can take these files and parse them to Comma Separated Value (CSV) files. This does entail learning a proprietary command language for the compiling (it looks sorta like regular expressions but I don’t think its related), but the end result is worth it.

From this point (once you have your CSV files) you can create a database in the SQL of your choice (MySQL, sqLite, etc) and import the database.

Fortunately there are a few people out there who have already done a great bulk of this work, and have written some scripts to take care of a lot of this process for you. Unfortunately, they are using Python with the MySQLDB extension, which under snow leopard is near impossible to compile at this time.

The main site I have been working from to get this data to work can be found here:

http://blog.wellsoliver.com/2009/06/retrosheet/

This guy is the perfect combination for my thesis: a data geek and a huge baseball fan. He has made several amazing tools (a few of which I look forward to getting into in the future) that allow people to get baseball data in a bit more friendly manner, and shares his experiences obtaining the data.

I spent the better half of a weekend attempting to get his code to work on my computer, due in no way to any error on his fault but solely based on the fact that snow leopard refuses to compile and install a workable version of MySQLDB to python.

I finally gave up, and decided that I would go to plan B and run the script on my server (Dreamhost). This too proved to hit a few roadblocks (the version of Python installed on my server wasn’t new enough, had to install new Python then compile and install new MySQLDB a couple times )

Then I had to figure out how to compile the Chadwick source code under Unix, which seemed very unclear until I actually opened the readme file and realized all I had to do was type ./configure in the Chadwick directory and it would compile no sweat.

I finally got the code to run and (seemingly) work! Then I realized I had another error…my server was killing my requests and I was only getting part of the data. After emailing back and forth with Dreamhost for an hour or two, I finally realized what the issue was. The python code that I was working with ran in 20 seperate threads (which would have been fine had I been able to run it on my own computer) however my Dreamhost account had a limit on concurrent threads that were allowed to run and i was greatly exceeding this. After changing the amount to 5, I finally was able to execute the script and build my database. It took about 15 minutes (!) to run the script through, and I was left with a complete, 4+GB database of baseball information.

This has been a huge headache (to say the damn least!) but now that I have gone through this process once it should be a lot easier from her on out if I need to grab new data (hopefully…).

I’m now working on understanding and parsing this enormous amount of data (the one table of events alone has over 8 million rows…) and make some sense of it. I’m close to having a workable XML format and I’ll post more about this in the future.

One more thing….

I found this link: http://www.wantlinux.net/2009/04/retrosheet-baseball-mysql-database-download/

which is basically the entire code already compiled into a database and downloadable On one hand this totally bums me out, but on the other hand it was a great experience having terminal/unix try to beat me down and coming out victorious! I am considering doing what this person has done and hosting the 2009 database on my site once it has become available, I’ll make a post if I decide to do so.

I’ve been doing a lot of thesis research for what seems like forever at this point. I’ve known from the start that I wanted to do something that I was really interested in both technically and conceptually (seems like an obvious thing but its very easy to get sidetracked by the thesis process….). The easy part of the process was identifying exactly what I wanted to explore, which is the subject of baseball. I have been interested in baseball since I was young, and to this day I am borderline obsessed with the sport (and the Phillies in particular ). I also knew I wanted to explore the emerging technology surrounding multitouch and tangible interfaces, so I thought that I could combine these two ideas and a concept would emerge. After a month or two of going back on forth on exactly what I wanted to do with baseball and multitouch (Data visualizations, augmented baseball cards, media center, etc) I finally had a revelation that I was trying to fit a concept into a box that I had voluntarily made. After freeing myself from the focus/necessity of designing exclusively for a multi-touch installation, which was severely limiting my thought process, I finally feel like I have come up with a concept that is

1. Totally unique
2. Interesting to me
3. Can incorporate multitouch but does not rely on it
4. Can be appreciated by fans of baseball
5. Allows people who hate baseball to get an abstract form of enjoyment out of the game

So what is my concept? My concept is to use existing historical (1950-present) baseball game data and investigate the rhythmic, cyclical nature of the game. Furthermore I want to show the factual, hard evidence that remains after a game has been played (box scores, statistics, etc) and from that attempt to recreate the emotional experience of a fan that existed at that moment in time.

My investigation will be materialized as an audio/visual system that will allow users to select a historical game and play it back in a condensed form. The events of the game will serve as individual beat tracks upon which audio samples can be assigned, either by individual event or entire tracks of similar events. The user will then be able to play this game back and see the action of the game in abstract form, both audibly and visually.

Some further ideas I have for this are splitting the game based on fan allegiance (home team, away team, neutral) and allowing the user to switch between these views during playbook. I’d also like the user to be able to physically “scratch” or scrub the playback, simulating a DJ scratching a record.

As far as the how/what of the actual project, I intend to develop the project in C++/openFrameworks which will allow me to develop across multiple platforms (Desktop, iPhone, Touch Table) while keeping the core code the same. I’m really excited to attempt to develop for multiple platforms, but at the same time this will add a large amount of complexity (and work!) to the project, so I need to get moving fast.

I still have a LOT of work to do, but I’m happy that I finally feel like I at least have a direction  and can start to develop prototypes and code non-stop. Hopefully I’ll have a first basic prototype up soon ( I’ve started already but I’ll put that in a separate post)

Anyone who actually reads this and have any feedback on the concept I’d love to hear it, please feel free to leave comments!

I recently ran into an issue that was a bit of a pain in the ass and I wanted to put it up here both to help anyone else out who runs into it and for my own reference.

I have been doing a lot of data mining/visualization recently which requires a large number of calls to several data apis. I am using PHP because I am familiar with it, I like it, and I can’t stand the structure of Python. One advantage of php is that you can execute it in the browser, which I normally take advantage of when I am working on API requests or data scraping. As my scripts have gotten more and more complex lately, I’ve quickly run into Internal Sever Error 500 messages which can only be fixed by limiting the amount of calls to make at a time. At first I thought this was just a limit of my server/php, but then I remembered how I recently was able to import a 4GB database into MySQL through the terminal with no problems after PhpMyAdmin was unable to handle anything near this. So I decided to try to run my script through the command line using SSH with dreamhost.

I attempted to execute the script, and then I got a bizarre error: “Fatal error: Call to undefined function: mysqli_connect()” This error never came up in the browser, yet it was coming up in terminal. After some quick searching I found out this error was attributed to not having PHP 5 installed on my server. This is super strange because PHP 5 is on my server according to dreamhost. I then did a version check on php using the -v parameter. Sure enough, version 4.4.9.

So what was the solution? I found a couple resources after playing around with phrases to search on google, and figured out that while php 5 WAS installed on my server, the command line space is different than the web space, so I had to explicitly point to PHP 5 in order to use it.

Running the following command led me to the path of PHP5 “whereis php” which returns the following path “/usr/local/php5/bin/php”.

So super short finish to a long explanation, use “/usr/local/php5/bin/php” instead of “php” to execute php scripts using version 5 on Dreamhost.