Eric just posted a review of what we got up to at Stamen in 2007. My second Thanksgiving at the end of November 2007 marked the end of my first year in San Francisco; 2 months after that it still feels new, fresh and exciting.
The variety of projects and clients at Stamen over the last year or so has been extremely satisfying. I probably won't get a chance to write them up thoroughly for myself, but I'm proud to have had a hand (large or small) in all the projects Eric wrote up (and several more besides!).
Pete from Trulia sent me and Eric a copy of Simon Foxell's Mapping London, and I've been poring over its pages for the last couple of days.
Visually, my favourite map is definitely the one entitled "Social and Functional Analysis", which has a beautiful cellular structure:
But lest I get too involved with the aesthetics or content of any one particular map, or the print quality of the book, or the sheer Londonness of the thing, there's also the "Fetish Map of London", whose description warns:
[Chris] Kenny draws attention to the way that maps can become fetishised objects, by creating links between Kongo fetish figures—with their nailed in 'pledges' or 'commitments'—and the pins in a wall map. His map of London is covered in such pins, tacks and nails to the point of rendering it almost unitelligible.
Normally that reference would be enough to keep me quiet, except I'm delighted to find that I'm mentioned in the book, on page 137 for my Travel Time Tube Map. Sadly the link is a little muddled (pointing people to del.icio.us instead of here) but I hope that can be corrected in future editions.
That aside, the book is of a very high quality and full of historical and contemporary mapping gems from all kinds of sources, including many that I can't find anywhere online (who says print is dead?). I've taken a few snaps of my favourites so you can get an idea of what's in store if you buy a copy, and I can definitely recommend that you do.
I'd been saving this title for a potential Pecha Kucha presentation, covering 20 different maps of London, but it doesn't look like happening any time soon. Meanwhile, maps of London are on my mind: watch this space for some new ones coming soon!
Testing for the existence of a property on an Object is simple in actionscript 3:
varobject:Object = { sub: "sub"};
trace("testing object properties");
if(object.sub){trace("CORRECT: object has a sub element");
}else{trace("WRONG: object has no sub element");
}if(object.nosub){trace("WRONG: object has a nosub element");
}else{trace("CORRECT: object has no nosub element");
}
This yields the correct output:
testing object properties
CORRECT: object has a sub element
CORRECT: object has no nosub element
However, the same thing isn't as intuitive with XML and E4X:
varxml:XML = <xml><sub>sub</sub></xml>;
trace("testing xml element");
// don't do this, it will give false positives!if(xml.sub){trace("CORRECT: xml has a sub element");
}else{trace("WRONG: xml has no sub element");
}// don't do this, it will give false positives!if(xml.nosub){trace("WRONG: xml has a nosub element");
}else{trace("CORRECT: xml has no nosub element");
}
This gives incorrect output:
testing xml element
CORRECT: xml has a sub element
WRONG: xml has a nosub element
The way to test reliably for the existence of xml elements is to check the length() method on the element:
trace("testing xml length()");
// this works to test for the existence of an elementif(xml.sub.length()){trace("CORRECT: xml has a sub element");
}else{trace("WRONG: xml has no sub element");
}// this also works to test for the non-existence of an elementif(xml.nosub.length()){trace("WRONG: xml has a nosub element");
}else{trace("CORRECT: xml has no nosub element");
}
This yields the correct output:
testing xml length()
CORRECT: xml has a sub element
CORRECT: xml has no nosub element
Even with the great speed improvements that actionscript 3 and Flash 9 offer over actionscript 2 and Flash 8, I've occasionally had the need to revisit a project and look for places to optimise.
Miscellaneous Tips
Here's a list of suggestions I recently made to Gabe, who has his own actionscripting notes, as he was revisiting an old project looking to reduce CPU usage.
look closely at what happens every frame (on enter frame) or inside for loops with 100s or 1000s of objects
creating objects is slow (using 'new') - if you do it inside of a loop consider if the object could be declared outside the loop and reused inside it
trig can be slow - lots of sin and cos inside of loops could be slowing things down (likewise pow, log etc)
redrawing everything (graphics.clear() etc...) is slow, but moving and resizing things (with width/height or scaleX/Y) is fast; just moving things cached as bitmap is fastest (but scaling them is slow)
creating new Textfields and TextFormats is slow, reusing them is faster
visible = false still gets drawn, removeChild is better
hinting types (with :int, :String etc.) and using compiled classes rather than dynamic objects to hold your data will be faster - this is again most important inside of loops
Tweaking the framerate
Simply dropping the framerate of an application might work as far as CPU usage goes too.
(Be careful with this though - if you're watching exclusively watching the CPU meters, and not the app, you might be optimising for the wrong audience!)
You can do that with the SWF metadata tag above your main app class in Flex Builder. The main bit is [SWF(frameRate='15')] but check the help file as you might have background colours and width/height in there already.
Memoization
You probably won't need it, but the trick used in Digg Arc (for calculating arc points before redrawing them) was to use what's called memoization — it helps with space-time trade-offs.
The idea is to remember the results of calling a function with certain arguments and only recalculate when the arguments change.
e.g. You might have a function that you're calling it a lot with the same values e.g. calculatePoints(1,2,3,4) that looks a bit like this:
function calculatePoints(a,b,c,d):Array{var points:Array = [];
/*
lots of heavy math with a,b,c,d and points
*/return points;
}
Instead of calculating every possible variation, you can create a hash of the common results:
privatevar results:Object = {};
function calculatePoints(a,b,c,d):Array{varkey:String = [a, b, c, d].join();
var points:Array = results[key] as Array;
if(points){return points;
}else{
points = [];
}/*
lots of heavy math with a,b,c,d and points
*/
results[key] = points;
return points;
}
Then if calculatePoints is called again with 1,2,3,4 you grab the answer from your results Object and return that instead of calculating it again. You probably want to set a limit on the number of things you cache though, so don't use this technique without thinking about that, and only consider this if your performance bottleneck is definitely one maths-heavy function!
I've been programming interactive maps visualisations using Flash and Actionscript 3 for almost a year now. Actionscript 3 code is what's behind the scenes of most the Flash work I've been involved with at Stamen so far: Trulia Hindsight, Digg Arc, Twitter Blocks, Modest Maps and more.
So in the spirit of writing about what's important to me (and what I'm actually doing) instead of only writing tangential asides, I'm going to start writing occasional notes on Actionscript 3 here. Hopefully the ideas explored will contribute to my upcoming workshop at Etech in San Diego in March.
I considered starting a new blog, but I've had to deal with my fractured blogging personae twicebefore already. Hopefully there'll be enough visualisation and project links to keep non-coders interested.
All kinds of people read this blog for all kinds of reasons, you might not care who I spent New Year with and that's OK with me. The actionscript posts will be tagged with as3, if that's all you're interested in you can subscribe to a feed of them here. (The same is true of the Processing posts, which have a feed here).
I'm reading Kurt Vonnegut's Breakfast of Champions at the moment. Our protagonist, Kilgore Trout, is hitch-hiking in a truck which has PYRAMID written on it in massive letters. He wonders about the implications:
"Trout wondered what a child who was just learning to read would make of a message like that. The child would suppose that the message was terrifically important, since somebody had gone to the trouble of writing it in letters so big."
I often wonder the same thing about blogging, twittering, linking on del.icio.us, open source programming, and so on. The things we do in public, on the web, aren't always that significant. And yet to a passing reader they must appear to be very important to us. It seems that often we don't get around to writing the important stuff down, precisely because it matters so much.
My new year's resolution is to take time to write the important stuff down, in MASSIVE LETTERS.
Like Mike, I spent New Year in a holiday cottage in Sonoma, enjoying the company of friends good and new. Aaron was a permanent fixture in the kitchen, tending to his cassoulet for three days in a quest for the mythical crust.
Being vegetarian, I didn't sample the dish itself (though that didn't stop some people!). I did manage to document the eating using the timelapse feature on my camera. It's not quite up to Cassidy's standards, but it's a nice memento of the evening and it was interesting to have an instant replay of dinner as soon as we were done!
In my post about the good people at Yahoo's design research group in September I suggested that some of their visualisations remind me of the movie War Games. I love the movie, but I continue to think that certain kinds of accidental visual resonance should be avoided. The 'incoming' visualisations by the good people at Dopplr have this problem too.
Today, Mike sent me the above image that Gem ffffound showing the devastation caused by the Oakland Hills firestorm in 1991. It's shocking, stunning and scary all at once to see so many homes ablaze like that. Mike pointed out that it looks like some of the work from our Trulia Hindsight project at Stamen.
Thankfully I think Mike was referring to the early prototypes I made in Processing using additive blending and a red-through-blue colour range. I've uploaded a movie of one of these prototypes to Vimeo so you can get an idea of what we're talking about:
The fact that certain parts of the movie looked like San Francisco was burning, or being bombed, was definitely a problem we had to avoid for the final piece. It's something I wouldn't want to be thinking about addicentally if I was trying to find out about real-estate in the area. What we want is to make something that can illustrate the effects of real devastation if we want it to, without emotionally swindling you if you just want to think about urban growth. That's why we knocked out the red and orange hues in the colour range, added a drop shadow and ditched the additive blending. Ultimately, it was more appropriate to show data on the map than in the map.
So, if you want to you can look up some of the areas of Oakland affected by the fires in 1991, such as this example, and spot the clear rebuilding activity in 1992. With luck, the animation will illustrate some of the devastation caused by the fires, without looking like a simulated disaster.
Over at Data Mining, Matthew Hurst takes exception to JC Herz's assessment of his map of the blogosphere as "(approx.) "completely useless"". Having recently engaged in several discussions about beautiful-but-useless visualizations I continue to insist that not everything has to be useful; perhaps Matthew doesn't intend for his map of the blogosphere to necessarily be useful in a traditional sense. That said, I have to admit that JC's blunt assessment is easy to agree with, and I had a similar reaction to the maps when I first saw them myself.
After the initial wave of early Google Maps mashups, some members of the mapping hacks community settled on the term "Red Dot Fever" (coined by Jo Walsh or Schuyler Erle, I think) to sum up the common patterns they were seeing. In a similar fashion (affectionate, but with a critical eye), my colleague Mike Migurski calls the prevailing network visualization technique the "Sticks and Rocks Diagram".
Matthew's images clearly have lots in common with the kinds of work catalogued meticulously at Visual Complexity. Sadly, I think a lot of the work there (some of my own included) is better at illustrating the problem than really informing us about the data that drives it. There's nothing intrinsically wrong with a popular approach to something, but when the results are so often misunderstood I bet we can all do better.
I've read a lot of research papers that would suggest that visualizing large complex networks is hard. Throwing the data at the screen and seeing what sticks is possibly a road to understanding, but I suspect it's an incredibly long one. Calling something "completely useless" doesn't drive our field forward or help open it up to new audiences, but the sentiment underpinning that reaction is something we could all work to understand better.
To me, red-dot-fever maps and sticks-and-rocks diagrams always look like works in progress.
. It's not quite up to 
