Blindfolded Cartography

This is an adaptation of a talk I gave at the 2015 OpenVis Conference in Boston, expanded in a few spots and abbreviated in others. You can see slides and, ugh, video from the talk.

At Axis Maps, a rough napkin sketch of our projects often looks like this:

Map viewer sketch

We’re tasked with designing and building interactive maps of data that, for one reason or another, we can’t yet see. Sometimes the client doesn’t have data ready soon enough. Sometimes we expect data to change or be added after our work is done. Sometimes it’s just too vast for us to lay eyes on all of it. Whatever the reason, this reality of web mapping is a significant departure from what we knew back in cartography school.

Traditional cartography allows—encourages, perhaps—perfectionism. We were taught attention to detail, and to find and tell the story in our data. Crafting beautiful, effective maps and telling stories with them is one thing when you can obsess over every detail; it’s quite another when you have to do it as though blindfolded. (And I don’t mean sea monsters and mapping unknowns; I mean mapping real things that are known but somehow inaccessible to the cartographer.)


As always in cartography, this is all about making compromises. We make design choices that we know are not are not ideal for most cases, but are at least acceptable for all cases. What follows is a list of some areas where we’ve found the “blindfold” particularly challenging, and some compromises that we or others have found helpful. And an occasional shrug where we haven’t found good answers yet. Much of this is about design, some of it is about code (JavaScript), some of it isn’t even about maps, and none of it is perfect.

Data classification

John Nelson has a succinctly handy explanation and demonstration of why data classification decisions are important on choropleth maps. One way of dividing data into bins can produce a starkly different map from another way, potentially in a functionally and aesthetically bad way.

Data classification example by John Nelson
Data classification example by John Nelson

We want to devise a classification scheme around several questions: Will the map be useful and look good? Are the class breaks meaningful? Are they understandable? Are they pretty numbers? As usual, this isn’t too difficult when dealing with a single data distribution. But we need satisfactory answers to those questions for any data set, without our manual intervention. And real data… well, real data are always messy.

Data in designs vs data in reality

Two common solutions are Jenks optimal breaks, where class breaks are calculated to optimize both grouping and spacing, and quantiles, in which each bin contains the same number of values. Both offer some assurances of visible spatial patterns, but both have drawbacks. For example, optimal breaks can be hard to understand, and quantiles can inappropriately group or split values.

Optimal breaks and quartiles

One compromise we’ve used can be described in two parts:

1. Unevenly distributed percentile breaks. Quantiles are friendly, readable, and somewhat reliable, so we often err toward them. Instead of dividing data into evenly sized classes, though, we might break down some of the classes further to separate or highlight extremes or important breakpoints, for example the top 5% in the histogram below.

A compromise classification

2. Use percentiles of unique values, not all values. Datasets often contain many duplicate values; when quantiles are calculated properly, a single value could span several classes. (A common example is having a whole bunch of zero values.) To avoid weird map legends and to better bring out geographic patterns, we might base our classification on the distribution of only unique values, avoiding duplicates.

// basic example
function getValueAtPercentile( data, percentile ){
  return data[ parseInt( (data.length - 1) * percentile ) ];
// using underscore.js
var dataArray = _.sortBy( [ 0, 0, 12, 23, 2, 5, 0, 5, 19, 0, 0, 0, 33, 9, 25, 0 ], Number );
var uniques = _.uniq( dataArray, true );
getValueAtPercentile( dataArray, .25 ); // = 0
getValueAtPercentile( uniques, .25 ); //  = 5


Expect holes in the data. Assume that sometimes data will be bad or missing. Catch these missing values in code, and, importantly, design for them. “No data” is data too.

Andy Kirk gave a talk called “The Design of Nothing: Null, Zero, Blank” at last OpenVis in 2014, covering (among other things) some no-data scenarios. It’s worth a look:

There are two sides to handling missing data. On one side is code that won’t break if a null value is thrown at it. Basically this means a lot of error handling and bailing out of functions if they’re passed null values. But it also requires some understanding of the data format. A missing value could come through in a variety of ways.

// no data might be...
// &c. &c.

Be careful to avoid the JavaScript gotcha of equating zero with “no data”—usually not the same thing in reality.

// a tempting way to catch "no data" in javascript
if ( data ){
  // yay, we have data!

// but watch out!
var data = 0; // zero is real data
if ( data ){
  // zero won't get us in here :(

The other side is design. One common scenario is missing data in a choropleth map. We like using texture to indicate missing data. It’s distinct, not easily confused with colored values; and it’s explicit, keeping “no data” as part of the story instead of hiding it. If you’re working with D3, check out Textures.js for easy texturing.

choropleth textures

Another common case is gaps in time series data. Again, it’s good to be explicit. Interpolation can be misleading. For example, I like the dashed line in the iOS Health app. It explicitly indicates a gap in data without losing continuity.

iOS health - gaps in data

On maps, one thing we’ve tried is using a special symbol to indicate a gap in data. Below is a frame from an interactive animated map where proportional symbols remain on the map even when there’s no data for the current year, showing the most recent available data but with a different, hollow symbol.

Gaps in time series data on a map


Text in an interactive map setting is more than just labels. Marty Elmer has written nicely about prose on maps, and how it’s ubiquitous yet overlooked. Text, too, can be an unknown part of map data—one that can ruin otherwise beautiful layouts.

The big lesson from experience here is to restrict the space allotted to text. If you’ve designed for a short sentence, assume you’ll be fed a novel, so make sure text doesn’t overflow all over everything. CSS properties like max-height and overflow:auto can help. For shorter labels, truncation and abbreviation (such as via text-overflow:ellipsis may be useful, but also take advantage of what you do know about the data to be clever about this. For example, in the chart below we knew that some labels would be for congressional districts. If we simply chopped off those labels after a few characters, they’d all be the same, so instead we put the ellipsis in the middle and retained the district number at the end.

Label abbreviations

One last thing: mind your number formatting! It’s easy to forget to design label formats for things like singular versus plural or different orders of magnitude, in which case you end up with some funny-looking labels.

Bad number formatting

The Lorem Ipsum Map

All of this, broadly, is about the challenge of designing around missing or fake data. The “lorem ipsum map” is a phrase used by Rob Roth and Mark Harrower (2008), as a caution against designing user interfaces around a placeholder map. In studying the usability of a map we made for the UW-Madison Lakeshore Nature Preserve, they found some negative reactions to the cold, metallic UI (which we designed first), in contrast to the green and fuzzy map (which we didn’t add until later). It’s hard to offer solid advice about this, other than to suggest trying to understand at least the basic nature of the unknown data and what it might look like. ¯\_(ツ)_/¯

Instead of designing around a blank spot, however, we often generate fake data. That of course can be a challenge itself, because how do we design somewhat realistic fake data when we don’t know what the real data look like? Carolyn Fish has a good term for this goal—”smart dummy data“—and an interesting anecdote about challenges she faced trying to make OpenStreetMap data stand in for totally inaccessible (to her) classified data.

All that said, fake data can be an excellent test of code. In some ways, the more unrealistic the better. If the code can handle ridiculous data scenarios, it can probably handle the real data.

The Human Touch

Big picture time. The ultimate goal, really, is to approximate good, human design when we’re forced to do it through rules and algorithms applied to unknown data. I’m going to keep pointing to Daniel Huffman to explain why this matters, at least until he makes good on his promises to follow up on four-year-old articles.

To illustrate how enormous a task handmade design can be in the web cartography age, consider The Essential Geography of the United States of America by David Imus. You probably saw this map a few years ago when a Slate writer declared it “The Greatest Paper Map of the United States You’ll Ever See.” Indeed, it’s a lovely map with tons of manual details.

The Essential Geography of the United States of America

The map is 1:4,000,000 scale, and according to the Slate article, it took nearly 6,000 hours to complete. 1:4,000,000 is approximately zoom level 7 in the standard slippy map scheme. Just for kicks, let’s extrapolate and say David Imus wanted to design a fully multiscale web map (zoom levels 0 to 18) with the same attention to detail. How long would it take him? I’ll spare you the details of my calculation: it’s 2,803 years and 222 days. And that’s only the United States. Im-freaking-possible, in other words. That’s why we need algorithms.

Big Design

This gets into what I want to call “big design.” So-called “big data” isn’t just a computational challenge; it’s a design problem too. How do we accomplish good human design when there’s simply too much data for a human to see?

The problem is perhaps unique to cartography, where at some level we want to see almost every piece of data we have, not aggregates and distillations. For most of us that means a map based on OpenStreetMap data down to the highest detail levels. With 2 million users mapping all over the world, quality and consistency can’t be 100% guaranteed. Our challenge is to come up with design rules that ensure the map looks pretty good everywhere, at all scales. Yikes.

Nicki Dlugash of Mapbox spoke to this very topic at NACIS 2014. To summarize her advice:

  1. Prioritize areas you care about for your specific use case.
  2. Prioritize the most typical or common examples of a feature.
  3. Look for the most atypical examples of a feature to develop a good compromise.

To help you along the way, there are things taginfo, where you can explore OSM tags and get a sense of things like geographic variation; or things like this view in Mapbox Studio where you can inspect many places at once.

Mapbox Studio "places" view

And of course the nice thing about OpenStreetMap is that you can always fix the data if you find problems!

Good Luck

Well, I hope that assortment of tips and problems has been useful. Good luck as you stumble through the dark!

Blindfolded Mercator

Three mobile map design workarounds

We recently built a map for Napa Valley Vintners, a nonprofit trade association with 500+ members located in one of the most well known wine growing regions in the world. The map is meant to help people locate wineries, plan a visit to the region, and then send directions and a trip itinerary to a phone for easy navigation while driving. Two versions of the Web map were developed, one for the desktop and another for mobile phones. We ran into a couple of issues while working on the mobile version, in particular, that were solved with a design workaround or three. They’re relatively small things, but should have a positive impact on how users experience the map.

Browser chrome – minimize before entry

The browser chrome is all the stuff that appears around a window, taking away screen space from what you’re trying to look at. On a phone, when maximized, it usually appears as an address bar at the top and tool bar at the bottom for various things like page navigation, sharing and bookmarking. The bottom bar can obscure content, which isn’t great if you want to use that space for other things, like parts of a map interface, or if you simply want more map area showing on the screen. Typically, the browser chrome minimizes automatically when scrolling down a normal web page via tap+drag down. However, because our map is fixed to the viewport, scrolling down pans to the south instead, and the chrome doesn’t minimize.

What’s the workaround? How do we minimize the chrome so that when users get to the map they as much of it as possible? By forcing people to scroll down a separate introduction page. The page doubles as a loading screen and also includes some branding, a background image, and an attribution line. When the map finishes loading, a big up arrow with the words “Pull up to view map” appears. Pulling up, which scrolls down, sends people to the map with a minimized chrome.


The HTML is structured with a few special elements:

   <div id="loading">
      // 100% width / height
      // loading screen content
   <div id="treadmill">
      // absolutely positioned div with height of 100000%
      // no matter how much you scroll, you'll never reach the end
   <div id="wrapper">
      // div containing all the map content
      <div class="pane">
         // each UI is given its own div

There’s only two bits of javascript you need to get it to work:

$( window ).scroll( function( e ) {
   // wait until the map is loaded to allow scroll
   if( load === false ) return false;

   // check for scroll distance
   if( $( window ).scrollTop() &gt; 100 ) {
      // transition the wrapper into view with CSS
      $( '#wrapper' ).addClass( "visible" );

$( ".pane" ).scroll( function() {
  // prevent scrolling on the UI frames and scroll their contents instead 
  return false;

Of course, it can come back later! For example on our map, entering a search term will maximize it again. Complicated matters, Safari on iOS doesn’t report it’s window height differently when the state of the chrome changes so it’s not something we can detect in code. For this reason, we decided to position key map ui elements, like the winery “list” button, higher in the window so as not to be obscured. Sure, a little scroll from the header would shrink it again, but it’s not obvious.

Geolocation – ask if the browser can ask

Geolocation is great for plotting your location along a route, fixing your location to the center of the map while driving, or plotting a route from your location to a winery. But none of this works unless you first grant the browser permission to track the phone’s physical location. The problem is that the browser only asks once. Furthermore, that request doesn’t tell people the advantages of accepting. If the one browser request is denied, you get none of the good stuff… ever. Or, at least not until you reset your security preferences, which isn’t obvious and is too complicated to explain in a short help message.

What’s the workaround here? How can we 1) encourage people to allow their location to be tracked, and 2) if it’s denied, still ask for it again later to see if they change their minds? Essentially, we did it by asking if the browser can ask for permission in the first place. In other words, we used a custom notification that both explains the advantages of allowing your location to be tracked and asks if you would like to enable GPS. If the custom notification is denied, we can ask again next time… the browser hasn’t blocked anything because it hasn’t asked anything and the user is sent to the map. If the custom notification is accepted, the user is asked again by the browser. Yes, it is an additional click, but we see this as better than the alternative of a user potentially not having geolocation enabled at all.


Data Probe – animation indicates more

Every time a winery point is tapped on the mobile map we display a set of attributes, such as name, address, phone, hours, and appointment details. These show up in a small data probe panel fixed to the bottom of the screen. In addition, the panel includes a button that generates a mapped route and step-by-step directions to the selected winery. Together, the details and button take up all the space available in the data probe panel. A lengthier text description and logo also exist, but flow off the bottom of the screen. This information is accessible by swiping up from the small data probe. The problem was that in user testing no one knew to swipe up and this extra information was rarely even discovered.

We needed a visual cue that would make it clear that more information existed without using up any space in the data probe itself. There was no room for an obvious up arrow here. However, we did find a nice bounce animation at animate.css that served as a good workaround. With each tap of a point, the probe panel bounces up and down a couple times from the bottom of the screen, then stops. It’s a subtle way of showing that more information can be accessed by swiping up.


Swiping up yields the full details for the winery:


Lessons Learned

With a huge push towards responsive web design, this is something we’re going to be doing more and more as users expect to have content tailored for whatever screen they’re using. Mobile maps present a lot more challenges than a standard webpage of long text content. Elements can’t reflow and reposition with a grid scaffolding and some basic CSS width queries and you often feel like you’re fighting against the tendencies of the browser. However, by making mobile design a key part of the total map design process, you can force yourself to think about how mobile users use the map differently; which features are important to them and which should be left for the desktop only. It may feel like building two separate products but the results mean that everyone gets what they need wherever they are.

Device testing

PS – Get ready to buy a bunch of extra phones off eBay because each one is a unique little snowflake which makes testing a nightmare.

Mass Observation Basemap

We recently worked on a project with Adam Matthew Digital mapping British diarists in the UK who wrote during the first half of the 20th century. Most of the 500+ entries deal with observations about the impact of WWII on everyday life.  The map allows users to search and filter diarists by gender and date of birth or view them in smaller groupings by theme (e.g., “Political Opinions”, Women in Wartime”, “London During the Blitz”). Brief bios and excerpts from the diaries themselves are also viewable, as shown in the screenshot of the interface below:


One of the fun challenges of the project was designing a tiled basemap that resembles other maps from the time period in terms of look and feel. We needed something that would help set the tone and mood for the project without using an actual historical map made in the 1940s. Although we’ve used actual historical maps for other projects, in this case doing so would have caused too many accuracy issues around the locations of the diarists. Instead we turned to TileMill, where we brought together modern-day data from OpenStreetMap, the Ordnance Survey, and Natural Earth and applied our own design.


After spending some time online browsing maps made in 1930s-40s England and the UK, such as those out of the British Ordnance Survey, we narrowed down a few of the salient design elements we found. Of course, we saw a lot of variability, but typography seemed to have one of the greatest impacts in terms of evoking the look and feel we wanted. Serif fonts with good contrast between thick and thin strokes were common, as was the liberal use of italic for map labels. Map symbol colors were similarly impactful. They ranged across the spectrum but were generally desaturated and flat on light-colored backgrounds (very few gradients, glows, drop-shadows or other effects). We took note of a few other elements too, like line weights, which tended to be thin (not overly chunky), and line styles, which varied greatly–we found all kinds of dashes, dots and dash-dot combinations.

One other element having a big impact on look and feel was the paper the maps were printed on. Textures in the maps gave the impression of something old and used. They also added a tangible and personal quality, which seemed a perfect fit for our map of diary entries. Of course, tiled basemaps with textures that look worn or folded are not new  (e.g.,  Geography Class map) but we couldn’t resist making a version of our own since it seemed so applicable for this project. Here is a closer look at the paper texture at zoom levels 9-11:

We tried a bunch of different fonts for the map (e.g., Cochin, Magneta, Playfair, Essay) and settled on Latienne Pro in the end. It’s not quite as high contrast as some of the others, but thicker strokes help it hold up well at smaller sizes on screen. And its available on TypeKit!


The color palette we arrived at is made up of mostly desaturated colors that become even more so when made semi-transparent on our light-colored background, as is the case with the national parks (green) and urban areas (yellow) on the map.


Finally, our background texture was made using scanned images of folded paper and cardboard. After a good bit of trial and error, we worked up a seamless version of the image in Photoshop that could be repeated throughout the map.texture

2nd edition of the Boston typographic map

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

Yakkin’ ‘Bout Mappin’

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 effected 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!

Web cartography… that’s like Google Maps, right?

A few weeks ago I was graciously invited by Jeff Howarth to speak to cartography and geography students and faculty at Middlebury College, Dave’s alma mater. I showed some of the work we do at Axis Maps, described our processes, and offered my perspective on what web cartography is all about. The topics were mostly aimed at undergraduate cartography students who may be considering a career path like ours. (While we’re at it, check out some of the student maps.) This post is not at all verbatim but more or less sums up what I said.

The “what do you do?” exchange is always fun for me when meeting new people. When I tell people I’m a cartographer, two reactions usually occur. The first is something like “wow, that’s so cool! I’ve never met a cartographer!” (Lesson: maps make you popular at parties.) Then follows something along the lines of “so what does that mean, like Google Maps?” I then attempt to explain succinctly that yes, sometimes it is kind of like that, but no, it really isn’t.

It’s a little amazing that it’s only taken six or so years for the popular conception of a map—or at least a web map—to become so strongly tied to one type of map, and one exemplar at that. It’s both a blessing and a curse for a practice like ours at Axis Maps, in ways that I hope will be evident as I summarize the way we approach interactive web cartography.


I made a bad map a couple of weeks ago. It showed 24 hours of bus GPS tracks in Boston, colored according to speed.

MBTA bus speed map

Cartographers, trained in their science, would tell me it’s a bad map. It’s a totally inappropriate color scheme for numerical data. It doesn’t generate any clear insights. But the map’s intended audience—the people for whom it was designed—speak differently. It’s eye-catching and novel, it’s reasonably popular, and most importantly it prompts interest and discussion on the state of transit in Boston. Rules and conventions shouldn’t be ignored to the point of misleading or misinforming map users, but just as with wholly “correct” and “useful” maps (which we also try to make!), this particular map successfully accomplished its purpose.

The point is something that seems to define our work and, I think, modern web cartography beyond the general practice of “making maps”: it’s all about purposeful design. Cartographic design is more than visuals and aesthetics; there’s room for the cartographer’s design decisions at every step between the initial earthly phenomenon and the end map user’s behavior.

Daniel Huffman has argued for the human element in cartography with regard to the discipline’s artistic side, and the more I think about it, the more it seems that this is not just about art in cartography; it’s part of what makes a Cartographer something more than a mapmaker. Cartography is about the careful thought behind the design of a map, not just any work (automated or otherwise) that results in a map.


So how does cartographic design play out at Axis Maps? We like to think of a project as three-stage process. We begin by finding out what the client wants mapped and for whom, and then assessing and obtaining the necessary data. Next we develop designs for the map, user interface, and interaction based on the known goals, assets, and restrictions. Finally, in a stage that is labor-intensive but conceptually trivial, we write code to build the map as designed. Without getting too far into the boring details of how we work, I want to mention a few notes on each stage.


Anyone who has tried to make a map, chart, or anything like that will know that working with data is an easily underestimated task. Data come in a million formats and are often messy. Jeremy White, graphics editor and cartographer at the New York Times, has said that when people ask his advice on what software to know for his line of work, to their surprise he answers Excel. It takes at least passing familiarity with a variety of formats and scripts and tools to be prepared. And getting data onto a map isn’t just a matter of using ArcGIS anymore. I haven’t used ArcGIS even once in the past four years.

I’ll say two specific things about data. First, we always take care to obtain a data inventory from the client and to develop a data model early on. The data inventory (a list of everything that needs to be shown on the map) is an important first step before we begin designing anything, because obviously we need to have complete knowledge of the requirements in order to come up with a good design. Similarly, the data model (the way the data are organized, basically) will be necessary to know how to write code that loads and processes the data later on.

Second, all of that matters because complexity of the data and map can vary a lot, and it can’t be unknown when we go to design an interface. The chart below, from a paper by Robert Roth and Mark Harrower (PDF), explains why complexity matters. (It’s talking about interface complexity rather than data complexity, but we find them to be related.) We need to know about complexity and the map’s audience in order to execute a successful design.

Interface complexity vs user motivation (Roth and Harrower)


If there is one clear thing I can say about our design process, it’s that it works like this: mock up EVERYTHING. Everything! We try not to leave anything to imagination. We generate mockups for every interface state, every map view, and every interaction. This usually means a couple dozen screens in the end, showing a step-by-step simulation of a user interacting with the map. We think that locking down all these designs before writing a single line of code is crucial to smooth development and good design. Otherwise we run the risk of cobbling together designs on the fly while writing code, resulting in a messier product.

We’ll always miss a few things, but with enough thinking and discussion we manage to identify most problems before encountering them during development. Our design process, like most I’m sure, is very iterative and involves a lot of attempts and review. Ben, our main Design Guy, draws on experience, conventions, constraints, user feedback, a keen sense of aesthetics, and, I assume, magic to turn ideas into great-looking and smoothly functioning designs. (Maybe he’ll have a chance to describe his methods here sometime.) He notes that there are always a zillion ways to attack a design problem, and for every alternative there is always a better one. We discuss to death possibilities for every little detail until the optimal solution is achieved. Ben’s idea of improvement in design skill is being quicker and requiring fewer attempts to arrive at the best solution to a problem.

FInding the design solution


Writing code takes up the bulk of our time, but in concept it’s almost a formality to us. It’s all about choosing the right tools for the job (Flash, OpenLayers, Polymaps, jQuery, and so on) and then building what we’ve already so carefully designed. We don’t do this work in order to do interesting or novel technological things; we do it to make good maps. If cool technological developments come out of it, all the better, but it’s almost never the main purpose. In my own invented definition of cartography, cartographers are not the ones whose drive is to develop mapmaking technologies. Another related community does that, spending less energy on designing actual maps. It all works well as long as the groups exchange knowledge and each knows what the other is doing.

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.

Our coding steps for the London Low Life map

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. It’s just another skill, not so different from, say, drawing Bézier curves in Illustrator for static work. Nathan Yau’s tale (and his Visualize This book) is a good one to learn from for those who have resisted getting into programming.


After describing the design we do, it’s worth noting that visuals and user experience design are only one part of the overall process of designing a map. Kirk Goldsberry, visiting scholar at Harvard and professor at Michigan State University, recently impressed upon me that design in a cartographic context—broadly meaning the decisions that go into map—is not merely figuring out the visuals, but rather exists in the entire mapping process, something I touched on earlier. Leaving out map use for now, consider the progression from phenomenon to graphic. At one end is the actual thing that is happening, at the other end is the map that represents it. In the middle are data, meaningless in isolation and not to be confused with the phenomenon itself.

Design in cartography

Above are some activities that exemplify the progressions from phenomenon to data, from data to graphic, and the whole thing from phenomenon to graphic. Ideally a cartographer designs the entire process: what data are collected, how they are collected, how they’re organized, how they’re represented, how the map looks, how interaction works, &c. Dr. Goldsberry gave the example of old-timey explorers. They went places, recorded the data themselves for the purpose of making a map, and then they crafted the map itself. They designed everything. Sometimes a cartographer can still own the whole processes, but it’s rare these days, especially in web mapping. Realistically I think most activity falls either between phenomenon-to-data or data-to-graphic, with most of us who call ourselves cartographers existing in the latter category. We work with the data we have, but it’s worth bearing in mind that we’re doing something (i.e., making a map) that the data may not have been meant for, and this can affect our user experience design decisions.


Returning to Google Maps, it has defined not only the layperson’s idea of a web map but also the web mapper’s idea of a web map, it seems. Ever since the early days of Google Maps mashups, the trend in web maps has been basemap + stuff on top. There’s almost always this strict separation of layers—layers that often were not designed to go together, although that part is gradually on the decline. We’ve advanced to the point where pretty good cartography is possible and easy in this framework (thanks to tools like TileMill), but it remains the case that web cartography usually means designing around the tiled Mercator slippy map system, and often using someone else’s tiles, instead of seeking the ideal solution. We all do what’s feasible within technological and time constraints, of course. At Axis Maps we take advantage of the built-in capabilities and user familiarity with standard tiled web maps all the time. But I do sense a risk that “web map” is coming to mean only one type of map, the “things on top of other things” map.

So perhaps my purpose today is to remind us all that there’s more than one kind of web map. Cartography is not Google Maps. It’s not OpenStreetMap. It’s not mashing up geotagged data from various APIs. It’s not rendering tiles. It’s not “geo” (“geo” is a stupid non-word and I wish it would die). It’s not GIS. Cartography is in the thoughtful design of maps, no matter how they are built or delivered.

Representing ‘No Data’ on Interactive Maps

We spend a lot of time determining the best way to represent data given to us by our clients. Whether in the user interface or on the map itself, it’s at the core of what we do. In contrast, I’ve been surprised recently by the amount of time we’ve spent thinking about how to best represent data we do NOT have. Here, I’m talking about places where data was either not collected or not reported. Needless to say, discovering empty cells in a spreadsheet is not at all uncommon, albeit frustrating at times. This is the nature of data collected in the real world. But what is the best way to represent “no data”? It only takes a single missing value to raise the question and present this rather unique design problem.

Below are a few of the ways we’ve chosen to represent ‘no data’ in recent projects when interpolation or other means of smoothing out and covering up missing values was not an option. We feel that instances of ‘no data’ are nothing to hide from or ignore. In fact, in some cases, I’d argue that representing ‘no data’ can be a good thing and actually help to tell a more complete and truthful story about a mapped phenomenon that wouldn’t otherwise be seen.


Proportional Point Symbols

In the Jewish Life in America project for Adam Matthew Digital (project description), we mapped immigration, education, and population data at a number of countries, states, and cities over time to show how change took place. However, not every city has data available at every time slice. For those years when cities had no data, we mapped empty proportional point circles, sized according to the last year in which recorded data was available. For example, in the figures below the map shows that around 1890 Chicago had a Jewish population of 50,000. No data is available for St. Louis for this year, but in 1850–the last year in which data was recorded–we can see there was a Jewish population of 600 people.

Jewish population in Chicago, c1890

Jewish population in St. Louis is not available at c1890. The value at the last available time slice, c1850, is given instead.

Mapping hollow circles at years with no data can be helpful in a few different ways. First, it allows comparisons to be made between every city, albeit across years in some cases. Second, it reduces the distracting “pop-corn” effect of city points appearing and disappearing with each click of the timeline. Third, it shows the spatial distribution of all cities having some jewish population across time. Finally, and perhaps most simply, it makes for a less empty-looking and data-starved map.



For the Children’s Environmental Health Initiative Interactive Map Dashboard, we mapped a range of health, demographic and program data. In the figure below, late pre-term births at the census tract level in Durham, NC are shown. Features with ‘no data’ are represented by a gray fill color, a common technique found on choropleth maps. They can be hidden from the display via a checkbox in the user interface where the number of features without data is also shown.

Tracts with no data are represented using a gray fill color. An interface control counts and hides them.

The same map, but with ‘no data’ features hidden from display.

Places with ‘unstable rates’, although not exactly instances of ‘no data’, do not have big enough sample sizes to make meaningful inferences (as well as having some privacy concerns related to the small sample). Like features with no data, unstable rates can be hidden from the map display and ignored when necessary. However, unlike ‘no data’ these places are included in the map classification and are color-coded (i.e., not grayed-out). By treating each independently, users can refine how they want to display this more empty end of the data spectrum.

The same map, but with ‘unstable rates’ hidden from the display.

Assigning the color gray to ‘no data’ might seem like an obvious and easy choice, however, we’ve had to be somewhat careful in the past. Gray tends to recede and lie lower in the visual hierarchy than other colors on the map, and from a design perspective this can be advantageous in a number of ways. At the same time, this makes it especially important that the different meanings for “gray” are clear to the end user and that it be used consistently across the map and user interface.

While working on designs for the Illinois Public Health Community Map in collaboration with IDPH and IPRO, for example, we found that multiple uses for gray would be needed. In fact, a county on the map could be assigned one of three different gray values, and it was possible that counties representing each type could appear coincidentally. They could be gray 1) because a user zoomed in to a particular sub-region of the state, 2) because a user focused data around certain percentiles with the provided histogram control, and 3) because no data was available in the database. In addition, the health data we were mapping was calculated in several ways (e.g., “Rate of discharge” and “Deviation form Statewide Benchmark”), each requiring a different map color-scheme. In the mockup below of the Western IL health region, out-of-region counties are shown in light gray, out-of-focus counties in medium gray, and a single county with no data is shown in dark gray. To be safe, we chose sequential, diverging, and bivariate color schemes that didn’t include gray so as to avoid any potential confusion.

Mockup of the Western IL health region showing out-of-region counties in light gray, out-of-focus counties in medium gray, and a single county with no data in dark gray.


One feature of the London Low Life Map we produced for Adam Matthew Digital (project description) involves the overlay of historical maps on a modern basemap of London so that both images can be seen together using an opacity control. However, not all of the historical maps were scanned at the same resolution, meaning the extent that zooming is possible can change from map to map. As a simple means of handling maps with ‘no data’ at the higher resolutions, we disable part of the zoom widget when the handle reaches a certain point. Zoom levels that are not available for a selected map are shown, but not clickable. This is similar to what Google Maps does when switching over to terrain from the roads map, although in that case the zoom widget is shortened instead of disabled.

In this map, the zoom track is disabled to represent the limits of available base map data.

San Francisco Typographic Map

HOORAY! The San Francisco typographic map is finally finished and is ready for purchase today. I made a big push to get this map ready for the holidays (with some help from Andy and Ben) and we’re really happy with the way this turned out. More images.

I went a bit overboard and decided to map the *entire* city; The amount of fine detail in this map is pretty astonishing. To fit the entire city onto a poster, of course, means the type itself has to be much smaller to fit it all in. In fact, the street text is half the size of the Chicago map (6 pt surface streets versus 12 pt) so there’s lots of detail for your eyes to enjoy.

GO BIG: Given the crazy density of streets I strongly recommend you get one in poster size (23×34 or up) so you can best see all of the parks, water features, and twisty streets the city is famous for.

WHAT’S THIS ABOUT LETTERPRESS?! Great news, we’ll be offering limited edition, gorgeous letterpress prints on rich cotton paper in the first half of 2011. While we love Zazzle (their prints rock), many of you asked (and begged!) for us to do these as hand-made, limited edition art prints and we thought that was a great idea. Want to be the first to know when they go on sale? Go here.

WHAT’S NEXT? We have New York City (Andy) and Washington DC (Ben) coming up shortly. They look sweet.

Typographic map posters

Today we’re pleased to show off a pet project that’s been occupying us off and on for nearly two years. After some emotional separation issues, we are declaring finished a few typographic map posters—one of Boston, and color and black and white flavors of Chicago. Everything in these maps is made of type.

Chicago typographic map

Chicago typographic map

Boston typographic map

These look good hanging on a wall, so of course prints are available. Check out the page we’ve set up with some more detailed images and links to get copies for yourself.

I began this project with the Boston map, thinking it would be fun to expand the style of my small party announcement map to a full city. The idea caught on here at Axis Maps and soon Mark and Ben had parallel effort underway for a map of Chicago, a city to which several Axis Mappers have some affinity. Ben took the lead on that map, and some twenty months later we both added our respective finishing touches and reluctantly let go.

There was nothing automated about making these maps, unless you count copying and pasting. Everything was laid out manually, from tracing streets over an OpenStreetMap image, to nudging curved water text, to selectively erasing text to create a woven street pattern. The Boston and Chicago maps differ in style, but the end result is similar: from a distance it can appear as an accurate reference map, and as you get closer you notice the thousands of words it comprises.

This has been a fun, if long, process, and we hope other people can enjoy these maps as much as we have. There are only two cities for now, but look for more in the future! Our list right now is San Francisco, New York (Manhattan), and Washington, D.C.

Map Evolution 2

Over the summer, a friend asked me to put together a map of Punta Gorda, a small coastal town in the country of Belize. He works for Hillside Health Care International, a non-profit organization providing medical care in that area. The map was needed to help orient and guide volunteer health care professionals visiting from the States while serving at the clinic. It was to be printed in color on a letter-sized page.

In talking with my friend, I knew right away that the biggest obstacle was going to be getting good local data for the map (and getting it for free, because there was no money set aside for the project). Most importantly, I needed data for local roads (locations and names) and point features (hotels, government buildings, grocery stores, banks, etc.), these being the two main pieces he wanted clinic volunteers to have at their disposal.

Of the big free mapping services, Google Maps had the most complete road network for the town, so it served as my starting point. I had hoped there might be a nice Open Street Map shapefile to work from, but this area is still mostly a blank slate:

View of Punta Gorda in Open Street Map

So, I decided the simplest and easiest approach to getting those roads on the map would be to trace them in Adobe Illustrator. That’s where the remainder of the map design work was planned, and there was no good reason to construct a spatial database or harness the powers of GIS for our purposes, let alone the time and money to do so. We knew this would limit what what could be done with the map in the future, but a simple map illustration existing wholly outside of a GIS served our immediate purposes on the cheap.

The point features were collected in the field by my friend, who personally biked the streets of Punta Gorda and used his local knowledge and that of others who live there to collect and verify the names and locations of streets and places. His work was all done by hand by annotating an early draft of the map. While he was collecting data, I finished the layout and styling. Then, with his annotations overlaid on my working version, I placed markers at each point of interest (red and blue shapes and National Park Service-style symbols), added labels, and created the index that sits in the lower right-hand corner of the map.

Throughout the production process I captured screen shots showing the evolution of the map. When it was finished I sequenced them together to form a simple movie, as I did for the evolution of a map of downtown Madison, WI. Each screen represents about 10-15 minutes of real production work. While this PDF shows the final state of the map, the Punta Gorda movie (see it bigger here) shows how I got there. As you’ll see, it generally involved the transformation of a satellite image into a map by way of a healthy dose of cartographic abstraction and symbolization.