Since Mike simultaneously outed me and out-did me and linked to the Processing folder of the Modest Maps source at the same time, I thought I'd better post a version of the library I've been working on so that I can stop thinking about it for a while.
So:
Modest Maps is a BSD-licensed display and interaction library for tile-based maps in Flash (ActionScript 2.0 and ActionScript 3.0) and Python...
Ben Tesch overlays the timeline of technology adoption and the timeline of cool and concludes that the clothes dryer was responsible for the rise of soul music. I like it.
I'm reminded of my reaction to the wall of statistics about the world before and after Bill Clinton's presidency, at his library in Little Rock, Arkansas. We're told that among other things the national debt, the number nuclear warheads and world poverty all went down, but that AIDS increased. I'm led to believe that nuclear warheads prevent AIDS, or possibly that AIDS prevents nuclear warheads. Clearly.
I just came across a blog post from last May by Rolf Kersten about your CO2 footprint when using the internet. I was particularly intrigued by his estimate of the amount of carbon produced by Google at 6.8 grams per search.
A while ago the 'news' went around that Google could supposedly cut the energy consumption of millions of monitors by changing their website background to black. It turned out only to be true for old CRT monitors, and a bit silly all in all. But I sometimes do a couple of hundred Google searches a day, nevermind the other web-based services I use that are off consuming power on my behalf, and Rolf's post reminded me about an idea I had that I think could really work.
What if Google replaced the "I'm Feeling Lucky" button with one that said "I'm Feeling Patient" instead, and then waited for a convenient moment to perform my search instead of performing it instantly? Would they (could they) reduce the number of servers needed for search if they did that? And will there ever be a point where increased efficiency doesn't get used up by doing more instead of being used as an opportunity to cut back?
I know Gavin Bell has been thinking about these ideas too, wondering how to measure the energy consumption of web services in general, including the effects of mod_gzip on the power consumption of nosy routers that inspect packets at every hop. I wonder about the environmental cost of indexing all those mailing lists I leave archived and unread in my GMail.
Clearly some of these things pale into insignificance when compared with the environmental impact of air travel, long commutes, badly insulated homes, old power grids, etc. but I wonder if they start to be worth thinking about at a company operating on Google's scale.
One of the sad things about using the OpenGL rendering option in Processing is the lack of control over line weights, caps and joins. This week I allowed myself to get distracted by this issue for a little bit too long, but I did succeed in solving it, at last:
I've put some code about line caps and joins in Processing & OpenGL up on Processing Hacks in case it's something that bothers you too. I've not tested it extensively so I'd welcome bug fixes and suggestions there, or in the comments here. One thing I'm interested in doing next is extending (or reimplementing) BasicStroke to generate shapes for thick polylines with varying line thickness. If that's something you've done before, please let me know.
I'm using Java's BasicStroke to generate the path outlines, and GLU's tesselators to generate a mesh that will fill correctly in OpenGL. I "borrowed" the code for the latter from Ben Fry's PGraphicsOpenGL font rendering – thanks Ben!
As I mentioned in my previous post, we were working with Geraldine Sarmiento on the ArtNano site, and she came up with the pixellised imagery you see throughout.
Towards the end of the project, I needed a few more of the pixelly images at short notice, to illustrate the essays and about pages on the site. Rather than bother Geraldine, I reached for Processing to see if I could match the look of the homepage imagery that she had created.
I came up with an applet that used a bit of blurring, a bit of distance fall-off, and a bit of perlin noise to create the effect that we were looking for (decorative, obscured, but related to the overall site). Here's an example of the imagery created from a picture of Scott Snibbe's Three Drops that we used on the page for Jennifer Frazier's essay:
You can see the full applet and source code here, and I think it's a good example of how a generative solution to design elements can keep a project flexible right up until launch (and beyond).
I recently finished helping out on the back-end of the NISE Network's ArtNano site for San Francisco's Exploratorium. Working on a 'straight-up' website is a rare departure for us at Stamen, but we're big fans of the Exploratorium and were delighted at the opportunity to work with them.
The ArtNano site features contributions from several artists tasked with exploring the nanoscale. My favourites are Semiconductor's gorgeously glitchy 200 Nanowebbers video, Scott Snibbe's multi-scale Three Drops installation and Santiago Ortiz's Time Spiral. Also featured are artworks by Eric Heller, Victoria Vesna and Stephanie Maxwell.
If you're interested in that sort of thing, read the full version of this post for some notes on using the Wordpress blog platform as a CMS for a small website project like ArtNano.
I've been thinking recently about data visualisation approaches. One that I'm very fond of in the early stage of a project is to figure out a way to arrange the whole thing on screen – or a representative sample of it – and figure out what meaningful segments you can mark on top of it.
That was the rationale behind our Trulia Hindsight movies (show something about everything) and our charts of a day of activity on Digg. It's definitely an approach I've found easiest in Processing, although using it recently I've missed the instant mouse-driven interactivity of Flash or HTML.
My colleague Shawn just posted a visualisation he made to help debug a visualisation he's working on at the moment:
Shawn's chart is basically a simple scatter plot of cabspotting data points (by cab ID and time), except that he's also overlaid some of the connections between the data to show how far back and forward he has to look to accurately predict a cab's location. And the whole thing moves beautifully, showing up bad data and highlighting good data as it goes. Hopefully we'll get a video up soon.
In the meantime, be sure to read Shawn's description and keep an eye out for the final debugged visualization in the MOMA soon!
One of those tedious admin posts.
I was tired of the tiny green-blue text and general busy-ness of my previous theme, so I've stripped everything back today and gone with Derek Powazek's De-Po Skinny.
Doubtless I'll want to mess with the look of it in the future, but this will definitely work for now. Flickr photos at the top, too!
(This post is part of the series I threatened to write about actionscript 3.)
For the mySociety travel time maps I wanted to have user-defined labels that looked pretty much like the map styles in the OpenStreetMap base maps we were using, like this one:
It turns out Flash doesn't have a way to draw the outlines of text easily, nor does it have a stroke filter like Photoshop. I tried a few different solutions that didn't work out, including a combinations of ConvolutionFilters (too hard to get right), GlowFilters (too blurry) and stacks of offset BevelFilters (nasty looking edges). Since the only thing in Flash that has the same quality antialiasing as the text does is, well, more text, that's what I ended up using. It looks like this:
I've included a sample SWF and pulled out the relevant AS3 code (for Flex Builder) in the full post, below.
O'Reilly Radar has the scoop on the most recent thing I've finished working on at Stamen. Interactive travel time and house price maps for London. Go play, and read what mySociety have to say, including the ones for BBC TV Centre and the Olympic Stadium site. Then come back and read this full post if you want the background info...
I've had a slow debate running with mySociety's Tom Steinberg since Euro FOO '06 about the best way to present travel time mapping, after we compared notes from my travel time tube map for London and the work Chris Lightfoot did on mapping transport travel times in the UK as a whole.
It seemed like the best way to settle this debate would be for mySociety and Stamen to work together updating their maps and see if we could get the best of both worlds. MySociety had comprehensive travel time data that they, uh, acquired from Transport Direct and Transport for London's journey planners. They also had an ace up their sleeves with the purchase of house price data for London from the UK's land registry. So far the volunteer-led map design had come up with strong proofs of concept, but a consistent set of presentation material was needed to make a compelling argument about the usefulness of these maps in the general case.
Our initial attempts to update the map began with a couple of days of Tom Steinberg and I alternately hunched over Photoshop and poring over the Edward Tufte books (passages recommended by the man himself) and looking for an appropriate colour gradient to represent travel contours (I didn't know about this resource at the time). All the while Francis Irving was back in the UK working on the heavy lifting behind the project, getting the data gathering and overlay rendering up to speed. We tried a few different things, but actually I thought that the palette Tom had worked on with mySociety volunteer Richard Pope was pretty good, and that's the one we used for these static contour maps. (Early mySociety results on the left, updated one in the middle, my final one on the right).
These maps got much less satisfying with the addition of the house price zones, however. That was what Tom had originally asked us to help with; a thorny problem that needed a new approach. After poking around with the various two and three colour overlays with my colleague Mike it became clear that the combinations of masks and outlines were immensely confusing to work with. In addition to this problem, Tom and Francis at mySociety wanted to be flexible about the most appropriate configuration of house prices and travel times to tell a convincing story about the data later. My initial plan had been to set up a workflow in Photoshop to quickly produce the image files they needed. As the complexity of that task became clear, it got less and less attractive.
I had been resisting reaching for a programming solution to the design and cartography problem, but it became clear the manual processing was going to be onerous and difficult to keep consistent. So I asked Francis to provide me with a house price overlay that displayed small price increments using a grey-scale gradient, instead of solid colours between large price bands. Then whilst Tom Steinberg was out at a meeting I cooked up a quick slider experiment in flash to see if the approach had merit, and the difference was astounding. From that moment I was hooked on giving everyone access to what we were playing with, even if it meant working on it over Stamen's christmas break (time/budget constraints had already excluded building a slippy Google-Maps-style map, for example).
Here's a picture of what the house price masks looked like at that point, two colour bands on the left (constrained, harsh), and the new small price increment one (cloudy, beautiful) on the right:
The next task focused on getting a consistent set of base maps for the work, rather than using a hotch-potch of Ordnance Survey maps. The OS maps are world-class for accuracy, of course, but the cartography changes radically at each different scale and the maps aren't designed for on-screen viewing, let alone for data presentation. Naturally (given my history with the project) we turned to OpenStreetMap as a data source and asked Nick Black from ZXV to help produce maps that would be a drop-in replacement for the OS maps mySociety had been using so far.
One thing that Nick's involvement got us was separate layers of data (above), which let us get more fancy with the presentation later on, and keep the labels on top of the data. Of course flexibility giveth, and flexibility taketh away: later on, it took me a while to figure out how to get the text rendering in Flash to match the mapnik style Nick was providing us (more on that later).
So, armed with new map layers, gradient overlays and masks for travel time and house prices, I set about creating a Flash piece that Tom and Francis could configure for themselves (and they did). They're tough cookies to please, of course, and getting something ready that we were all happy with (on volunteer time, across an 8 hour time difference) took patience on everyone's part. Looking at the finished pieces I hope you'll agree that it's worth it, and if you happen to be a transport routing expert sitting on a system that could help produce these maps for everyone, working around the issues Francis identified, then I hope you get in touch!
I have to leave this post here for now, but I hope to go into more detail about the Flash code (which is over here, under a BSD license) in a future post.
© Random Etc.. Powered by WordPress using the DePo Skinny Theme.
