2nd edition of the Boston typographic map

by Ben Sheesley on November 25, 2014

It’s been five years since we first introduced our map of Boston. The popularity of that map started us down a course of typographic mapping that has since expanded to 11 cities. Given the special place that Boston has in our hearts, we felt it was well deserving of a redesign. And to prove just how much we love this city, we started from scratch. In other words, we started at the beginning with a blank canvas, imported a fresh copy of Open Street Map geography and place names, determined a new map extent and layout, and chose new fonts, colors, and character styles. The new Boston, 2nd edition poster is still 24 inches wide by 36 inches tall, but looks and feels dramatically different.


Boston 2nd ed. typographic map

Here are some of the most notable changes:

Extent and Map Scale

The 2nd edition covers a much larger area than the original version. We now include the entire city of Boston, plus a number of surrounding towns. Cambridge and Somerville are still present, of course, but we now extend farther north into Medford and Malden. The extension southward is even greater, covering the area all the way down to Dedham, Milton, and the Blue Hills Reservation.

Fitting more territory on the same-sized poster meant a smaller scale map, which in turn called for some design modifications. For example, because streets were crunched closer together at the new scale we reduced font sizes. The smallest text on the map is that of residential streets — now just 6pt in size. It’s still readable yet small enough to prevent excessive overlap in the denser parts of the city. We also removed the underlying neighborhoods layer that existed in the original version. Again, due to the smaller scale, it cluttered the map and was mostly buried by streets anyway.

Area Features

One of the most visually striking design changes was to the area features on the map, including water, parks and “institutions” (a catch all for universities, airports, or other important not-green areas). Solid color fills behind reversed-out white text gives them a bolder look, compared to the original map. Also, the high contrast between these areas and the white map background gives the map more definition overall and makes some features like small parks, narrow rivers, and jetties, easier to see. Achieving strong figure-ground contrast between land and other area features has always been a challenge with typographic mapping because there is only so much ink that a letter can hold. This method of treating areas with solid background fills seems to help the map visually and functionally while staying true to our aim of covering everything with text.

There are a couple of smaller changes worth noting, too:

Wavy water text

We’ve liked the wavy water text style ever since we first applied it to the Chicago map. Variation in text size, placement along curving paths that parallel one another, and the use of opacity masking to give the appearance of overlapping waves all come together to represent the flow and movement of water better than any other technique we know. We hope the redesigned water text in the 2nd edition map does the same.


Boston is famous for its major underground and underwater tunnels. The 2nd edition Boston map is the first to employ a text style specifically for tunnels. Where highway text goes subsurface, we simply reverse its fill and stroke color. For example, Interstate 90 is represented by purple text with a white stroke but where it becomes Ted Williams Tunnel it is reversed and becomes white text with a purple stroke. I can’t help but compare the bright white tunnel text to the bright lights of cars being turned on as they go beneath the surface.

Below are images of the two maps side by side, each covering an area that is approximately 13 by 13 inches on the printed poster. The 2nd ed. covers a lot more ground in the same amount of space, has a bolder look due in part to its color-filled areas, has wavy water text, and a couple of new headlight-style tunnels. Let’s say goodbye to the original Boston map and hello to the 2nd edition!

Boston 2nd ed. typographic map detail

Boston 2nd ed. typographic map detail

Original Boston typographic map detail

Original Boston typographic map detail

No Comments

AskCHIS NE map: All D3 Everything

by Andy Woodruff on November 19, 2014

Last week saw the launch of AskCHIS Neighborhood Edition, a product of The California Health Interview Survey and the UCLA Center for Health Policy Research, with whom we worked to develop map and chart components for this new interactive tool. The short story of AskCHIS NE is that it is a tool for searching, displaying, and comparing various California health estimates at local levels such as zip codes and legislative districts. Take a look at it if you feel like setting up an account, or you can watch a demo at its launch event (demo begins at 14:00).

AskCHIS Neighborhood Edition

The long story is interesting too, as this is fairly sophisticated for a public-facing tool, so we’d like to share a few details of how the map and charts were made.

We built that big component with the map, bar chart, and histogram. It lives in an iframe, and as a user makes selections in the table above, various URL hash parameters are sent to the iframe telling it what data to load. The map and bar chart then make requests to a data API and draw themselves upon receiving data. Almost everything here uses D3, either for its common data-driven graphic purposes or simply for DOM manipulation. As usual, this much D3 work made it a fun learning experience. And it once again expanded my awe for Mike Bostock and Jason Davies and their giant brains: more than once during this project, I asked about apparent TopoJSON bugs far beyond my comprehension, and each time they fixed the bug almost immediately.

Davies/Bostock mega-brain

Tiled maps in D3

The map shows one of six vector layers on top of a tiled basemap that is a variation on Stamen’s Toner map, derived from Aaron Lidman’s Toner for TileMill project. Normally we use Leaflet for such tiled maps, but our needs for the vector overlays were complex enough that it made more sense to adapt the basemap to the vector layers’ framework (D3) rather than the other way around. Tiled maps in D3 are pretty painless if you follow the examples of Mike Bostock and Tom MacWright. The six vector layers are loaded from TopoJSON files and drawn in the usual fashion in the same Mercator projection as the basemap.

Dynamic simplifcation

The most interesting technical detail of the map (to me, anyway) is that it uses dynamic scale-dependent simplification. This is a nice design touch, but more importantly it ensures that the map performs well. Zip codes need to have reasonable detail at city scale, but keeping that detail at state level would slow panning, etc. tremendously. We took (once again) one of Mike Bostock’s examples and, after some trial and error, got it to work with the tiled map. Here’s a stripped-down example. Simplification is based on the standard discrete web map zoom levels. As the user zooms, the vector layers redraw with appropriate simplification when those thresholds are crossed, with basic SVG transformations for scaling in between those levels. Keep your eye on the black-outlined county in the gif below, and you should be able to see detail increasing with zoom.

Dynamic simplification

Pooled entities

One of the more sophisticated capabilities of this tool is combining geographies for pooled estimates. For example, maybe you want to look at Riverside and San Bernardino Counties together as a single unit:

Pooled entities

The API does the heavy lifting and delivers pooled data; our challenge was to display pooled geographies as a single entity on the map. Although TopoJSON seems to support combining entities (after all, it does know topology), I had no success, apparently because of a problem with the order of points. Instead we use some trickery of masking, essentially duplicating the features and using the duplicates to block out interior borders, as outlined below. If you wonder why we couldn’t just skip step 2, it’s because our polygons are somewhat transparent, so the interior strokes would still be visible if we simply overlaid solid non-stroked polygons.

Combining SVG shapes while preserving transparency

Image export

The biggest source of headaches and discovery was the image export function. Users can export their current map or bar chart view to a PNG image, for example the map below. (Click it.)

Map export

I learned that converting an HTML canvas element to PNG data is built-in functionality, but getting this to work in a user-friendly way was not so simple. For one thing, our map is rendered as SVG, not canvas. Luckily there is the excellent canvg library to draw SVG to canvas, so we build the entire layout above in SVG, then convert the whole thing to canvas (except the basemap tiles, which are drawn directly to the canvas). Pretty cool. Thanks, canvg!

The nightmares begin when trying to trigger a download, not just display an image on screen. Firefox and Chrome support a magic “download” attribute on <a> elements, which does exactly what we want, downloading the linked content (image data, in this case) instead of opening it in the browser. If only everyone used those browsers! Cutting to the chase, we couldn’t find any way to ensure the correct download behavior across browsers without sending the image data to a server-side script that returns it with headers telling the browser to download. The final task was showing a notification while the image is being processed both client-side and server-side, which can take long enough to confuse the user if there is no indication that something is happening. Failing to detect the download start through things like D3’s XHR methods, we ended up using a trick involving browser cookies.


Phew! Turns out making a static graphic from an interactive is complicated! But it was a valuable experience—subsequently I’ve even used JavaScript and D3 deliberately to produce a static map. It works, so why not? (Most of this dot map was exported from the browser after drawing it using this method.)

ALL the D3

For all of the above, it’s hard to post code snippets that would make sense out of context, but we hope that the links and explanations are helpful, and are happy to talk in more detail if you are working on similar tasks. There’s a lot more going on than what I’ve described here, too. Suffice it to say, D3 is a pretty amazing library for web mapping!

No Comments

Offline Web-Maps

by David Heyman on October 30, 2014

Recently I said something silly to a client:

…and because we’re not using a database, you’ll be able to run this map offline on your local computer.

Great! They give lots of presentations where they want to show off the map and this means they wouldn’t have to rely on conference wifi, the most overstretched resource on the planet. We delivered the completed map to be deployed on their site along with the instructions:

Just open index.html in your web-browser and you’ll be up and running.


Did you try Chrome instead of IE?

That ol’ chestnut? Still nope.

Why was it working for me but not for them? We developed this map running the files locally so what was the difference between our machines and theirs?

The Development Webserver

Everyone doesn’t use one of these? If you develop stuff for the web, you most likely have some kind of webserver running on your computer (MAMP, WAMP, LAMP, et al) so when you view a project in the browser, the URL looks like:


The page is loaded over the same protocol used when it is on the web, it’s just not looking outside your actual computer to do so. However, if you just open any old HTML file in the browser, you’d get something like:


This local file protocol means your browser is loading your file without it being initially processed by a webserver, which opens it up to some potential security issues that make the browser say “nah… not loading that guy”. If it’s a really simple page (static HTML, CSS), no problem. It is a problem, however, if you’re running any XMLHttpRequests to asynchronously load data. In D3, these requests look something like:


or any of these. In jQuery, this is the guy you’re looking for:


The Fix

Once I’ve located all the XMLHttpRequests on the page, it’s a relatively simple job to replace them. In this map, I have this block of code that loads a topojson file:

d3.json("json/states.json", function(error, us) {
      .data(topojson.feature(us, us.objects.states).features)

This loads the states.json file and as soon as it is received, runs the function that takes an error and a variable called us. The second variable contains the contents of the loaded file and that’s the important one for what we’re doing.

There’s two changes to make. The first is to open states.json and at the beginning of the file, add:

var us =

This takes the proceeding JSON object and declares it as the variable us, the same variable used in the success function for the d3.json request. Now, delete the first line of the request (and the closure at the end) so you’re code becomes:

   .data(topojson.feature(us, us.objects.states).features)

The new code is still looking for the us variable, but now it isn’t wrapped in the d3.json function that waits for the XMLHttpRequest to finish before executing. It will just run as soon as it gets to that line in the flow of the code. Because of that, you need to make sure that data is available when it gets there.

In your index.html file add the modified states.json file like it was a regular javascript file:

<script src="json/states.json"></script>

before the javascript file that executes the code. Just put it at the top of the <head>, below your CSS files. You don’t need to worry about it slowing down the load time of the page because none of these files are being transmitted over the web.

You now have a set of files that will work wherever you send them. Anyone can open your index.html file in a browser and see your map as you intended.

Some Caveats

  1. Watch out for convenience functions like d3.csv() that have conversions built into them. This method only works for files that are already Javascript objects and can be declared as variables. If you must have your data stored as CSV, you’ll need to alter the file to become one long string and parse it yourself.
  2. The variable you use in the external file will be global. Be careful with that. You can’t reuse any of those variables in your code so it’s worth a quick search to make sure the names don’t come up again.
  3. There’s a reason we don’t load our data like this all the time. It will be slow and gross.
  4. The latest version of Firefox appears to be cool with XMLHttpRequests over file:/// so if you’re lazy, just tell your clients to use that instead.
No Comments

Geography of Jobs: animated mapping with D3

by Andy Woodruff on October 29, 2014

One of our recently completed projects is a new Geography of Jobs map for TIP Strategies. Have a look at it, and read what they have to say about it.

Geography of Jobs

It’s a month-by-month map of job gains or losses over the prior twelve months for most (or all?) of the metropolitan areas of the United States, from 1999 to present. Proportional circles are colored to indicate gain or loss, and the map can either be animated or controlled by moving a slider.

This is a very straightforward project, and we like it as an example of animated proportional symbol mapping using the D3 library. Data are loaded from a CSV file and plotted on a map drawn with D3’s convenient Albers USA projection, which automatically handles Alaska and Hawaii insets. Then we use basic transitions and timers to create animation. The timeline slider uses Bjørn Sandvik’s d3.slider plugin.

Smooth transitions between frames are achieved by tweens (created with D3’s transition method) that are the same length as the frames. Although this may obfuscate specific point values, tweening improves change blindness problems, and is just plain nice to watch. Compare the smooth transitions:


With an abrupt version:

No tween

Perhaps the latter would be easier to interpret numerically, but in general we expect people to retrieve exact values by poking around the map, rather than watching the animation.

In any case, view source on the map if you’re looking for code examples of animated D3 maps!

Geography of Jobs

No Comments

In Defense of Bad Maps

by Andy Woodruff on November 19, 2013

Last month at the annual NACIS conference, I gave a presentation called “In Defense of Bad Maps” — an attempt to demonstrate the value of prolific, popular, yet supposedly “bad” cartography on the web; and to propose a small bit of advice on how to approach cartographic sacrifices in the real, professional world.

This was a last-minute submission, not without occasional regret, and as such there are no especially strong arguments here, but my hope the is that the talk provided one or two things to think about as web cartography continues to grow and evolve. Presentation slides have been posted, but as usual they don’t mean much without the spoken component. Here’s a summarized version.

F tha map police!

Now, I was going for something a little trollish, at least in the title, but I’m too mild-mannered (by day) to go on a true rant, so the provocation—while evident, I hope—is minimal. This is the tl;dr synopsis:

  1. There are “bad” maps on the web, they sometimes become very popular in spite of (or even because of) being bad, and they bother cartographers.
  2. “Bad” does not mean they fail utterly and are without use, however.
  3. All of us commit cartographic crimes, as tradeoffs and sacrifices are part of any real-world job.
  4. We can be wise and responsible in practicing “bad” cartography to good effect.
  5. We should reconsider how we conceive of web cartography, and perhaps break away from the rules of old.

Bad maps

A “bad map” could be a lot of things, but here I’m focusing on four categories, a few of which I suspect are related the potential of a map to become popular among a web audience.

  • Breakin’ the law: Rule-breaking maps are easy to identify and pick on. Mercator projection? More like jerk, hate yer projection, amirite??
  • Lack of design: It’s the dreaded pushpin map, which is the web equivalent of the godawful GIS map with a north arrow the size of a baby. It’s easy to accept defaults and crank out a web map in seconds, but defaults are rarely good across the board.
  • Form over function: Some maps pretend to say something but really don’t—they’re eye candy with no real value added by the cartographer.
  • Code over content: Similarly, there is, uh, the code candy map. A map is presented as something useful and important, but in fact exists mainly as a demonstration of its underlying technology. (This “crime” is perhaps more often committed by the people who promote the map, not the cartographer.)

Who cares?

We care about this because, well, it’s what we do. It’s what we’ve done for hundreds of years. Good cartography has been figured out, and we don’t want to take steps backward. Furthermore, perhaps, we’ve so bought into the idea of maps being powerful that we feel bad cartography may even be dangerous in the long run—or else we just want to assert how important and powerful we are as cartographers.

And, in a point to which I’ll later return, I think we look for bad maps because we don’t really embrace the web; we treat it as an obstacle to overcome. Try to find literature on web cartography that doesn’t give substantial treatment to limitations: screen resolution, colors, projection, and so on. Why did we cheer when D3 came along? We cheered because it allowed us to overcome the Mercator projection, not because it opened up so many new possibilities.

Why we do it

When it comes to deliberate carto-crimes, we make bad maps because of money. A client or boss asks us to do something stupid, and we do it because we like having a job. Or we do something bad but eye-catching, and the attention leads to work. Or we don’t have the budget or time to do a good job, so we do something quick and not so good.

Or, besides money, we make bad maps as part of a process of exploration. We’ve always done this. It’s just that it used to mean printing something out that never left the confines of our cubicles, except in the trash. The web is a much more public and open environment in which we’re encouraged to publish and share our processes, which may include bad cartography.

Bad maps are no big deal

My conjecture is simply that most “bad” maps under-inform rather than misinform. That is, they don’t entirely succeed in their purpose, but they do offer some small takeaway. And, if the sacrifices in cartographic integrity mean that the small message is more likely to reach a wide audience, the map is valuable.

Map message

The open, public exploration process is important, too. Maps needn’t always “say something” but rather can be used to prompt questions and discussion. Having more maps out there, even if many of them are technically bad, inspires us to think about a variety of issues, and additionally drives a sort of design competition that will lead to all-around better cartography.

Wise uses of bad cartography

We can, then, judiciously and wisely practice bad cartography for good reasons. Here are some ways:

  • Know the basics. Yes, you should learn basic cartographic rules and best practices. Ignorance is no reason to do anything. And, in our experience, cartographic expertise is respected. Our clients trust our decisions because of it.
  • Design in proportion to meaning. If your map is meant for a silly fluff piece that intends to do no more than raise a smile for two seconds, then sure, go ahead and make it a dumb non-normalized Mercator choropleth map. If it’s meant to explore a complex and important topic, then give it the proper thought toward good, sound cartographic design.
  • Be clear in purpose. If your map is for exploration or experimentation, let that be known. If it’s a code demonstration, bill it as such. Don’t pretend that a map is saying important things about its subject if you didn’t design it to do so. On the web, we can’t control every context in which our maps appear, but we can give them the right start and help prevent them from being carried away for the wrong reasons.
  • Accept feedback. Nothing on the web is permanent or final, and especially if we are trying new things, we should be willing to change them based on feedback from others. You don’t always have the time or resources to change something after you’ve published it, and yes this is the internet so people are probably going to be awfully rude in their comments, but you can still learn something for your next project.
  • Be smart in responding to client/boss requests. If they request something bad, first try to talk them out of it or propose better alternatives. Try some smart business maneuvers to discourage them or shift the responsibility for the decisions. When those things fail, then give in and do the bad thing. It’s not the end of the world.
  • Choose your battles. Continuing on that last point, prioritize the elements of your design. Not everything is worth defending when a client asks for a change. For example, we’ll give up on the look of UI controls most easily, then non-spatial content, then basemap symbology, and then we’ll most strongly defend thematic symbology. We’d rather have a map be not that good than be wrong.

Moving forward

What I mean to say is that bad maps are nothing to worry about, and are not a plague to fight. But we have a chance for things to be different and better, and to escape the same old types of critique.

Let’s study and understand the use and impacts of web maps specifically on massive, public audiences. What is the actual impact of a “bad” but popular map? What makes a map popular in the first place? I’m looking forward to continued attention on web map use from the academic side of cartography. There’s work from Ian Muehlenhaus on online persuasive cartography, Sarah Battersby on Web Mercator, and even more casual folks like Marty Elmer on viral maps.

Let’s continue to educate users on map reading. I feel confident in my use of a bad map, but maybe that’s because I know maps well. That should not be a privilege. More map literacy means more trust of users, which means less dumbing down of maps because we fear users won’t understand them, but also less fear that “bad” maps will be misused or dangerous.

And, importantly, let’s rethink what web cartography is. We cartographers are in a print mindset, no matter how much we think we are web mappers. The rules of web cartography are a mashing together of a bunch of different things: the principles of print cartography, web design, computer science, statistics and “data science,” and whatever else. Crucially, it’s all founded on cartography rules that were developed for static maps. We don’t need to start over, but let’s at least have a thought exercise: what would web cartography look like if we didn’t base its rules and principles on print cartography? The web is different in so many crazy ways from paper; should the rules really be the same?

web cartography

I used to be in that camp that always says, “there isn’t a new cartography; only new underlying technology.” But I’ve been backing away from that lately. True, at the moment the bulk of web cartography isn’t anything truly revolutionary—it’s only modern means of producing, presenting, and interacting with the same types of displays we’ve always had. (Think choropleth, proportional symbols, etc. We jazz these up considerably over paper versions, but fundamentally the cartography is the same.) But maybe there is a new cartography out there. Maybe our fidelity to the rules of paper prevents us from discovering it. And maybe that’s why born-and-bred cartographers are not the ones leading the charge these days.

Above map by Marty Elmer


Axis Maps Summer Internship

by David Heyman on April 23, 2013

This summer we’re going to try something new by taking on an intern. Here are the details:

What: You’ll be making an interactive map of physician performance across New York. It’s a relatively small dataset covering 120 physician practices and 12 measures focusing on heart care. The map is in partnership with our friends and colleagues at IPRO and will be used to improve the quality of care in New York.
We want you to see the entire process of making a map so you will be responsible for this project from start to finish including:

  1. Working with the client to learn about their data and functionality requirements
  2. Preparing the data to go into the map
  3. Designing the map and UI elements
  4. Building the map in javascript
  5. Testing the map

We’ll be supporting you every step of the way with project planning,  best practices, technical assistance, and design reviews.

When: 8 weeks starting June 17th

Who: We’re looking for anyone looking to sharpen their interactive cartography skills, however, students currently enrolled in undergraduate or graduate programs will be given preferential consideration. To get the most out of this experience you should:

  1. Have experience working with all types of data (spatial, tabular, databases, etc.)
  2. Be somewhat comfortable with map and UI design
  3. Know the basics of building a map in javascript
  4. Be willing to learn all the stuff you don’t know

Where: Wherever you want to be with a computer and internet connection. We all work remotely at Axis Maps and keep in constant contact through Campfire, our group chat system. You’ll be expected to keep semi-regular business hours logged in to Campfire. We’ll have scheduled weekly status meetings (via Skype) dedicated to your project and you’ll be expected to attend regular Axis status meetings as well.

How much: $3,500

To apply: Please send:

  1. Cover letter
  2. Resume / CV
  3. Link to your online portfolio

to David Heyman at info@axismaps.com by May 6th.

1 Comment

Yakkin’ ‘Bout Mappin’

by Ben Sheesley on November 15, 2012

Last week, we made an election map that shows how counties voted in relationship to several different demographic variables. It gave us a chance to take value-by-alpha (VBA) mapping one step further than we did after the 2008 election. Back then, we produced a nice little static map. Our new, interactive map is a bit more substantial, having a user interface, loading data, including a charting component, and displaying a data probe with details on mouseover.

Unlike our typical interactive mapping project, this one was rather small in scope. We wanted to make something that could come together quickly and easily and be seen before people stopped caring about the election. There was also no client, so we were free to work however we pleased in order to get done fast. In other words, no one was telling us that we had to make this work in IE7! All said and done, we devoted twenty-eight hours to the map before sharing it on Twitter.

Because the project was short and received a sustained, concentrated effort from each of us, a behind-the-scenes look at its development seems like it might be of interest to other mapmakers. If nothing else, it serves as an example of how three people, working in different parts of the world, interact together online to get work done. Something for the human geographers out there, at least, if not for the cartographers.

What follows is our Campfire transcript covering the duration of the project. Outside of this transcript, there was no video, voice or other written communication between us. The language here has been smoothed out and edited somewhat in order to reduce each thought, question, or decision to its essence, although there are some direct quotations thrown into the mix.

We think about every project, large or small, slow or fast, client or not, in terms of three primary components: data, design, and code. They are essential ingredients of web cartography and what any aspiring cartographer should learn. To that end, the transcript below has been tagged with colored dots that represent the predominant component in play at any given moment in time, plus a yellow dot for instances when our thoughts were mostly on project planning or management issues.

As you scan through, some patterns to note are:

  1. Entries pertaining to all three components, as well as a basic project plan, are found in the first 30 minutes.
  2. The number of entries about data start out heavy and all but disappear on Day 2.
  3. Entries about code pick up steam toward the middle and end of the project.
  4. Entries about design appear rather consistently throughout the project, with a run of back and forth data-design entries in the middle of Day 1 and a similar back and forth run of code-design entries at the end of Day 2. Interesting!

Planning = Planning
= Data
Design = Design
Code = Code

Day 1 – November 7, 2012

8:15 AM Planning “Want to make a map?” -Dave
8:15 AM Planning “Maybe just this one last time. Then I’m retiring.” -Andy
8:20 AM Design How about an election-by-demographics map using the value-by-alpha (VBA) technique?
8:25 AM Code What’s the best technology setup for this? (Polymaps? CSS?).
8:25 AM Planning Let’s get started this way:

  • Andy: prepare the data
  • Dave: get interactive setup going
  • Ben: put together an interface design
8:30 AM Data I’m exploring election data from The Guardian in Excel.
9:05 AM Data What kinds of demographic data would be worth mapping? Which are affected by geography?
9:05 AM Design What kind of chart should accompany the map?
9:15 AM Design Margin of victory versus demographic variable by county sounds like a decent chart.
9:25 AM Data Here’s a Shapefile with geographic and election+demographic data.
9:25 AM Planning We need to share this file with the world.
9:25 AM Data Let’s explore the Shapefile in indiemapper.
9:30 AM Design We should wait and share this data once it’s all cleaned up.
9:40 AM Data Here’s a second version of the Shapefile with our map data.
10:00 AM Data What’s the best way to store the data? A series of JSON files?.
10:05 AM Data What scale is appropriate for the county boundary data? Will we need to zoom in?
10:10 AM Data There’s no need for detailed, large-scale county data.
10:10 AM Data Let’s store data and geography separately.
10:10 AM Data I’m preparing the data in Google Refine.
10:20 AM Design Anyone have good red/blue color specs?
10:25 AM Design Here are two 5-class sequential color schemes, one for red and one for blue.
10:30 AM Data Looks like there are problems with this data.
“It has Obama winning most of Wyoming handily.” -Andy
10:40 AM Data “In Colorado, that’s showing the Constitution Party candidate!” -Andy
10:55 AM Data I’m fighting with pivot tables in Excel. Trying to get sums into columns instead of grouped in rows.
11:00 AM Planning “Back in a moment… need to go do something to my car before it starts raining.” -Andy
11:45 AM Data Here’s a third version of the Shapefile with our map data.
11:50 AM Design Here’s a VBA map showing county margin of victory by population.
11:50 AM Design Switch to black background.
11:55 AM Design Let’s go with 2-class winners. It’s too hard to see both change in color and alpha.
12:05 PM Design Here are new red and blue color specs.
12:10 PM Design Here’s a new VBA map showing county winner (2-class) by population.
12:10 PM Design “That’s looking pretty okay.” -Dave
12:10 PM Design How is population classified? The map looks kinda bright, making it hard to see population differences.
12:10 PM Design Should we go with equal-interval or unclassed population instead of quantiles?
12:20 PM Data “Argh, this stupid data. Chicago is red!” -Andy
12:25 PM Data For unclassed data, opacity should be a percentage of the max, right?
12:25 PM Design “Los Angeles is ruining it for everybody.” -Dave
12:30 PM Data How about capping the population values at a certain threshold?
12:50 PM Design Here’s a new VBA map showing winner by population, capped at the 90th percentile.
12:55 PM Data What about going with population density instead, in order to control for county size?
12:55 PM Design Here’s a new VBA map showing winner by population density.
1:20 PM Data Here’s the fourth version of a Shapefile with our map data.
“Gave up on Excel, used a Python. Er, Python, not a Python. No snakes involved.” -Andy
1:25 PM Design The user interface mockups are done.
2:00 PM Code Maybe we ought to go with D3 so we can use a map projection.
2:05 PM Design Does using VBA even make sense for mapping demographic variables? What if there is no real correlation between the demographic variable and county winner? VBA might be best for things that are magnitudes or certainty.
2:15 PM Design It’s worth a try. In the end, it’s just a bivariate color scheme.
2:25 PM Data Here’s the final version of the Shapefile with our map data.
2:25 PM Planning Let’s tweet that data.
2:25 PM Data I’m still not sure if population or population density makes more sense here. If we think of VBA as a cartogram, shouldn’t we just map totals?
3:05 PM Design Does this map need a legend?
3:10 PM Planning How should we proceed, now that we’ve got data and an interface design?
3:15 PM Planning What exactly are we trying to make here? A static map viewer? A basic interactive map with data probe and linked chart?
3:20 PM Code If it’s a static map viewer, how about using indiemapper + SVG?
3:25 PM Code There are problems getting a good data probe and chart that way, plus the SVG is too huge.
3:30 PM Code D3 and JSON is sounding like the best approach.
3:45 PM Code The D3 shell is made.
“It was an election day sweep for President Robert Smith of the Goth Party.” -Dave
4:10 PM Code Here’s what it looks like with colored data.
4:20 PM Data The JSON files are ready.
4:30 PM Planning Let’s divide up the remaining work (data probe, data loading, chart, and ui).
4:40 PM Design Let’s put the project data on SVN so it’s easier to work together.
4:55 PM Data Any other interesting demographic variables we should be mapping?
5:15 PM Data Here is poverty:
5:30 PM Data Here is uninsured:
6:10 PM Data Data loading is complete for five demographic variables (birth rate, medicare, poverty, uninsured, wealthy, and non-white).
9:05 PM Design We should go back to quantiles for the demographic data so the maps look balanced with respect to alpha.
9:10 PM Design We probably need non-linear alpha steps to make them look right. Differences should be optical, not mathematical.
9:40 PM Data Can we get data indexed by FIPS code in those JSON files?

Day 2 – November 8, 2012

8:30 AM Design Yeah, let’s do 10-class quantiles for the demographic variables.
8:45 AM Data Get rid of Alaska and Hawaii. There’s no data for those in the source.
8:50 AM Code The 10-class quantile maps are online.
8:50 AM Design They still look too bright overall.
8:55 AM Data Let’s problem solve any data issues. Class breaks and data distribution look okay, at least.
9:05 AM Design Let’s try that non-linear alpha scale to even these out visually.
9:10 AM Design “That’s hella-nicer.” -Dave
9:15 AM Design What kind of instructions will people need to understand these maps? E.g., Brightness is NOT margin of victory.
9:25 AM Code A basic chart is working.
9:25 AM Code How can we easily link the map and chart on mouseover?
9:30 AM Code Try looping through counties to find matches.
9:30 AM Design Here’s a new, cleaner, down-pointing triangle PNG for the user interface.
9:30 AM Code How’s that chart looking?
9:35 AM Code Are the fonts in the mockup on TypeKit?
9:40 AM Design Yep, that’s Ubuntu Regular and Condensed.
9:55 AM Code We need a red and blue PNG for the bars in the chart.
10:10 AM Code The new fonts are in.
10:25 AM Design We need a better way to do the x-axis labels on the chart. They get buried and probably aren’t very clear.
10:25 AM Code Let’s drop in an Axis Maps Logo.
10:30 AM Design Does the page feel too tall? Can we fix that without shrinking the map?
10:40 AM Design Here’s a mockup showing new chart labels.
10:55 AM Code Implemented the new chart label design.
11:00 AM Design Let’s put in an active state for the selected variable text in the UI.
11:05 AM Code Implemented the new active state.
11:05 AM Design There’s a problem with positioning the divider in the new chart labels design. How about a text pipe instead?
11:15 AM Code Implemented chart label tweak.
11:20 AM Design Horizontal page scrolling won’t go away.
11:25 AM Code The scrolling problem is fixed.
11:25 AM Design Let’s give the map a final look over.
11:30 AM Code Let’s stick in a new map title and add some instructions for users.
11:30 AM Design Dang. The page gets cut-off in Firefox.
11:45 AM Code The FF page problem is fixed.
11:50 AM Design Dang. The chart isn’t showing up in Safari.
12:05 PM Code The Safari chart problem is fixed.
12:10 PM Planning Let’s tweet this map to the world!
1 Comment

Mapping Superstorm Sandy

by David Heyman on November 1, 2012

Poking around on Twitter today I saw a couple mentions of this map from ESRI, next in what I’m sure will be a long line of maps about Superstorm Sandy. This was the first thematic map I’ve seen about the storm but it struck me as hugely ineffective. Comparing 2 variables (census statistics vs. storm impact) requires a bivariate map. Mapping one variable and hiding the other one behind a mouse action makes it impossible to see any trends or gain any meaning from the two datasets as a whole. Unless you’re interested in just a couple of counties or having the clicking abilities of a 14-year old Farmville addict, the relationship between the data will be lost.

After manually replicating the data from the map, I put together some quick maps of a few value-by-alpha maps (here’s a stellar though academic introduction from its inventors) using indiemapper. VBA maps were originally conceived to visualize election results by visually-weighting (using alpha) red / blue colored counties by their relative populations. The end result gives you an overall sense of the election by making those counties which contributed more to the result (because of their higher population) more visually prominent.

These maps use the same technique except now alpha is controlled by storm impact. Areas with a higher level of impact are more visually prominent that areas of less impact. These maps hopefully quickly give you an understanding of the population affected by the storm. While I’m sure this was the intention of the ESRI map, because of some misplaced interactivity trumping thoughtful cartography, it can’t say the same.

Median Income


Black Population


Percent Residents on Medicare


Percent Uninsured


Unemployment Rate


No Comments

The Aesthetician and the Cartographer

by Andy Woodruff on October 2, 2012

An ugly map

Sometime around 2006, when everyone and their grandma started cranking out terrible Google Maps mashups, the Cartography world soiled its collective underpants as it looked like the once specialized profession was about to become obsolete. Fear was channeled into outrage at the whole idea of the “democratization of cartography” because it facilitated—encouraged, perhaps—the production of bad maps that ignored everything Cartographers had learned and taught over the years. In other words, “they took our jobs!

Eventually we all calmed down when we saw that people still appreciated good cartography and there was still a place in the world for us—probably even more room for us than before. Then the tools improved by leaps and bounds, to the point now where it’s possible to use them for good web cartography and it’s easy to make maps beautiful. But it might be time to get uppity again.

There is a potential problem in that last thing: beautiful maps. These are prized an awful lot these days, and I’m worried that it’s distracting everyone from the real essence of cartography and the problems that needed or still need to be solved. There seems to be an idea floating around that Cartography is now winning the War on Bad Maps because we’ve defeated Ugliness. TileMill hype is an easy thing to point to here: consider MapBox’s repeated use of the word “beautiful”; or Brian Timoney’s recent, justified praise of the accessibility and openness of TileMill’s newest capabilities, unfortunately framed in the familiar GIS versus Cartography divide that treats the latter as little more than cosmetic surgery, aesthetic touches separable from the rest of the mapping process. Meanwhile with some regularity a web map project seems to find the ultimate “success” of ending up in an art exhibition or winning the Purtiest Map Evar Award.

It all brings into question what Cartography really is (and isn’t) or needs to be in the modern web mapping world, something I’ve been pondering a lot over the past year. (Big-C “Cartography” is used here to mean the the specific profession, theories, and body of knowledge, not simply the making of any maps.) Yes, a good cartographer has graphic design skills and an eye for beauty, but as a discipline and profession it is not about aesthetics.

A beautiful map

Beauty is unquestionably important in cartography. It’s what turns functional maps into good maps and good maps into great maps. And we don’t need to be above putting form over function sometimes. Eye candy sells, and sometimes grabbing attention or being just plain artsy is whole the point of a map. The number of beautiful maps floating around lately, the public appreciation of them, and the proliferation of tools that make them possible are all very pleasing developments. We shouldn’t mistake aesthetics for Cartography itself, though. Cartographic expertise is, in essence, knowing the right way to represent geographic phenomena and data for analytical or various other purposes, and understanding of all stages of the mapping process, not simply knowing how to swoop in at the end and make a map pretty. Sure, we can make every map delicious by wrapping it in metaphorical (or real?) bacon, but it won’t be good for you.*

It’s so much easier to see the aesthetic side of maps than all the informed decisions behind them, and now that it no longer takes specialists to use the production tools and code, aesthetics start to look like the only area where specialized Cartography comes in. We don’t talk about the real Cartography enough for it to be chracterized otherwise. For every blog post or tweet you see about the newest cool graphical capability of Mapnik or d3 or anything else, how many do you see giving advice on when to use it?

Just as we always associated ArcMap with “ugly” and Illustrator with “pretty,” aesthetics continue to be tied to specific tools, and GIS and cartography people still let themselves be defined by the tools they use despite the trends away from reliance on a single piece of software. As usual we have the problem of knowing tools versus knowing concepts. It’s vital to know tools and understand how they work, of course, but in the end they’re only as useful as the operator’s knowledge of cartographic concepts. Today’s tools are new, but a lot of the amazing new capabilities we’re seeing are not new at all; they’re just better implementations. They lower a lot of barriers and have big impacts, sure, but tools are still only tools. BYOCartography.

(When it’s not aesthetics or tools, by the way, it’s the idea that map = data. You can see this in the Apple Maps uproar. But that’s a different kettle of fish for another day.)

I don’t want Cartography to be reduced to mastery of pulling levers to make pretty things. Not because I fear for my career—I can pull levers with the best of them—but rather because it limits the gains in the quality of web mapping. You don’t need to have an advanced degree in Cartography or be an old-school Cartographer to make good maps, but you do need to take the time to understand the when and why of mapping techniques, not just the how.

A map that needs some 'splainin

The traditional Cartographic solution to this kind of problem is to complain and criticize, but we need to point out what’s right more than what’s wrong. (Yeah, yeah, irony here. But think of this post as more of a lament than criticism.) After all, it’s not that bad things are happening—quite the opposite—it’s just that a lot of good things remain invisible and left out of the conversation. So next time you make a killer map, don’t just talk about how you did it; talk also about why you made the design choices you did. Let’s make it understood that there is more to Cartography than aesthetic sensibilities and technical skill, and encourage all mapmakers to be true Cartographers.

* You’ll have a cart attack. Ha!


Advice to the Aspiring Interactive Cartographer

by David Heyman on September 2, 2012

I often get emails from recent geo-grads or new professional students asking something like:

“I’m looking to expand my skills to make interactive maps. What do I need to know to become an interactive cartographer?”

Because our industry is evolving at such breakneck speeds, the required skill sets are constantly changing. Flash actionscript code has been replaced by Javascript and HTML5. Basemap cartography is endlessly tweaked as Mapnik XML instead of Illustrator layers. We can easily build and support our own tile servers. It’s exciting change and it allows us to do more with our maps faster and cheaper.

Unfortunately, if you’re trying to break into interactive cartography and haven’t been involved with its evolution on a daily basis, it can be very tough to know where to begin. It’s no longer as easy as “learn ArcView if you want to be a GIS Tech, or Illustrator if you want to be a cartographer.”

However, while the tools may be changing month-by-month, there have been three broad areas of core competency for all interactive cartographers that have been consistent throughout:

  1. You need to be able to find, manipulate, and store spatial and non-spatial data.
  2. You need to be able to design a functional and attractive cartographic representation of that data as well as the UI controls to operate it
  3. You need to be able to implement that design through code

Working with data is probably the most underestimated part of a cartographer’s job. The steps required to go from source to ready-to-map are different for every dataset, but there are some general tasks you’ll come across at some point. You’ll need to be able to find data, navigating though state GIS websites designed in the 1970’s for administrative boundaries or combing though big data repositories (US Census, World Bank) for a single supplementary attribute. Once you find your data, you’ll need to be able to manipulate it to work with the other datasets required for your map. This is where you’ll put that GIS education to good use but more often than not you’ll find yourself trying to remember how Excel Pivot Tables work. With the data ready to be mapped, you’ll need to decide how to store it and how your map will retrieve it. Simple data can be stored in a text file like CSV (that you’re probably already comfortable with) but more complex data will often require a database. It’s really helpful to know a bit about data structures, and feel comfortable enough with a server to do some basic installation and maintenance.

Design for an interactive map comes in two separate but highly connected pieces. Cartographic design involves designing the “map” part of the map. Most of the design decisions you’ll make during this phase of design are no different than if you were doing cartographic design for a paper map. Is this the right thematic representation of this data? Does my visual hierarchy clearly communicate the message of this map? Is my basemap garish and stupid, drawing attention away from the point I’m trying to make? You’ll also need to design the UI controls to operate the map. This is a much harder skill to cultivate and is most likely something you haven’t been exposed to in your GIS / cartography curriculum. The best way to get to be a better designer is to look critically at lots and lots of web maps. Compartmentalize their interface components and decide for yourself what works on them. Steal the stuff that works and think about how the stuff that doesn’t could be improved. Learn how to quickly make UI mock-ups and wireframes of your map. Iterate over your designs before you build them, using that critical eye you’ve developed critiquing other people’s work on your own. Repeat for 2 weeks or so and then put it down because it’s probably good enough.

Andy said this best:

“Our coding process goes something like this. 1) Load the data. 2) Make things work. 3) Make things pretty. Like I mentioned before, having everything designed ahead of time is vital. We can start with something rough but functional without worrying about design, because we already know how it will look and behave in the end. It also lets us know when we’re finished; interactive projects have a way of never ending if there are no clear goals at the outset.

“After hearing from enough of my cartography peers whose hatred of programming burns with the fire of a thousand suns, I must say this: yes, coding sucks. I write code all the time, and it often makes me want to punch the computer in the face. But it’s worth it. Totally worth it. It only takes a little skill to produce awesome things. A willingness to write some code opens a lot of doors, and it doesn’t require devoting a lifetime to becoming a master programmer. It doesn’t even require being a good programmer.”

If you’re an absolute beginner this is a great place to learn the basics. Then, choose a mapping library that you like (they’re all good) that will do what you need it to do and run through the basic tutorial (usually gets you a basic map on a blank page). Once you’ve got that down, all you have to do is start putting in the hours at the keyboard.

Axis Maps has always been a small company with a very strong DIY ethos (just ask Ben who can now add “shipping tycoon” to his CV). My favorite part of working on projects here is we’re constantly learning how to solve the hundreds of problems that come up through the course of any project. You’ll never know how to do it all yourself but if you give yourself a good foundation in the basic concepts, you can start making maps and learning as you go like the rest of us.

Pirate NG Kids