Some links for tonight:

• CartoDB
• Google Refine (the software we used last week)
• New York State traffic fatalities dataset
• Fusion Tables

Here’s a sample map of the sort that I’ll build in tonight’s workshop:

All of these workshops use as examples data made available through the White House Office of Science and Technology Policy‘s Safety Data Initiative. Below are some helpful links that I’ll mention during the sessions.

• Start by downloading and installing Google Refine.
• My first example dataset is this list of mine accidents. The data series page, which is referenced in the metadata, includes the all-important definition file as well as the master list of all mines. I used the joining method outlined by Tony Hirst on his blog.
• My second example dataset is this KML file of auto accidents.
• Some useful articles on Google Refine techniques from Paul Bradshaw. H/T to Jonathan Hayter for pointing these out.
• Some relevant O’Reilly books (obviously, I work for O’Reilly, but I learned to program with the famous “animal books”. These are great introductions and you can download them as DRM-free e-books):
• Introducing Regular Expressions—Regex, which lets you extract data from formatted text, is one of the most powerful tools in data mining. Google Refine offers plenty of ways to use regular expressions, and it’s also a key feature of scripting languages like Python.
• Learning Python—Python is my favorite scripting language: once you’re familiar with it, you’ll find it easy to build small bits of software that can, say, scrape thousands of web pages in a few minutes or turn a spreadsheet into thousands of graphs. And it scales up from there: Python is one of the languages that Google uses to build some huge systems.
• R in a Nutshell—R is the most widely-used open-source statistical package, with free add-on libraries for every discipline. I got my start with Stata, and found R difficult to learn, but once you do you’ll find it to be a very powerful tool that can stand in for Python and full-scale database applications for many data-journalism projects.
• Advanced resources: at some point you’ll want to use a database to store and analyze data. MySQL is the reigning king of open-source database software, and you can learn it with the aptly-named Learning MySQL. For certain applications, the freer forms of Mongo are more useful, and you might want to take a look at MongoDB and Python, which outlines ways to use Python to fill and analyze a Mongo database.

It’s been an unfathomable joy to work at Forbes for the last six years. Anyone who has asked me about my work there has heard me glow about the magazine’s inquisitive minds and open culture and the extraordinary latitude I’ve been given in choosing and executing my own projects. My experience at Forbes has defined what I want in a career.

I’ve gotten to know O’Reilly over the last couple of years, and I’ve been deeply impressed by its role as a gathering place and intellectual exchange for the technology industry–as Pushkin is the only thing all Russians can agree on, so is O’Reilly a central cultural feature of the technical economy. It’s now reaching well beyond Silicon Valley by drawing together its original constituency in the tech industry with other areas that are anticipating rapid, disruptive change–healthcare, news publishing and basic scientific research, for instance.

My work at O’Reilly will involve many of the same things I’ve loved working on at Forbes–writing about the technology industry, exploring data with narrative and interactive applications, and getting to know people whose ideas are transforming the economy. I’m also looking forward to being a regular participant in O’Reilly’s great conferences and to freelancing as time permits.

I’ll continue to live and work in New York, and you can continue to reach me by the e-mail address to the right.

My interactive migration map for Forbes, showing inbound (blue) and outbound (red) migration to and from Maricopa County, Arizona

My latest interactive migration map on Forbes.com improves on the previous version in a few ways: it’s got five years of data instead of one; a brand-new layout; and some much-requested features like a search tool and the ability to switch off the lines. But the upgrade that I’m most excited about is in the code: I built the map using nothing but open-source software, from Python and MySQL to handle the data right down to JavaScript to display the map. I’ve been steadily moving much of my data handling to Python and MySQL, but this is the first map I’ve made using JavaScript, and interactive JS maps are still rare elsewhere, too.

The previous map was built in Flash, and I used some other proprietary software to handle the data and tweak the presentation. Moving to JavaScript for interactive applications saves money you’d otherwise spend on Flash licenses and it makes your work more widely available: this map functions on the iPad, for instance (albeit very slowly, since it’s computationally intensive and involves fairly large downloads). Here, in case it’s useful for anyone else who makes these sorts of things, is a rundown of how I built the map.

Overview

This year’s map is similar in basic function to last year’s. When you visit the page, JavaScript code renders a county map of the United States and prepares it for interaction. When you roll over a county, an event listener fires, displaying a callout with the name of the county and turning the county’s edges red. When you click on a county, your browser downloads a corresponding file that includes a list of other counties to which and from which people migrated, along with relevant stats (income per capita of migrants) and the figures that are shown above the map (year-by-year migration, population). Your browser fills out the stats at the top of the screen, draws a graph (or animates a change from the previous graph, if you’ve already clicked on a county), and loops over the counties in the file, filling them with some shade of red or blue to indicate net inward or outward migration.

My JavaScript code deals with two big datasets: one—the migration data—is downloaded and rendered on the fly every time you click on a county. The other consists of the contours of the map itself: the locations of the boundaries that define the 3,143 counties in the United States.

The Map

I started by building a generalized interactive map of U.S. counties, where each county listens for rollover and click events and the appearance of each county can be changed programmatically. This is the sort of interaction that Flash has been critical for in the past, but the rise of faster browsers that better comply with universal standards means we can make this sort of map with JavaScript.

You can build a map like this with HTML5 Canvas, or, more promisingly, publish the map as an SVG image and use a library like JQuery to manipulate the appearance of the counties with CSS. But neither of those techniques is compatible with Internet Explorer 7 or 8, which together still have significant (roughly 15%, in the case of this map) market share. To get around this browser compatibility issue, I used the excellent Raphaël JavaScript library to draw counties and handle interactions with them. Raphael renders images as SVGs for users with modern browsers and as VMLs for Internet Explorer users, and it provides a useful set of functions for interacting with shapes once they’ve been drawn.

We want Raphael to create each county as a polygon (or group of polygons). For this, we need polygon definitions for each county, and we can find those in a very useful SVG file available on Wikimedia. SVGs are vector graphics that work something like HTML; open this SVG county map in a text editor and you’ll see a list of nodes that look like this:

<path
 d="M 404.13498,227.558 L 407.75898,227.324 L 407.95298,228.019
    L 408.99798,231.791 L 409.07498,232.061 L 405.21798,232.503
    L 404.57198,232.58 L 404.13498,227.558"
 id="01111"
 label="Randolph, AL" />

That definition draws and labels Randolph County, Alabama. The “d” attribute contains the county’s edges: start at x = 404, y = 227, then move to 407, 227, and so forth. We need to get these paths into Raphael so that we can draw them on the page. Fortunately, the path definition syntax for Raphael looks very similar; we can convert the SVG’s paths to the slightly more compact Raphael format using regular expressions and scale linearly as needed to the width and height of our eventual map.

I extracted the path definition and county ID (a FIPS code—see below) from the SVG file with Python’s useful BeautifulSoup library and stored them in a MySQL database . I then queried that database, along with another one that I’ve built to return properly-styled place names (i.e., “Randolph, AL” becomes “Randolph County (Roanoke), Ala.”), to create a single JSON file that contains a name, ID and path definition for each county. Here’s how Randolph County looks in that file (remember that I’ve increased the size of the map to fit my page, and have scaled the path linearly):

["01111", "Randolph County (Roanoke), Ala.",
    "M727,410L734,409L734,410L736,417L736,418L729,419L728,419L727,410"]

This JSON file is fairly large (mine is about 580KB), but it’s much smaller than the original SVG file (about 1.9MB). Now it becomes easy to download this definition file, loop over it, and draw the counties. In the map’s JavaScript, we write (after importing JQuery and Raphael):

$(document).ready(function() {
    $.getJSON("/path/to/counties.json", function(data) {
        drawMap(data);
    })});

function drawMap() {
    map = Raphael(
        document.getElementById("map_div_id", mapWidth, mapHeight)
    );

    var pathCount = data.length;
    //Loop over all of the counties in the JSON file
    for (i = 0; i < pathCount; i++) {
        //The county's polygon definition is available at data[i][2]
        var thisPath = map.path(data[i][2]);
        //and its ID is at data[i][0];
        thisPath.id = data[i][0];
        thisPath.name = data[i][1];
        //Give the paths whatever appearance you want
        thisPath.attr({stroke:"#FFFFFF", fill:"#CBCBCB",
            "stroke-width":"0.2"});
        //Add event listeners for rollovers
        thisPath.mouseover(function (e) {countyMouseOver(e)});
    }
}

Now the event functions will look something like this. You just have to retrieve the event target’s Raphael node, and then you’ve got yourself a Raphael object that can take all of the Raphael methods. Avoid the temptation to operate directly on these targets with JQuery, because then you’ll lose Internet Explorer compatibility.

function countyMouseOver(e) {
    //Retrieve the mouseover target as a Raphael object
    var raph = e.target.raphael;
    //Use this to display a callout or whatever
    var thisCountyName = raph.name;
    //Change the color of the county's edges to indicate selection
    raph.attr({stroke:"#FF0000", "stroke-width":"1"});
    //Get ready for a click
    thisPath.click(function (e) {countyClick(e)});
}

There’s obviously a lot more than that going on in the migration map, but that’s the foundational structure of the map. It takes a moment for most browsers to render this, but there’s still room to load all of your data in this step if you’re doing something fairly simple with your map. If you need to show more data, you’ll have to make the map download it on the fly, as I do in the migration map.

Adding More Data

The migration map presents a little under 20 megabytes of data in total—that’s pairwise in- and out-migration totals for every county in the country for five years. We obviously can’t have users download all of this data at the outset, and that’d be overkill in any case because most users only look at a handful of counties in a single session. So I pre-compiled one JSON file for each county for each year (15,715 files altogether) and published them to Forbes.com. The map downloads and parses them as users click on counties. So the countyClick function looks something like this, specifying an individual county JSON file to download and initiating the process:

function countyClick(e) {
    var thisID = e.target.raphael.id;
    //Compose the path to the JSON file for this county
    var url = 'path/to/json/files/' + thisID + '.json';
    $.getJSON(url, function(data) {renderData(data)});
}

Then we do whatever we want with the data in the callback function renderData(data).

The IRS Data

A bit about the IRS data I used in the migration map, in case you’re interested.

This data comes in two files for each year, one for inbound moves by county and the other for outbound moves. Each file contains one line for each pair of counties in the country along with tax return stats for the people who moved between them: number of returns, number of exemptions, and total adjusted gross income, in thousands, for those returns. So in the 2009 outbound CSV file, we see this line:

"01","001","01","047","AL","Dallas County",42,94,972

In dealing with these files it’s useful to know about FIPS codes, 5-digit unique identifiers for each county. The first two digits correspond to the state and the last three to the county. In the IRS files they’re broken apart. When concatenated, the two columns on the left give us the county code for Autauga County, Alabama (01001). The third and fourth columns give us the code for Dallas County, Alabama (01047), and the last three columns tell us that people who moved from Autauga County to Dallas County in 2009 filed a total of 42 income tax returns, on which they counted 94 exemptions, and that the total adjusted gross income on all of those returns was $972,000.

Note that only people who file income tax returns will be included in this data, so it leaves out some retirees, some young people, and some low-income people. Nevertheless, we can glean a lot of information from this single line of data that’s useful in comparing this migratory flow to other migratory flows around the country: for instance, that adjusted gross income per capita among people who pay income tax and moved from Autauga County to Dallas County in 2009 was $10,340. (Household AGI, if you want to make an additional leap to equate a tax return with a household, averaged $23,100.) The IRS only reports these figures for groups of 10 returns or more, in order to preserve the privacy of filers.

Since the IRS data comes in the form of two CSV files per year, it’s best to consolidate all of the data in one place—I uploaded it to a MySQL database that was easy to query when it came time to build the individual county files that underlie the map.

My graphic for Forbes illustrating donations from billionaires to political action committees

I spent part of last summer building a system that parses Federal Election Commission records and, along with my colleagues Louie Torres and Dmitri Slavinsky, a system that helps our researchers link members of the Forbes 400 to political contribution records.

We’ve made that data an important part of our Forbes 400 profiles (scroll down on publisher gnome Sam Zell’s page, for instance, to find a breakdown of his political contributions as well as direct links to original filings). I’ve also visualized it a couple of times: in an interactive graphic last year and in a more focused static graphic this year. The smaller graphic, which shows every contribution by the ten biggest contributors, is more effective at illustrating the point I make in the accompanying article: that many of these contributors are not motivated by ideology but by lobbying power, as evinced by their donations to politicians in both parties (some even contribute to multiple candidates in the same race).

It was fairly easy to assemble the data for these graphics (and for the companion pages in the October 10, 2011 issue of the magazine). The hardest part of writing both graphics–whether in ActionScript for the interactive one or in Python/SVG for the static one–was developing the equation for finding the endpoints of a line drawn between the edges of two circles whose centerpoints and radii are known.

In case it’s useful, here’s the Python function I wrote that will take x and y centerpoints and radius for two circles and return the endpoints of the shortest line that connects their edges. If you’re using Python, be sure to send in your parameters as floats rather than ints; otherwise, you’ll end up with a big jumble of rounded numbers that won’t connect your circles very nicely at all. This is a casewise function, each case being an orientation of the circles relative to each other: circle 1 above and to the left of circle 2; circle 1 above and to the right of circle 2; etc.

import math

#Where x1, y1, r1 are centerpoint x, centerpoint y, and radius of circle 1
#and x2, y2, r2 are centerpoint x, centerpoint y, and radius of circle 2
def getEndpoints(x1, y1, r1, x2, y2, r2):
    #Going through the orientation cases
    if (x1 >= x2) & (y1 <= y2):
        theta1 = math.atan(abs(x1 - x2) / abs(y2 - y1))
        theta2 = (math.pi / 2) - theta1
    elif (x1 < x2) & (y1 <= y2):
        theta1 = -1 * (math.atan(abs(x1 - x2) / abs(y2 - y1)))
        theta2 = (math.pi / 2) - theta1
    elif (x1 >= x2) & (y1 > y2):
        theta1 = math.atan(abs(x1 - x2) / abs(y2 - y1))
        theta2 = -1 * ((math.pi / 2) - theta1)
    elif (x1 < x2) & (y1 > y2):
        theta1 = -1 * (math.atan(abs(x1 - x2) / abs(y2 - y1)))
        theta2 = -1 * ((math.pi / 2) - theta1)

    #The x, y coordinates of one end of the line
    line_x1 = x1 - (r1 * math.sin(theta1))
    line_y1 = (r1 * math.sin(theta2)) + y1

    #The x, y coordinates of the other end of the line
    line_x2 = x2 - (r2 * math.sin(theta1 + math.pi))
    line_y2 = (r2 * math.sin(theta2 + math.pi) + y2)

    return {"x1":line_x1, "y1":line_y1, "x2":line_x2, "y2":line_y2}

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).

Terminal 3, which opened in the 1960s as the Pan Am Worldport and managed to escape the following five decades with only minimal improvement, is now festooned with kite-like leak catchers and a complicated system (series?) of rubber tubes that divert rainwater from the terminal’s crumbling ceiling (a couple of them are shown in the photo below).

Terminal 2, which is connected to Delta’s other building by a sequence of broken moving walkways, has likewise avoided any major upgrades since it was built for some other long-defunct carrier in the middle of the last century (Eastern Airlines? I’m writing this on my phone from a worn seat in a threadbarely-carpeted waiting area, so research is difficult).

Over the last decade, JFK has gone through an impressive modernization process; the pleasant-enough Airtrain whisks me to the airport from the thrillingly-rebuilt Jamaica Station in less time than it takes a bored TSA agent to find a rogue yogurt container. The airport’s other terminals have been rebuilt: first the terminals that serve a motley assortment of foreign airlines, then American’s complex, and then JetBlue’s. If LOT Polish Airlines gets to use a terminal that’s not an embarrassment to New York City, why can’t one of the airport’s hub carriers (and now the largest airline in the world) have one that’s somewhere above Soviet bloc standards?

At the top of his results page are two news articles detailing his latest scandal (in which he apparently contacted a woman who lodged a domestic abuse complaint against his aide).

Below those news headlines are Paterson’s Wikipedia article, the last section of which documents his moribund gubernatorial campaign, and his state government website. Then come two headlines from the Huffington Post, one questioning whether Paterson will resign and another announcing the resignation of the aide involved in the domestic dispute.

Finally, right before Paterson’s campaign website comes a Business Insider article about the rumors that circulated in Albany over the New York Times’s investigation into the governor’s aides.

Things do not look good for David Paterson.

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.