We’re working on putting together a few election maps and and graphs at Axis Maps, and above is one that we’ve come up with so far.

It’s a standard red-blue map indicating the winner of each county in the lower 48 states, where the transparency indicates the population of a county. The many counties with low population fade into the background, diminishing their visual prominence. This is meant to accomplish something similar to a cartogram, where sizes are distorted to show the actual distribution of votes. It’s step one of trying out alternatives to the cartograms that I complained about earlier this week. I won’t claim yet that it’s better… just different.

Drop us a line over here: ColorBrewer 2.0

We’ve once again arrived at that special time of (every fourth) year when the internet abounds with maps, charts, and other graphics attempting to depict and analyze every geographic and demographic angle of the US presidential election. I am happy for these, both in the perspectives they provide on the election and in the demonstration of interesting visualization methods.

But as a cartographer in the eternal quest for the Perfect Map, I find myself complaining about some map and graphics. In particular, I take exception to this:

For anyone who doesn’t know, the above is a cartogram (’bout time I wrote about that which my site is named after!) of the United States, in this case a map by Michael Gastner, Cosma Shalizi, and Mark Newman showing the results of the 2004 presidential election by county (we’ll soon be seeing one for 2008). A cartogram is a map that does not strive for geographic accuracy, but rather in which the area of units actually represents some value. In the election map, each county’s size represents its number of voters. The point of the map is to show that while a geographic red-blue election map would show an apparent vastness of Republican votes, those “red” areas actually account for about the same number of votes as the tiny “blue” areas. (The message is further conveyed by coloring counties along a red-blue continuum to show the actual balance of votes rather than simply coloring by the winner, something first seen in Robert Vanderbei’s election maps.)

I’ve written several drafts of many paragraphs to try to explain my opinion, but really, who has time to read all my ranting? Short version: apologies to Drs. Gastner and Newman, but as a cartographer interested in clear and effective design, I really believe that cartograms generated from their method are severely over-hyped and far more popular than they should be. Consider the election map (or any number of examples)…

• Ugly! All that puckering and bloating… I wouldn’t want to share an elevator with that America.
• Topology preservation at the expense of shape: even if I know what a county looks like on a normal map, I’m going to have a hard time identifying it here.
• On shape, still: curvy shape distortions are harder to recognize than simplified polygonal shapes.
• The overall distortions leave me gleaning only about five things from this map: east, west, Florida, Michigan, and that there is roughly the same amount of blue as red. Yes, I know that last one is the whole point, but if I can barely discern the geography, why bother to use a map? There are lots of cool visualization works that deserve attention too.
• Fast and easy cartograms (including this particular map) are not useless, and the work by Gastner and Newman is an important contribution, but there are under-appreciated careful designs out there. Consider the excellent cartograms from Mapping Worlds:

The bottom line is that many—perhaps even most—cartograms are essentially used for shock value, for the “holy crap, that’s a different perspective!” response, which is exactly what they get. Too frequently they can’t stand as maps on their own. I think the election cartogram is only of use when it’s next to an undistorted map. The best maps and graphics are those that tell their story clearly and elegantly, not those that simply evoke an emotional response. There are a million good reasons why I’m wrong to complain, but rather than going on and on in an attempt to counter them I will simply acknowledge that they exist and expound later if necessary.

“Put your money where your mouth is, jackass!”
Oh, actually that’s a pretty important reason I’m wrong to complain. Okay, I promise I will attempt to come up an alternative visualization of the same information as that election cartogram, as soon as I figure out where people find such detailed election data so quickly. (And, as I stressed “careful design,” it’s not going to be instant.) I’ll also keep an eye out in the coming days for maps and graphics that I think are more effective.

Having deleted most of what I previously wrote for this post, I wasn’t left with a good place to bring it up, but I must, as I seem to do in nearly every alternate post, refer to the work of my mortal enemy Zachary Johnson, who wrote his master’s thesis on cartogram designs in political maps. (He should be writing about this stuff. Maybe someday he’ll at least finally write about his findings. Eh, Joncy?) At the University of Wisconsin-Madison, specifically in room 412 Science Hall, we did not take cartographic research seriously if it could not be depicted by a cube. As such, Zach defined a cartogram typology (Cartogram³) by three characteristics: shape preservation, topology preservation (the preservation of boundaries and connectivity), and density equalization (essentially, how accurately area corresponds to value). No cartogram can be perfect in all three, and in fact most compromise all three to some degree. Zach tested several designs, each making different sacrifices, in political map-reading tasks. Note that I have bitched about shape preservation versus topology preservation. His research backs me up in some respects, but not in others. But I’m not in academia anymore; I don’t need “research” to know that I’m right!

Not wanting to simply write duplicate content here, I thought I’d say a bit about what is perhaps novel about the project, which is visualizing word frequency on a map. Word clouds or tag clouds are trendy these days, especially given a tool like Wordle that can produce a damn sexy word cloud. They’re something of a simple and elegant visualization, combining data and label in one, and they’re pretty effective. (Their drawbacks should be noted, however. See, for example, the caveats at the bottom of this Many Eyes page or Zachary “Hollywood” Johnson’s experiments with tag scaling to address a potential overemphasis on long words.)

So tag clouds are hip. I thought it would be interesting to find a way to use them in a map. Easy enough: if a collection of words is associated with a location, slap it on a map. That’s the basic idea behind the campaign speeches maps. We can see how campaign word use varies across the region. Beyond that, though, I wanted to see how the patterns look at different scales by aggregating neighboring word clouds.

Aggregation is a basic and necessary cartographic generalization procedure wherein multiple point symbols are replaced with with a single areal symbol to represent them*. It’s a matter of scale; if you’ve got too many symbols close together to discern them at a small scale, you’re better off combining them. I’m a fan of the way EveryBlock maps have such scale-dependent symbolization. If there are too many points to show individually, they are combined into a larger symbol with a number on it. (It effectively becomes a proportional symbol map.) I wanted to do something similar with word clouds: if there were too many to fit in a given area, combine them into a single cloud encompassing words from all the individual clouds.

The spatial perspective it gives, then, is patterns from broad regions down to a local level. For example, zooming from the national level into my home state of Ohio on the campaign speech map, we see the word patterns for the general northeastern quadrant of the country, then the Midwest, then individual cities in Ohio.

As this project became neglected, so did my interest in learning about better aggregation algorithms. Mine was pretty basic and probably inefficient. It essentially draws all the tag clouds, finds the closest pair, checks if they overlap, if so combines them into one at the average location, and then repeats the process until no more clouds overlap. Each cloud shows only as many as 20 words, and half of them are from each candidate where possible. It’s a comparison of two texts, but not in a word-for-word way that is sometimes seen, for instance here at Many Eyes.

Anyway, I think these scale-dependent tag clouds are an interesting idea to pursue further, and I’m not sure if anyone’s done it before. Other examples would be most welcome!

* Note that the technical definition of aggregation involves “increased dimensionality” (to quote my friend Robert “The Hammer” Roth in his work on the ScaleMaster project at Penn State), e.g. from points to polygon. With my word clouds it’s more like polygon-to-polygon, but not a larger polygon, which would be closer to amalgamation. I’m not sure what a generalization expert would actually call this, as it’s sort of a content operation manifested in an geometry operation.

I wish to call attention to the fact that my humble little company Axis Maps has launched a new blog. This blog, I must stress, does not exist merely to promote ourselves, but rather to talk about practical cartography. So please stay tuned to it while our Ph.D. holders Mark Harrower and Ben Sheesley drop cartographic knowledge bombs on your face, and while Dave Heyman and I keep it real.

We begin with a single post by Mark Harrower, I’m not here to make your data look pretty. Expect more soon, though! When they’re not too inane, I’ll copy my posts from here to the Axis Maps blog.

So I have a single map that I need to show at several different scales in an interactive fashion. It’s got to be a pretty big image to look decent when I zoom in, so that means a large file and a long download. But I only need to see the scaled-down map when it first loads. I don’t want to wait for a big image to download when I just need a little one to start! The hip (or some might say “smart”) way to deal with such a problem is to break the image into tiles and load said tiles on the fly as needed. But this is a simple, one-off creation, and I’m too lazy, too stupid, or too pressed for time to figure out tiling.

That was my situation recently. And I thought to myself hey, the world needs more backward-looking individuals, and patted myself on the back for avoiding learning and taking the easy way out: use Flash’s timeline to fake a progressive download!

The solution takes advantage of the way a Flash movie loads: rather than waiting for the whole file to load, individual timeline frames appear as soon as their content has loaded. It’s something I first exploited for my CincinnatiRoads map, embedding videos right in the timeline to allow easier playback manipulation but also have a progressive download. Flash, from what I can tell, supports progressive JPEGs but does not display them progressively.

So, for my map:

1. Save a scaled-down image that is a manageable file size.
2. Divide the full-res image into tiles, also of manageable file sizes (mine is 16 tiles).
3. In Flash, plop the small image from (1) on the stage.
4. Then place the full-res tiles on top of the small image, scaling them down (in Flash!) to match the size of the small image. (When they’re blown back up by zooming in, they’ll look fine.) Place each tile in its own layer, and move each to its own frame. My timeline looks like this:

That’s all. No code (except a stop() at the end), very little thinking, and maybe a half hour spent. I then drop it into my map interface. When the movie loads, it should show up as soon as the small image has finished loading, and then the high-res tiles will come in one by one. Hopefully you noticed that the simple demo map at the top of this post appeared without too much delay even though the full image is a few thousand pixels across and the file is a couple of megabytes (and if files of that size load quickly anyway because you have an amazing internet connection, shut up and I hate you).

Caveats:

• Yes, I know this is not much different from having only two images: one small and one large. But I figured it’s better to see pieces of the high-res image appear as they load rather than nothing… nothing… nothing… EVERYTHING. And it almost looks like there is some kind of actual tiling going on!
• This was helpful for displaying an image that takes too long to download but is not too large to handle. It is not a solution for loading an absolutely huge image. That’s going to bog down the system in the end.

After a summer of long hours and occasional vagarancy, I’m happy to report that GeoCommons Maker! has launched today.  FortiusOne’s CEO Sean Gorman nicely sums up what Maker (I’m going to go ahead and drop the exclamation point henceforth) is all about:

Data that was once the sole providence of GIS professionals can now be mapped by anyone. Not only can they access the data but be guided through a process of creating a cartographically and statistically accurate map.

My esteemed colleagues and I at Axis Maps teamed up with FortiusOne to build Maker, sharing the goal of bringing good cartography to a vast collection of geographic data.

Maker is integrated with the existing GeoCommons service Finder, where users can access thousands of geographic data sets in different formats and contribute their own data. Now with Maker, users can create and share some of the slightly sophisticated cartographic visualizations that were once reserved for expensive desktop GIS applications. We hope that this will encourage appreciation of cartographic design in web maps, or, to quote the FortiusOne blog’s former name, to “move past push pins.” For a good summary of the highlights and goals of Maker, check out Andrew Turner’s announcement.

Our role at Axis Maps was essentially to build the Flash front end for Maker, bringing our collected expertise in cartography to the discussions with the GeoCommons team. A good map in 5 minutes was the goal, so we tried to reduce the map-making process to a short series of decisions that produce a well-designed map allowing basic analysis that is insightful and appropriate to the data. To that end we have the “Map Brewer” that greets you in Maker when you load a data layer.

A map in four clicks if you like. This is a slight variation on the concept of a tool put forth by Professor Cindy Brewer with our own Professor Mark Harrower in ColorBrewer. Professor Brewer has described what she sees as the “brewer” concept (see #8 here). In short, a brewer is a tool that guides a mapmaker through particular cartographic design decisions, presenting reasonable options and the information necessary to critically evaluate those options. It does not make the decisions for you; it helps you make decisions. We could have tried to have the system determine the best cartographic design for the data it’s given, but we think that guiding the user through a few decisions will lead to far better maps. The Map Brewer is the salient example of the principles we’ve tried to uphold throughout the interface and workflow: allowing decent design flexibility while keeping decisions simple and encouraging effective design.

Meanwhile, something I worked with a lot was actually rendering the data on the map. The Flash application builds on Modest Maps to display geometry (retrieved from the extensive back end), making map navigation easy and providing a variety of base map choices. There is continuing work to make the rendering methods more extensible by streamlining the integration with Modest Maps and allowing more flexibility of data formats. I must stress that the powerful back end to all this reflects a lot of hard work and ingenuity at FortiusOne, and they continue to work to make these data and maps as fast and easy to access and share as possible. It’s been a valuable experience to work with them and see everything they’ve put into GeoCommons.

It’ll be exciting to see how Maker evolves and expands. For some time now I’ve perceived a geoweb community emphasis on data, data, data, and I hope that Maker can cater to that while also introducing a stronger focus on presentation.

So please pardon the kinks that are still being worked out, and enjoy making some cool maps! Here’s my fist publicly shared map, a frivolous one of course: “Freshmen are Criminals”

I think I like the idea as a way to show the whole but focus on one section (ostensibly more important for tourists), but then I didn’t attempt to get around anywhere in that western section, so maybe it would actually turn out to be frustrating. San Francisco, it seems, is probably a rare city for which it’s easy to pull this off: it ends abruptly at water on three sides and has a street grid largely aligned to the cardinal directions, meaning the map can be squashed horizontally while preserving most street angles. Are there other maps like this out there?

A PDF of the map is available at Bay City Guide’s site.

• I’ve got 1,105 out of 3,141. I’m thinking about picking up three more in Pennsylvania tomorrow.
• It counts if I was on the ground, either on foot or in a terrestrial vehicle.
• Even so, airport layovers are cheap, but I don’t lose sleep because I only have one or two that are only airport layovers.
• I said been to, not any subjective word like visited. So shut up; it presents facts.
• Besides, a big part of visiting a place for me (as one who appreciates geography) is simply looking around at the landscape anyway, so I would count drive-throughs as visits regardless.

This was created at http://counties.visitedmap.com. If you are nerd enough and have a freakish memory of the exact routes you’ve traveled in your life, give it a go!

Lately some of my Flash mapping colleagues and I have come to rely on transforming geographic data—say, shapefiles—into various map projections on the client side via the ActionScript vector drawing methods. (See, for example, a post by my friend Zachary Johnson with an old-as-the-hills demo. And don’t you worry: we’ll be releasing something way, way cooler eventually.) But as cartographers know, vector data is just one side of things. What about raster data?

These days Flash allows good pixel-level manipulation of raster images with the BitmapData class. As a cartographer, I thought I’d try a little experiment in map projections.

The goal: Convert an “unprojected” (plate carrée) world map map to a Winkel Tripel projection. I used an image from Wikipedia as a starting point.

This is what we want to end up with:

Not terribly long ago for a mapping project I wasted a ridiculous amount of time on someone else’s dime attempting to reproject a raster map using the ActionScript DisplacementMapFilter class. If you don’t know, what the DisplacementMapFilter does is use the colors on a displacement map image (a BitmapData object) to determine displacement of pixels on another object. One color channel determines the x displacement and another the y displacement, both relative to the midpoint in the range of values for that color (i.e., 127 out of 255). For example, if we use the red channel for x and the blue channel for y, and a pixel in the displacement map has a red value of 255 and a blue value of 0, the corresponding pixel in the target object will be displaced positively 100% in the x direction and negatively 100% in the y direction. The actual number of pixels that 100% represents depends on a specified scale factor.

For a map projection, then, what we have to do is go through the unprojected source image pixel by pixel and determine how far each pixel has to be displaced on both axes by plugging the latitude and longitude values for the pixel into a projection formula. Using red for the x displacement and blue for the y displacement, below is the displacement map I generated for turning the unprojected map into Winkel Tripel.

I then applied that to the source image. The result? Yuck.

It’s probably possible to mess with this method and produce better results. As previously suggested, though, I’ve already spent too much time doing that without coming up with anything decent. In my experience there are three drawbacks to using the DisplacementMapFilter for map projections: (1) because of the way the filter works, if what you know ahead of time is the exact distance that pixels need to be displaced, it seems to be necessary to iterate over every single pixel twice, once to determine the maximum displacement in each direction for the entire image and once to then actually draw the displacement map; (2) precision in displacement is very limited, as it can only be from 0 to 127, in whole numbers, in either direction (multiplied by the scale factor); and (3) some projections will result in larger images than the original unprojected map, and it is a nuisance to try to deal with those using this method.

Screw it, then. Why not just move the pixels manually? To do this, we basically look at each pixel in the source image, run its latitude and longitude through the projection formula to determine its new location on the projected map, and then draw that pixel on the projected map with the color of the source pixel. Here’s what happened when I did that:

Hey, it’s the correct shape! But there are two issues with distorting a map to project it, namely, that the map is going to be compressed in some places and stretched in others. I’ve already attempted to deal with the compression in the above image. Instead of directly transferring the color of a source pixel to the projected map, I kept track of all the source colors that corresponded to a pixel on the projected map, then drew the average color on that projected pixel. Otherwise, when more than one source pixel corresponds to a projected pixel, the color would just be replaced every time one of those source pixels is encountered. In this case it was actually difficult to see much difference, but the attempt at resampling seemed like a good idea.

The second issue, the stretched parts, is evident in the above map, showing up as those white (empty) curves emanating from the edges. That occurred where pixels on the projected map had no corresponding source pixel because of distance distortions in the projection. To correct for this I did a simple interpolation in which I identified pixels with no data and assigned each a color that was the average of any neighboring colors. With that, then, we have our final map:

It’s not the most beautiful map, but not too bad, I’d say. That’s just one type of projection, though. As you might expect, the more interpolation that’s needed, the worse it’s going to look with these methods. Below, for example, is part of a Mercator projection. (Remember how I said larger map projections are a nuisance with the DisplacementMapFilter? Well, they’re kind of a nuisance in general, hence “part of” a map here.) The Mercator projection stretches the map pretty significantly in high latitudes, and as you can see the map doesn’t look very good near the top and bottom.

It’s also worth noting that these raster methods are probably best with continuous images like the example used here. The flaws are more noticeable with a rasterized line map, as below (projected using a source image from the wonderful Gallery of Map Projections).

And Mercator’s not so hot:

For the record, here’s what a nice, scalable, vector map projection from a shapefile looks like in Flash:

This little experiment has demonstrated that reprojecting raster maps in ActionScript is possible, perhaps with acceptable results in a pinch, but it’s far from perfect. I don’t doubt that it would be possible to use more advanced resampling and interpolation methods, but this is already a lot to deal with. The projections here took several seconds to compute and draw on my machine. That’s probably already an eternity in computer time, especially for a relatively small image, and it’s only going to grow as the algorithm becomes more complex. (Okay, minus the time that would be saved if my surely inefficient code were improved.) This kind of thing isn’t Flash’s strong suit anyway, right? Real geographic raster processing is being done with things like GDAL.

But again: in a pinch, it works!

Some references:

• The aforementioned Gallery of Map Projections is a good resource for seeing what different projections look like.
• This Java applet demonstrating map projections appears to use a raster map, though I’m not entirely sure how it operates. The source code is available.
• For map projection formulas, I recommend Wolfram Mathworld or Wikipedia.
• If you have access to the journal Cartographic Perspectives, check out Number 59 (Winter 2008) to see a gallery artistic renderings of map projection distortions by daan Strebe. The displacement map image used in this post reminded me of those images, which were presented at the 2007 NACIS conference.