Part of the reason that readers have enjoyed the map, I think, is that it confirms graphically what people have long known or suspected about regional trends based on either hard statistics or gut feelings: that the Pacific Northwest is being flooded with Californians, that Florida is suffering from brain drain, that Los Angeles no longer has the universal draw that it had during much of the 20th century, and that Detroit is in serious trouble and Dallas is doing rather well for itself.

At a higher level, the map confirms that the United States is a highly mobile country: one in which the lack of jobs in Detroit and the surfeit of them in Dallas draws massive numbers of people (806 of them, in fact, moved to the Dallas region from Wayne County; 167 went the other way). Commentators have offered theories of how taxes, costs of living, and quality of life create patterns on this map as well. Americans know what they like, and they’ll move to get it.

In skimming through the astonishing number of comments that people have posted (mostly to sites other than Forbes.com), I’ve come across a few persistent questions that I’ll answer here before explaining how the map works.

The lines obscure everything! Why not just use colored fills in the counties (i.e., a choropleth map or heat map) to illustrate net change?
Because that would be visually boring. The lines create a narrative by forcing the reader to see relationships between counties, not just flat characteristics. Click on Miami: your eye immediately catches the big swoosh of people from the Northeast and then follows its outward counterpart to the West. The lines are dynamic and directional; they suggest movement, which is exactly what the map is meant to show.

The other problem with the heatmap approach is that it would result in lots of emptiness: Maricopa County, Ariz. (which contains Phoenix) has the most connections of any county: 834. That’s a lot of lines on this map, but it’s not many counties to color: just over a quarter of the 3,000 or so counties on the map. Rather than seeing an explosion of movement when you click on Maricopa County, you’d see a limp, mostly-blank map with a few counties colored in and nothing to suggest their relationship to Maricopa County. That issue becomes really acute when you get to the 2,700 counties with fewer than 100 connections.

So there you go, Snoozy McBoringstein.

Well, then, have the lines appear by default but give me a button that I can use to make them disappear.
Okay, sure. I’ll try to satisfy these criticisms by way of more features in version 2 of the map, which I’ll probably publish this fall when the IRS’s 2009 data will be released. I thought of a lot of features that I’d like to include but couldn’t because this map already taxes most users’ computers. That can be fixed through careful optimization, but I didn’t have time to do as much of that as I’d have liked because I published the map literally 20 minutes before leaving for a week in Hong Kong.

This map is incomplete/misleading because the IRS data doesn’t include immigrants.
True, I suppose, but this is the very best migration data available and, in fact, its problems can be generalized beyond that complaint: the IRS migration stats don’t include anyone who didn’t file an income tax return (or count as an exemption on someone else’s return) in both 2007 and 2008. That means that there are some distortions when it comes to people entering the workforce (through immigration or by getting a first job) and people leaving it (i.e., retirees who file their last tax return the year that they move to Florida). It also probably leaves out some low-income earners who don’t file income tax returns at all.

How It Works

More than a few people (starting with @TribData) have asked how I built the map. Here’s the broad outline: IRS Data + Python + county shapefile + MAPublisher + ActionScript 3.0 = interactive map with tons of data.

I began with data from the Internal Revenue Service that reports migration stats for every county in the country: inward and outward tables that include number of returns filed, number of exemptions reported on those returns, and aggregate adjusted gross income for those returns. Using Python, I broke down the data and wrote 3,000 XML files (one for each county) plus a grand index file that contains county names and FIPS identifiers and uploaded all of those to our servers.

The map itself began with a county shapefile that I beautified with Avenza MAPublisher and imported to Flash using the process outlined on Kelso’s Corner. The result is a Flash file in which each county area and outline is its own movie clip, named with FIPS identifiers.

My ActionScript code in the map draws all of these together: it downloads the index XML file, then cycles through all of the county movie clips and adds event listeners for rollovers and clicks to each one (this is what it’s doing as the loading bar creeps across the page).

When the user rolls over a county, the rollover event listener fires, retrieves the county name from the index, and displays it. When the user clicks a county, the click event listener fires, downloads the relevant individual XML file, and draws lines between the clicked-on county and each associated county.

JavaScript in the article page looks for a URL parameter called “preload” and passes its value along to the Flash file; this allows users to share links that pre-load a particular county.

In the past, I’ve made all of my interactive maps using Avenza’s excellent MAPublisher software. MAPublisher handles geocoding and projections, which leaves me free to faff about with color schemes and callouts.

When you code your own map from scratch like this, though, you have to write something to geocode points and then project them (unless you’re partial to maps where Canada, Greenland and Russia seem to be taking over the world). There are less math-intensive solutions to this, like creating a map in Illustrator and then moving it to Flash (recommended for choropleth maps), but I wanted maximum programmatic control over the map (and the thrill of coding my own solution).

Geocoding was fairly easy in this case; I just derived centroids for each country using ArcGIS and merged those coordinates into the dataset from Heritage’s Derek Scissors using Stata. The data for each country now included deal value, acquirer, target, target’s country, latitude, and longitude.

Now for the projection: simply sizing down the latitude and longitude coordinates linearly by enough to make them represent pixel locations would result in a so-called ‘unprojected’ map that’s a dishonest representation of shapes and relative sizes. Unprojected maps also tend to waste a great deal of space by making the highest and lowest latitudes enormous and the middle latitudes small–a general problem for Web layouts like ours, where maps can’t be more than 768 pixels wide, and for this map specifically, because a great deal of Chinese investment has taken place in parts of Africa and South Asia that are near the equator.

I went for the Winkel Tripel projection, currently the presentation of choice for National Geographic and one that strikes a reasonable balance between angular and spatial distortion. Wikipedia conveniently provides the transformation formulae, which include functions like arccosines that I hadn’t seen since college physics classes. With longitude as λ, latitude as φ, and standard parallel–the latitude above and below the equator at which the projection is entirely accurate–as φ_1, we get mappings for the x and y coordinates thus:

where

It would be easy to code these equations into ActionScript and have each user’s Flash player map the investment dots on the fly. But Flash files with more than 200 event listeners (counting rollover and click listeners on the dots and bar graph and click listeners on the legend and buttons) already strain some feebler computers. Preprocessing the mapping seemed like the way to go, so I did the projection transformation in Python as I built the XML files that underlie the map (one file that includes every investment, its magnitude for sizing, its x/y coordinates for location, and details for the callouts; and another file that includes monthly data for the bar graph).

With the XML files built in Python, ActionScript just had to handle some simple placement and sizing tasks: creating a circular movie clip for each investment, coloring it appropriately, and adding it as a child to the stage. The script adds all of the circles to the stage when the map loads, during the time that the background displays a big “Loading…” notice; as the animation plays, the circle movie clips are set to visible and a little popping animation is applied along with a small sound effect. While the Flash file is open in the viewer’s browser, the circles and spark bars are stored in arrays for easy access with the .indexOf() method.

The combination of sound effects and spark bars might seem redundant, but they illustrate two different dimensions of these investments: the spark bars show dollar volume, which might be high even in months when there’s just one investment. The monthly number of investments is the other dimension: the visual animation is meant to call the viewer’s attention to each newly-appearing circle, but it’s difficult to keep track of every new dot on the map every month. The sound effects reinforce the visual animation by giving an overall feel for the number of dots added each month (the popping sound plays once for every new investment in each month).

The data that the maps are based on come from my friends at Inrix, a clever company based just outside of Seattle that measures traffic congestion using data from GPS tracking systems in commercial fleets. I’ve written about them before, and used their data in December 2008 to form the Forbes “Chirp Index,” a group of leading indicators with which we (fairly accurately) predicted that the recession would bottom out late in the summer of 2009.

After a couple of years of declining traffic congestion (due first to rising gas prices and then to rising unemployment), traffic congestion seems to be coming back. Growth in economic activity and stimulus-related road construction projects are bringing more people onto the roads and then slowing them down.

A minor tiff erupted in the comments section of my article; one commenter suggested that traffic congestion wouldn’t come back if only we invested more in public transportation. The next commenter wrote that public transportation hasn’t been proven to have any meaningful impact on traffic congestion.

Both commenters make legitimate, though incomplete, points. Public transit advocates tend not to talk of payoffs from transit investment in terms of immediate relief from congestion; after all, much of the housing and commercial space that’s been built in this country over the last 50 years is fundamentally incompatible with efficient transit schemes. The office-park worker who lives on a cul-de-sac will likely never be able to use even the most ambitious new transit system to commute–at least not as long as he lives in a housing tract and works in an office park.

That’s why transit advocates concede that new rail lines won’t immediately cut traffic on adjacent arterial roads. Rather, they say, transit systems encourage the kind of development that is compatible with transit use: walkable neighborhoods with a combination of townhouses, apartment high-rises, offices and shopping that are based around transit stations.

This kind of development is popular in places like Northern Virginia, where a well-run rail system links outlying areas to a massive job center in Washington, D.C. It takes much more patience to introduce these kinds of transit-oriented neighborhoods to cities with comparatively weak central business districts, like Phoenix, Los Angeles, and Atlanta, since people who live in them but don’t work in them may still have to drive to otherwise-inaccessible office parks.

So new transit networks in car-oriented areas constitute major investments in reorienting urban development over a period of decades, not a quick attempt to remove a few cars from highways. Traffic will come back this year–there’s no way around that–but sound investments now could mean that it will bring fewer headaches fifty years from now.

Here’s how it works: copy and paste the code below into the HTML of your web site wherever you want it to appear. Because we’re bound by an embargo and are not allowed to release this year’s ads until the end of this year’s Super Bowl game, the viewer will contain ads from last year at first. Embed it anyway. In an unprecedented feat of Internet magic, the viewer that you put in your own blog will automatically replenish itself with fresh, fresh 2010 ads after the big game on February 7. Again, we make it easy for you.

When we switch in the new ads on the 7th, we’ll also remotely activate a voting feature in the viewer that will let readers pick the best and worst ads. Expect to generate some good discussion in your comments section.

Here’s the viewer. Scroll down to copy and paste the code.

And here’s the code:

<script type="text/javascript" src="http://images.forbes.com/scripts/swfobject.js">
</script>
<script type="text/javascript">
swfobject.embedSWF("http://images.forbes.com/jb/superbowl/viewer.swf",
"myAlternativeContent", "568", "600", "9.0.0", "expressInstall.swf", {},
{allowscriptaccess:"always", allownetworking:"external"},{});</script>
<div id="myAlternativeContent">You must have Adobe Flash Player 9
or higher installed to view this content
<a href="http://www.adobe.com/go/getflashplayer" target="_top">
<img border="0" alt="Get Adobe Flash player" align="left"
src="http://www.adobe.com/images/shared/download_buttons/get_flash_player.gif"/>
</a></div>

Visit Forbes.com for more details on our embeddable Super Bowl ad viewer.