Andrew Powell, Doug McCune, and Brandon Purcell have already posted great introductions to SpatialKey, so I won’t go through all that here. But just so’s you know: SpatialKey is a visualization system for geotemporal (location + time) data, developed primarily in Flex, that lets you filter and render thousands of points very quickly, all client-side in your browser.

This is not a formal release. We’re in a technology preview for now, which means you just get to see some sweet examples, but soon we’ll release a version, SpatialKey Personal, into which you can load and visualize your own data. Here are links to three of my favorite examples (for more, check out our Gallery page, or this post on the SpatialKey blog).

• where prostitutes are arrested in San Antonio
• the housing slump in Sacramento
• the radial spread of Wal-Mart

As I said, other better introductions have been written on SpatialKey; I just want to focus on a few of my favorite features or attributes.

not a single, do-it-all application

SpatialKey is based around a collection of visualization templates. Each offers a unique view of the data, with specialized visualizations, filters, and UI controls. Since the templates are specialized, each one is pretty easy to learn and begin using.

The examples linked above demonstrate the animation, map comparison, and drill down templates. The fourth template we’re showing off now is the temporal heat index template (here’s an example of that: Sacramento residential burglaries).

chorodot symbolization

You don’t see these much, but I think they’re really effective. The “heat grid” symbolization in SpatialKey is a modern implementation of a technique put forth by Alan MacEachren and David DiBiase in 1991.

Aggregating points to arbitrary but regularly-shaped polygons, or binning, was an extant graphical practice at the time, but the geographic application and their particular methods created an effective cartographic symbology. Other than SpatialKey, I haven’t seen this symbolization in a geographic visualization context, but I think it’s very effective at presenting large datasets that require aggregation. The heat grid symbolization in SpatialKey extends the approach by allowing grid renderings of attributes of the data (like house prices or temperature) in addition to aggregation of the count of points.

MacEachran and DiBiase’s example chorodot map of AIDS in Pennsylvania (image from J.B. Krygier’s lecture notes)

SpatialKey grid symbolization showing a data attribute (average home prices) in Sacramento county

small multiples / map comparison

I’ve always been a fan of the small multiples depiction of change, illustrated so well by Edward Tufte in The Visual Display of Quantitative Information and Envisioning Information. Though the SpatialKey Map Comparison template shows two multiples, it qualifies (and we can easily plug in more maps for specialized templates).

D.C. construction in the SpatialKey Map Comparison template

Both the maps and the time charts are live-linked. Mousing over an area on one of the maps or a bar on one of the time charts reveals the tooltip for both displays, allowing you to easily retrieve specifics for different time periods or areas.

complex temporal filtering and focusing via the heat index chart

The time chart, shown in the first screenshot above, is great for revealing linear temporal trends in a dataset, and for enabling linear filtering. But some datasets evince more complex temporal trends — for example, some crimes may be more common on a certain day of the week and at a certain time of day. Such trends are lost when data is aggregated in a linear fashion to, say, days or weeks.

sex crime arrests in Sacramento

The temporal heat index chart reveals such complex trends and allows filtering by multiple temporal aspects simultaneously (for example, showing only prostitution arrests on Tuesdays between 3 and 4 am).

in closing

I was late to the game on this one, joining Universal Mind in June. SpatialKey was developed by the brilliant team of Doug McCune, Ben Stucki, and Andrew Powell, led by Brandon Purcell and Tom Link, with product manager Mike Connor. It’s a privilege working with such a talented crew.

Our goals for this technology preview are modest (blowing minds, getting feedback), but we’re excited to continue developing SpatialKey and SpatialKey Law Enforcement. And we’ll be releasing updates, new examples, and SpatialKey Personal in the near future. So stay tuned to the SpatialKey blog, and please contact us if you have any feedback on our technology preview.

This cool app answers seemingly every question about when and how Manny hit his home runs…except for the one I’m most interested in: where on the plate is Manny most likely to hit a home run? I’ve seen a few visualizations recently that do this sort of thing, so I thought I’d share this view of current practices in the area of pitch location v. batting performance visualization.

ESPN will often show you a 1D view (showing only the x dimension of the pitch location) during games, dividing the plate into three horizontal segments (in this case showing the number of home runs this year by Vladimir Guerrero):

A more advanced, 2D view of the same is used often on ESPN’s Baseball Tonight:

For a while now, ESPN.com’s baseball Gamecasts have shown real-time pitch locations, including whether the ball was called a strike (red) or a ball (green).

Turning on “Hit Zones” reveals a very cool diverging blue-to-red heatchart-style graphic of batting performance in the 9 segments of the plate’s plane.

The above is apparently a common method of showing this statistic. These heatcharts differ in 1) how many segments the plate is divided into and 2) whether a sequential or diverging color scheme is used. Here’s one — with many more segments and a high swing zone — for Ted Williams, from the Official Ted Williams Website.

And a very cool report in the Baseball Analysts shows batting averages with 20 pitch location squares, aggregated over two seasons, and divided into the four types of batter-pitcher matchups. For example, the image below shows the greyscale heatchart for the matchup, Left-handed pitcher vs. Left-handed batter.

MLB.com’s Gameday does a better job, methinks, of showing pitch locations relative to the batter and the plate. But they don’t give any indication of the particular batter’s performance with different pitch locations:

I also like the above because it at least suggests the 3d nature of the strike zone: pitches with movement will not leave the space above the plate at the same position as they entered it. The heatcharts shown above do a good job of showing pitch locations in the x and z dimensions. A pitch visualization notable for showing these x and z locations at various points in y space is Lokesh Dhakar’s Baseball Pitches Illustrated (shown below is the slider), though this too is concerned only with pitching.

Thanks to the PITCHf/x system, there is a ton of pitch location data available. Currently, though, there have been few attempts to flexibly visualize this data. One app, the PITCHf/x tool by Josh Kalk, is quite flexible, but the charts themselves leave something to be desired (below for Ben Sheets).

I’m thinking more of a tool like Visual i|o’s baseball visualization tool, or the Boston Globe app linked above, that would take advantage of this rich data, but allow it to be manipulated and filtered in real-time. For example, I’d love to just look at called strikes or balls, and be able to filter that down by ballpark, or perhaps even by individual umpire, and visualize it by the ratio of strikes-to-balls, to get a better idea of the true strike zone. And, it’s worth noting that there’s no reason this information need be aggregated to grid squares; it could also be shown with a continuous density representation like this style of heatmap.

So, given a field of points (weather stations, say)…

…with one or more attributes attached (temperature, say)…

…a TIN can be constructed.

With the above TIN, values can be interpolated along each edge between the points of known values (control points). The interpolation is strictly linear (that is, the value 50 would be interpolated halfway along an edge whose control points were valued 48 and 52).

With a given contouring interval (I’m using 4 degrees F here), we can connect some of these interpolated points, creating our contour lines.

With the previous steps stripped away, this creates a passable isoline map.

The lines are rigid, though, and should be smoothed for presentation. I allow two methods for this. You can use the “simple” method, which just uses the built-in graphics method curveTo between the midpoint of each isoline segment (below with the isoline interval decreased to 3 degrees).

The above looks alright, but the curves are not continuous, closed loops can still have hard corners, and the isolines no longer pass through the interpolated points (we have therefore generalized an already-inaccurate interpolation). My compatriot Andy Woodruff, author of the glorious new Cartogrammar blog, offered to write a nice continuous curve method that ensured isolines would still pass through the interpolated values. You can read about the method in his post. Here she blows:

Bringing it all together, then, and incorporating the only extra feature I wrote (tinting of isolines), here’s a nice finished isoline map of temperature across the U.S.

My new isolining package for Flash/ActionScript3 accomplishes all of the above, requiring only an array of point data with attribute values attached. The above example, was accomplished with the following lines of code (after drawing the U.S. states from a shapefile).

The full example is included in the .zip distribution. Get that here:

• the full .zip thing (in addition to my isolines class and an example, the archive includes my delaunay triangulation package, Andy Woodruff’s cubicBezier class, and a slightly modded version of Edvin van Rijkom’s shp classes, which are used to draw the shapefile in the example .fla)
• or, for you browsers, the main IsoUtils.as class

Keep in mind: triangulation is just one interpolation method, and is many ways the least technical (and accurate). More accurate interpolation techniques include inverse-distance and kriging. ***If you’re having trouble, and your isoline interval is not an integer, check out the comment at line 171 of isoUtils.as. Please fix that, BTW.

I meant to add other features, but since I started work this past week, I’m posting the package as-is, and invite others to modify. On my wishlist:

• hypsometric tinting, or color between the lines, would allow for more effective terrain or temperature mapping
• support for projections and other coordinate conversions in the drawIsolines method. I have packages for converting lat/long to a number of map projections, but currently the drawIsolines method doesn’t have support for passing a point coordinate conversion method.
• an animated demo. This thing’s lightning-fast, so why not?
• something that would be super wicked would be if someone would implement Tanaka’s illuminated contours [pdf] method, that thickens/thins and darkens/lightens lines like so…
  
  …creating beautiful relief maps like the one below
  

If you add anything to the package, feel free to post a link to your revised version in the comments.

Now there’s nothing wrong with Blosxom (well…), nor with other minimal blogware, but I gradually grew weary of the quirks (for example, it took me a weekend to debug the commenting functionality) and I began to feel like it was taking away from my writing.

What does this mean for you?

• I’ve likely lost a lot of indie cred in your books.
• If you subscribe, you’ll want to update your feed to this.
• Outside links to individual blog posts won’t work. I can hopefully fix or redirect these eventually, but for now we’re all screwed.

On the bright side, you’re here, which means something’s working.

The term “heat map” has become increasingly confused. Perhaps it doesn’t matter, but for the record the above map is a choropleth map. It’s been branded by Google (as one of the Google Gadgets) with the sexier label “heat map”, and this (mis)usage is catching on. The term heat map is already equivocal. First, as a non-geographic, non-map representation, the heat map is a treemap-like graphical technique used to represent a two-dimensional array of data.

As a cartographer, though, I’ve always (well, ok, for a year or so anyway) taken heat maps to be a thematic mapping technique in which a (typically) diverging, (usually) thermal-like color scheme is used to represent density in a continuous fashion. Like the following (from Cartifact’s Downtown L.A. homeless map).

This technique holds the use of color (well, value or lightness really, not hue) in common with choropleth mapping. That is, they share the same visual variable (though, as noted, heat maps almost always utilize a diverging color scheme, in which both hue and value/lightness are varied). The difference is that choropleth maps represent data by enumeration units (countries, states, counties, blocks) while the heat map technique is continuous and not aggregated to enumeration units.

As I say, perhaps it doesn’t matter, and I’m not really advocating that Google Gadgets users (and others) learn the term “choropleth map”. Indeed, I’d be just as happy with the also-misleading term “color map”, as at least it does not already stand for two different symbologies.

The Delaunay triangulation was invented in 1934 by Boris Delaunay. According to Paul Bourke,

The Delaunay triangulation is closely related geometrically to the Direchlet tesselation also known as the Voronoi or Theissen tesselations. These tesselations split the plane into a number of polygonal regions called tiles. Each tile has one sample point in its interior called a generating point. All other points inside the polygonal tile are closer to the generating point than to any other. The Delauney triangulation is created by connecting all generating points which share a common tile edge. Thus formed, the triangle edges are perpendicular bisectors of the tile edges.

What all that means is that the resultant triangles will be as equilateral as possible. The triangular mesh has the advantage of minimizing the distance over which interpolations must take place.

Go ahead, try it out.

With the idea of creating client-side isolines and inspired in part by the spirit of Keith Peters’ ongoing MathWorld Problem of the Week, I set out to write an AS3 class to create the above triangulation. After an hour of hacking, I gave up, and decided to just port the algorithm from another language. I chose Florian Jenett’s Java version, itself a port of Paul Bourke’s original C. The port was easy, and makes it a cinch to create a triangulation of, say, selected weather stations in the U.S.

(sorry - unprojected)

Of course, this triangulation isn’t really interesting in its own right, but rather for what it allows us to do, at run-time, with near real-time data, in Flash. On that, check this out.

(a temperature isoline map generated in Flash from a field of only 50 or so weather stations of the form lat, lon, temp)

I’ll release a full isolining package — complete with smoothing and hypsometric tinting — soon. For now, here’s the source code to the Delaunay triangulation in AS3.

• Full .zip with necessary classes and example .fla
• For browsing, the main Delaunay.as file

I defend my thesis next Tuesday, so have been staying away from here lately. I will return soon.

“Map” above is the USGS Rozel Point SW Quadrangle.

3d visualization cartography climate change geographic information science geographic visualization geovisualization gis giscience interactive map modeling self-organizing maps uncertainty visual analytics visualization

Tag clouds use the visual variable of size to convey information. As a cartographer, then, my first instinct was to compare tag clouds to proportional and graduated symbol maps.

When viewed in this light, tag cloud scaling begins to seem quite haphazard — font point sizes, not areas, are modified to communicate the data. Thus, two tags of varying character length (GIS vs. Geographic Information Science, for example) but equal incidence will have very different visual presence (though their font point size will be equalized, the area will not).

3d visualization cartography climate change geographic information science geographic visualization geovisualization gis giscience interactive map modeling self-organizing maps uncertainty visual analytics visualization

Sixteen hours into my 30 hour train trip from Boston South Station to Chicago Union Station, I got the hairbrained idea that tags could be more accurately scaled — each one can be thought of as a rectangle, and a point size can be calculated for each tag such that its rectangle’s area is proportional to its incidence.¹ I call this the Amtrak method. I wrote first an as3 class, then a somewhat hacky PHP script to generate the pseudo area-scaled tag clouds. I say it’s hacky b/c the areas aren’t really exact — I don’t have a method for exactly figuring the bound area of rendered html text. So instead, I estimate it based on character length. Specifically, I estimate the area of a rendered tag to be:

tagarea = taglength * fontsize² / 2

A simplification to be sure, but based on some tests in Flash, not too inaccurate (for my Helv anyway). This gives us the formula for the font size of each tag.

fontsize = sqrt( 2 * tagarea / taglength )

In the above, tagarea is determined by dividing the tag’s occurrence value by the maximum number of occurrences among all the tags and multiplying this percentage by a predetermined maxarea value (I use 12,000, natch). So for each tag:

tagarea = occ / maxocc * maxarea

This generates the following, based on the same data as the above two clouds.

3d visualization cartography climate change geographic information science geographic visualization geovisualization gis giscience interactive map modeling self-organizing maps uncertainty visual analytics visualization

Leave it to a grad student to create a problem where none exists. Looking at my new Amtrak tag clouds, I don’t think they communicate the data more clearly. As I say at the beginning, tag clouds work. Existing tag clouds work. And they work for a reason. Font point size is a measure of the height of the text, the distance “from the top of the capital letter to the bottom of the lowest descender, plus a small buffer space” (Ellen Lupton’s Thinking With Type).

Thus, tag clouds employ the specific size variable, height (or length). This is most similar to proportional symbol maps using a bar symbology.

But it isn’t that simple. The symbols in a tag cloud also vary in width. The important data is encoded in height, the width is simply related to font size and tag character length, and it must be temporarily ignored by readers to determine the tag’s number of occurrences. This is most similar to a bivariate technique in cartography where the width and height of a bar are varied independently to show two different variables.

In such maps, as in tag clouds, the user is expected to attend to and separate the visual dimensions of width and height. Is attending to the height of a symbol, while ignoring its width, a realistic task? Or, in the speak of the discipline, is length a separable or an integral dimension? If it is separable, it can be attended to selectively. If it is integral, then it cannot be ignored.

There is no definitive answer to the question of size (or length) selectivity; existing evidence is mixed. Bertin considered size to be dissociative, or integral (in Semiology of Graphics). Alan MacEachren cites numerous studies of selectivity of visual variables (in How Maps Work) and my own thesis research has required a survey of the bivariate symbol literature. It appears that size-size has a configural relationship, which is somewhere between integral and separable (selectivity appears to be a continuum). Though not a sparkling recommendation, this at least suggests that people can, with little work, separate perceptually the width and height of a symbol. In doing so, they can estimate the number of occurrences of a tag, while ignoring the tag’s overall visual presence (esp. it’s width).

1 OK, I suppose another way of thinking about the area of the text is to look at the amount of ink on the page. But this would be much harder to determine, and will correlate with character length.

These have gotten a lot of attention lately (uses the Gastner-Newman diffusion-based algorithm).

Some cartographers manually tweak their automatically generated cartograms to better preserve shape or topology (from the Dutch company Mapping Worlds).

Some preserve shape completely (from the Online Atlas of the Millennium Development Goals also by Mapping Worlds).

Others abstract enumeration units to geometric primitives (generated by my Python script, based on Daniel Dorling’s algorithm).

And of course many other designs can be found between these extremes (redrawn from the NY Times‘ 2006 election results app).

The standard approach to cartogram design is to classify them as either contiguous or noncontiguous (with some adding a pseudo-contiguous category). As the small gallery above illustrates, this is inadequate. It seems to me that cartogram designs vary along three dimensions, and that variation along each dimension is continuous.

1. Shape preservation — how much the original shapes are preserved on the transformed cartogram (can be quantified with local angles and edge length ratios)
2. Topology preservation — how well adjancencies are preserved
3. Density equalization — how accurately unit size represents the chosen attribute

The latter requires perhaps more explanation. Isn’t size on a cartogram supposed to perfectly reflect the chosen attribute? Sure, but some recent cartogram algorithms (Gastner-Newman slightly, Kocmoud-House somewhat more) have chosen to allow for some inaccuracy in order to better preserve shape or topology. Since readers can’t accurately estimate area anyway, this seems like a fair tradeoff.

To show these continua, and better portray the tradeoffs involved in preserving individual properties, I drafted the Cartogram Cube. It has helped me think through some of these issues while writing my thesis.

Cartogram³

Does any of the above matter? Well, only to the extent that it helps us make better maps. But I believe cartogram effectiveness has a lot to do with these design characteristics, and depends largely on the property tradeoffs made in cartogram design (for manual and algorithmically-produced cartograms). Indeed, this is precisely what my thesis results — to be defended on May 13 — indicate.

More on my actual results later.

Tomorrow, two of my fellow UW cartographers and I board a train in Chicago for our 24-hour ride to the Annual Meeting of the Association of American Geographers in Boston. I’ll present a paper, Cartograms for Political Cartography: A Question of Design, on Saturday, but I’m more excited about the visualization and cartography talks throughout the week.

To see what I can look forward to, I worked up a quick tag cloud of the keywords used by presentations marked ‘visualization’ in the AAG Preliminary Program.

3d visualization cartography climate change geographic visualization geovisualization gis giscience interactive map modeling self-organizing maps uncertainty visual analytics visualization

And for my fellow cartophiles, a cloud of the keywords used by presentations marked ‘cartography’.

animation art atlas cartograms cartography cinema computer mapping critical cartography education geographic education geology gis hazards historical cartography historical geography history of cartography map map use mapping maps navigation political cartography political geography propaganda maps remote sensing united states visualization

When I return, I’ll probably follow up this post with one or two more. My angle?– visualization in contemporary academic geography.

BTW, the map above is from Alex Tait & Erik Steiner’s actually quite cool Amtrak Route Atlas. Oh, and the reason our route stops in Albany is because of track repairs — from there we hop on a bus to Boston. Bring it on Amtrak!