After spending the last month in java land in a perpetual state of frustration, I needed a break, and went back to the blissful world of Flex.  I even toyed around with JavaFX.  The only reason I can see that taking off, is because of the multitude of open source Java libraries available.  Anyway, this isn't about Java.

 I needed to have a confidence booster and have a little fun, so I decided to take on a little project.  I am a big movie fan, and sometimes I like to find out if an actor (I'm using actor as a gender neutral for both men and women) as acted any movies with another actor.  There wasn't a real easy way to do this on IMDB so I thought why not create my own.  Unfortunately, IMDB does not have an API to pull movie and actor names from, but I did find the free movie database.  It's free for my purposes at least, since this was just a pet project.  To display the links and movies, I used the FLARE library's force directed layout.  I suppose one of the other layouts would also work.  Because of the ease of use of Flare and FLEX I was up and running in a day and half, and most of that half was tweaking to get the different things to work right.  I know the user interface is a bit crappy, but I was mostly interested in the back end and having something work.

Currently under "beta", and perhaps perpetually so.  Here are some quick instructions.

You can search for just one actor to see their movies by just entering the name in the first box and clicking find.  You can search for both actors and find their links and all their movies, or check the checkbox to just see the links.  Double click on the box to get more info about the movie, and double click on the actor to get more info about the actor.  Hover over the items to find the name of the movie or actor.  You can hover over the link to find out what job they had (actor, producer, etc...), but this doesn't list all the jobs, hence why this is still under beta.  Pause and Resume buttons will pause the layout from moving the whole time.

The app is available here, and the source code is available here.  You will need your own API key though.

James Fee brought the Google Visualization API and Google Fusion API to my attention, so I went and checked them out.  The video on the Google Fusion intro page is interesting.  It is all about putting the power to display information in anybody's hand.  Which I guess is a noble aim...  Then I looked the Visualization API and immediately looked at the mapping examples, here and here.  There area acouple of things wrong with these maps.  One, for a visualization of this kind, shouldn't they have used a better projection.  We are stuck, yet again, with Mercator.  In this context it is completely inappropriate, yada yada yada.  Second, they aren't really different kinds of mapping, but are just a choropleth map.  I'm not even sure what the maps are supposed to be mapping.  I presume generic information..."popularity???"  Choropleths are meant to map derived data.  So it shouldn't be popularity, but maybe popularity per 1000.  The intensity map just shows population.  It is the same problem, like if they were to map deaths.  The population and death map would theoretically look exactly the same.  Anyway, this is sort of a cost-benefit analysis.  Does the cost of putting the simplicity of creating the visualizations in the hands of everyday internet users (the ensuing creation of bad and ineffective maps) outweight the benefits of giving the power to create and visualize information?  I think that google could have provided a few fixes that do not impact the user in anyway to make their visualizations more appropriate.

You might say that the designers and journalists and whoever creates infographics for print will still (hopefully) create approrpiate visualizations.  But, a lot of people are getting their info from crap blogs like mine rather than reliable sources.  Anyway, this is just the same debate over and over again about the "cult of the amateur" and whether it is good or bad.

 There was another thing that I found interesting in Fee's post.  He described the google maps api's introduction of queries, comparing them to other GIS related queries - "Now of course this isn’t paleo-type spatial queries, just simple stuff that solve 80% of all queries you’d need to complete."  To me paleo refers to very old, or even primitive.  I find it confusing to refer to GIS techniques as paleo, when the mapping and spatial parts of the Web 2.0 (neogeography) are much simpler, and less advanced than the older stuff.  Anyway, I'm not going to debate the appropriateness of the terms paleogeography and neogeography because that would just get me stuck in the mud.  Plus I like the term Neogeography, but maybe my head is just in the cloud.  Ooops, should have put a pun warning in front of that.

  For those that don't know, I'm an American living temporarily in Australia.  Back in the US I wasn't much of a sports watcher, always finding something else to do on Sunday afternoons.  Although, I did watch the occasional football (American football that is) on tv.  Since being in Australia, I found I am taking more of an interest in watching some sports.  I've come to like learning and watching Cricket and Australian Football.  And have just started on Aussie rules rugby.  The seasons have ended, though.  I also have taken more of interest in the NFL, and follow the season regularly.  Being from Colorado, I naturally am drawn to the Broncos.  They had a pretty exciting sunday game (9-oct-2009), which we caught this Monday AM.  Unfortunately, unlike the rest of Australia (at least the major cities), Darwin does not get the game.  We watched NFL's game center application, and listened online to KOA.  Now to the actual point of this entry, as fascinated as my sports watching habits are.  If you have not seen the Game Center app you should really check it out, even if you are not a football fan.  Essentially it is an spatio-temporal infovis of the game, where time is along the vertical axis and space (distance) is on the horizontal axis.  As the time of the game progresses, the bars move vertically, past game plays fading out as they become further from the bottom.  It is a really well made application and kept us up-to-date on the plays.  Ironically it was the radio broadcast that was delayed, and not the app.  There are two views as well, side and top.  The side view further classifies the bars into passes and runs.  The length of the bar is the distance of the completed pass, run length, or attempted pass.  Anyway, it is worth checking out, especially if you are a geonerd like myself and instead of focusing on the game you drool over the infographic.

Side View 

Top View 

I have a tendency to jump around from topic to topic in an inconsistant way, and I guess this week/month I'm on a visualizations kick.  I look at a blog called Urban Cartography from time to time as they have interesting infographics and data visualizations posted there.  They had this graphic on it today.   On a side note Urban Cartography doesn't always provide a link to the original, which I think is really silly.  Anyway, this time the graphic had the address written on it and so I was able to read the author's original description.  All this graphic really shows is population density, or urban centres, McDonalds naturally being more accessible where there are more people.  The author notes this in the description.  I think this actually ties in somewhat with the "cartographic malpractice" where Stephen Few discusses the potential misuse of techniques not appropriate to the data.  I don't know if the McDonalds graphic is necessarily a misuse of a technique, all he did is calculate the distance between McDonalds.  This is a fairly simple process using ArcGIS Spatial Analyst, what the author doesn't show (given the lack of a legend) is the color scale.  You could easily reclassify the underlying raster layer to make the McDonalds appear more dense or less dense.  However, the point I want to make is something I've been seeing more and more.  A thing to be aware of when doing any geographic visualization is how the underlying data is going to affect it.  In this case, the obvious factor is population density.  Perhaps a contiguous area cartogram of Mcdonalds per 1000 people (county?) might be more interesting, or just end up showing the same pattern.

This came up in another blog about Mapping Oxford Crime data.  If you scan through the comments, you can see someone also took issue with whether or not the underlying data was accounted for - again the population.  This becomes a general criticism of Web 2.0 and the so-called democritization of the web and crowd sourcing I think.  It is a common criticism that we hear over and over again coming from "experts" - amateurs shouldn't be doing these things (I don't necessarily place myself in either category).  I do lots of things I probably shouldn't - programming for one.  Of course I'm not trying to sell any programs, because no one would buy them.  It is usually pretty obvious when an amateur has created something versus a professional.  This becomes more interesting in the world of the Web 2.0 where how something was created (say by the BBC with the crime map) is generally not divulged.  That's different than peer-reviewed journals where everything is scrutinized to the last detail.  But in journals, the writers aren't interested in telling a story.  The two examples in this entry, though both are using spatial information and geovisulizations to tell a story, are from different sources and purposes.  One is for the amusement of the author, the other is meant to inform a population with the backing of a powerful news organization.  Perhaps, then, the later should be more open with how they created their story...Of course, it is much easier to find faults than to deliver praise.

This article came to my attention via the always interesting Cartotalk.  It is a discussion of Bis²'s new software and new information visualisation technique.  While, I wouldn't really want to be on the receiving end of Few's criticism, I can't help but agreeing with the points made by few.  Initially, I was sceptical of the title of the article, and have soon numerous graphic designers bash maps as a infographic tool, so I was expecting this.  I for one am completely biased and think maps are fantastic, but do understand that the best tool should be used for the job not necessarily what you want for the job (surprisingly a simple line chart wins a lot of the time).  However, after reading the article, I found it to be a very reasonable assessment of the techniques used.  I am sympathetic to trying to create something new, but this technique definitely does not seem appropriate to the data.  I can't help but wondering though, maybe by keeping the data separate from each other as the data matrix was done, allowing the overlap between categories might help explore relationships between them, for example there might be a trend where clothing items dip together during one quarter where other categories do not.  I don't think this visualization technique would actually work to well for exploring these relationships, since it would be quite easy to just reorder the items.  There are probably better methods for this (data mining?).  I do think you can probably control for the issues Few raises a bit.  Presumably, Bis² uses some sort of interpolation method (IDW, krigging) to create the continuous surface, or a density (kernel density) method.  Both of these methods use either a search radius or bandwidth in order to determine the influence of data points on each other.  I refer you to Spatial Analysis Online if you want a more detailed explanation of either technique.  The search radius or bandwidth may be fixed or variable (e.g. a minimum of 3 points used).  This is a huge presumption on my part, because I don't know how the values are actually calculated but given the creator is a cartographer by trade...we can make a fairly safe assumption.  So by choosing a search radius or bandwidth that maintains the integrity of the category, or category and date (i.e. the data point only influences itself), then the influence of other categories might be reduced while still maintaining the ability to identify hotspots.  But this is approaching just a simple matrix approach demonstrated by Few.  If you create a continuous surface for individual categories you can see the relationship between months, which I don't necessarily think should be treated as discrete units as shown in Few's graphics..  But this is really just a mental exercise.

I don't really like the spiral graphic one.  Probably because I found it confusing.  I do however like the attempt to use the donut to represent time.  I find it interesting that the matrix graph separates January and December, where a donut would connect them.  Having worked at Best Buy through November, December, and January, I (intuitively at least) know how linked those months are.

Just some thoughts.  Kudos to Bis² on their efforts and hard work, though.

A friendly note to the reader:  I spell using an 's' or 'z' interchangeably at my whim, laughing in the face of consistency :).