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.

THOROUGHLY DELIBERATE, PURPOSEFUL DESIGN

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

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.

DATA → DESIGN → CODE

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.

Data

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.

Design

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.

Code

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.

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.

WHERE DOES DESIGN BEGIN?

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.

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.

WEB MAPPING, or PUTTING THINGS ON TOP OF OTHER THINGS

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.

Recently, we took on a nice little print mapping project for a few hotels located in downtown Madison, Wisconsin. The project involved making a one-sided, page-sized map showing hotel locations and the locations of a few points of interest in the area. The idea was that hotel guests could use the map to find their way around downtown as well as get a sense for where they were staying in relation to the university, interstates, airport, etc. The map was to be printed in grayscale, plus 3 spot colors (red, yellow, and blue).

Before starting out, we discussed the possibility of sharing the project with those interested in seeing all the stuff that goes into designing a map like this. The map design process is notoriously difficult to articulate and we’re keen on the idea of making pieces of it more transparent, where possible. One option was to screen capture the hotel map as it appeared in the production software at regular time intervals from blank page to finished product. So, here is a sequence of 116 images, originally captured at 10-minute intervals, compiled to show the evolution of the hotel map in just under 2 minutes. Clearly, not all maps are made in the same way, but this should expose some of the kinds of design decisions made in a relatively simple project like this.

Watch the larger version of Map Evolution (990 x 766px) — best for seeing change in map details.

After posting our election map last month, we received a number of excellent comments and suggestions. It’s late, but I thought I’d finally post the couple of variations of the map that I’ve managed to find time to put together. The maps below do two things differently from the original:

• Vary the brightness of counties by population density rather than total population. This was a frequent suggestion. I think it has a few of its own drawbacks too, but it looks pretty good.
• Different color schemes. Just for fun, I’ve used the purple color scheme that has become common in recent elections. I also liked the suggestion in one comment to saturate colors by margin of victory, so I’ve done that too. In these, full blue would be total Obama domination (Obamanation? Obamadom?), full red would be the same for McCain, and gray is an even split.

No snazzy posters this time. Just a few map snapshots.

First, the original colors mapped by population density, as posted in the comments on the original post.

The purple color scheme. First by total population:

And by population density:

Margin of victory by total population:

Margin of victory by population density:

Apologies for any trouble seeing the images. It’s tricky to find a brightness that will look right on every screen.

When we were building GeoCommons Maker! one of the key map design challenges we faced involved producing semi-transparent choropleth maps. Choropleth maps are perhaps the most common type of thematic map and are regularly used to show data that is attached to enumeration unit boundaries, like states or counties. Ever seen a red state / blue state election map? This is a basic choropleth. There are a lot of more sophisticated ways that choropleths can be made to best represent a given data set, for example, by playing around with classification, categorization, choice of color scheme, etc., but we won’t get into those here.

I want to talk about color. Traditionally, choropleth maps are read by looking at the general pattern of unit colors and/or by matching the colors of specific map units to a legend. Other reference data is often removed from the map because it is either, 1) not necessary to communicate the map’s primary message or 2) makes communicating this message more difficult. It could be argued, for example, that other reference map information, like green parks, gray airports, brown building footprints, and blue water distract readers from seeing the general pattern of choropleth colors on the map, which is where the map’s most important message can be found.

For GeoCommons Maker!, we wanted to allow people to make a kind of hybrid, semi-transparent choropleth map that would show both thematic data (colored choropleth map units) AND the rich reference information on popular map tiles (e.g., Google, Microsoft Virtual Earth) without sacrificing map reading and interpretation ability and confidence. We believe that there are lots of times when reference and thematic data can work extremely well together to really benefit a map’s message (e.g., a soils map that shows terrain or a vegetation map that shows elevation). So, we wanted to build this functionality into Maker!, and allow people to make maps that show the best of both worlds.

The Problem with Transparency

The fundamental problem with transparency is that the color of semi-transparent map units can shift due to the visibility of color that lies beneath them. This is not at all surprising, but can make the basic legend matching task difficult, obscure the pattern of color on the map, or just as bad, make patterns appear out of nowhere. Here’s a look at what happens to colors using the same semi-transparent choropleth map units on different backgrounds. These are screen captures from early design mock-ups for Maker!.

The first image shows (hypothetical) opaque choropleth map units with a 7-class color ramp. The next three images show the same units at 50% opacity on top of Google terrain, streets, and satellite imagery. Notice how colors shift when compared to the opaque map at top? See how lightly colored units nearly disappear on the streets map, and darkly colored units nearly disappear on the satellite map? Yikes!

Mock-up of an opaque, 7-class choropleth map for Maker! (Google terrain)

Same mock-up, at 50% opaque (Google terrain)

Same mock-up, at 50% opaque (Google streets)

Same mock-up, at 50% opaque (Google satellite)

The Solution to Transparency

We employed three design solutions to ensure that semi-transparent choropleth maps in Maker! would work, despite potential map reading problems: 1) unit boundaries, 2) data probing, and 3) transparency control.

1) Unit boundaries. In Maker’s choropleth maps unit boundaries are color coded but remain opaque, even when unit fill color is semi-transparent. This gives map users some true color information to work with, and should improve their ability and confidence to spot map patterns or match colors to a legend. In other words, while unit fill colors can get you close, unit boundaries can get you the rest of the way there.

Screen-shot from Maker! showing opaque choropleth unit boundaries

Corresponding legend for the above map

2) Data probing. We also took advantage of a relatively common and very helpful interactive map feature known as data probing. Exact values for any choropleth map unit can be obtained by clicking on them. In Maker!, we designed the data probing feature to go one step further and give values for all of the possible attributes associated with each map unit, not just the mapped attribute alone (see the scrolly list, shown in the probing pop-up below).

GeoCommons Maker! Data Probe

3) Transparency control. Finally, we gave mapmakers a transparency control, as well as a chance to take some responsibility for how well their maps communicate. The transparency control lets mapmakers decide what works and what doesn’t. Given the huge range of possible maps that can be made with Maker!, some user controls like this are necessary (as well as being kinda fun!). Here, transparency can be adjusted for a custom fit with any chosen tile set, color scheme, or other mapped data. Settings on the control (shown below) range from 50-100% opaque.

Screen-shot from Maker! showing the transparency control

The Best of Both Worlds

Our decision to include semi-transparent choropleth maps in Maker! should give mapmakers and map users the best of both worlds. A semi-transparent choropleth is truly a hybrid map in that it can potentially offer all the advantages of combining rich reference data (i.e., underlying tile sets) with great thematic data (i.e. overlying choropleth units). Hopefully the choropleth maps coming out of Maker! will be easy to read and good looking, too!

Update, Dec. 22: A few variations of the map technique are posted here.

We spent some of our spare time last week exploring data from the 2008 presidential election and thinking of some interesting ways to visualize it. Above is one map we put together.

One thing we sought to do was present an alternative to cartograms, which are becoming increasingly popular as post-election maps. Cartograms are typically offered as an alternative to the common red and blue maps showing which states or counties were won by each candidate, wherein one color (presently, red) dominates the map because of the more expansive—but less populated—area won by one candidate. Election cartograms such as the popular set by Mark Newman distort areas to reflect population and give a more accurate picture of the actual distribution of votes. A drawback of cartograms that we’re very aware of, however, is that in distorting sizes, shapes and positions are necessarily distorted, sometimes to the point of making the geography virtually unrecognizable.

Our map is one suggestion of a different way to weight election results on the map while maintaining correct geography. What we’ve done is start with a simple red and blue map showing which candidate (Republican and Democrat, respectively) won each county in the lower 48 states. Then, to account for the population of those counties (or, the approximate distribution of votes), we’ve adjusted opacity. High-population counties are fully opaque while those with the lowest population are nearly invisible. Against the black background, the highest concentrations of votes stand out as the brightest.

We’ll let viewers be the judge of its cartographic effectiveness, but we hope you’ll at least agree that it looks pretty cool!

Click on the image at the top of the post to view a larger version, or see it in a Zoomify viewer, or download the full size (suitable for printing).

I love ColorBrewer. All of us here at Axis rely on it almost daily and it’s helped us to make nice looking maps quickly; and that’s what good tools do, they make their users look really good at their jobs.

7+ years later, ColorBrewer is due for some changes and Cindy Brewer has been kind enough to ask us to hold the scalpel. Nothing major. Same great color schemes (of course), but a new interface and some new functionality to help ColorBrewer’s 2000 visitors per week get the most out of the experience.

We’re in the early stages of planning this project but we though we would open this up for some discussion amongst the ColorBrewer-using, Axis Maps Blog-reading masses.

QUESTION: What would you like to see in the new version? What should remain untouched? What do you love? What do you wish was done better?

Let us know your thoughts in the comments. Thanks!

This is an exciting time to be a cartographer. Cartography has changed more in the past 5 years than in the previous 50, and the field is in the midst of an unprecedented revolution that has forever altered what maps can do, and how and why we use maps. How far have we come? I now see teenagers using on-demand, customizable maps rendered in real time from multiple, distributed data sources on their cell phones that automatically geotag and upload photos to their blogs while they sit on the bus. Five years ago, heck, one year ago this would have been science fiction, now it’s just a collection of geoservices on a $200 phone. As a result, mapping technology has quickly outpaced mapping theory and practice.

While much attention has (rightly) been focused on the technology that is enabling these amazing advances  (Google Earth, mash-ups), I think the equally significant change is why people are making maps and the role maps now play in our everyday lives.

Take “pocketcasting” for example, the next step in social networking, where folks geo-broadcast their locations so they can see where their friends are at any given moment allowing unplanned meetings (“I’m at this cafe!” as a kind of mass, voluntary, geo-voyeurism). This adds a degree of instantaneous spatial awareness to our social lives that would have been impossible without the serendipitous convergence of technologies like GPS, wireless networks, and customizable on-demand maps. Other new ways the public is using maps include monitoring traffic conditions in real-time or using Google’s wonderful streetview to check-out a potential new home virtually. One thing is clear: Maps have become fully integrated into the fabric of our lives in ways we couldn’t have imagined a few years ago.

Beyond the popularity of these maps, however, has been the complete blurring of the distinctions between map maker and map reader, data provider and data user. It is precisely this tectonic shift in the world of cartography that underlies the philosophy of GeoCommons Maker!, the product we’ve been jointly developing with the powerhouse team at FortiusOne, described by the O’Reilly Radar as “a Flickr/Swivel/YouTube/Scribd of geodata.” Maker is at the vanguard of the democratization of cartography and the promise of Web 2.0 services that eliminate the need for expensive software/data for most casual ‘citizen cartographers’ and allows people to make great looking maps quickly while guiding them through the process. We here at Axis Maps feel strongly that powerful tools (e.g., desktop GIS) aren’t much good if they don’t provide guidance – it’s like giving the keys of an F-16 to someone who doesn’t know how to fly. Furthermore, while an F-16 is amazing, few folks actually need one. Same with $30,000 mapping software.

One of the reasons we like Maker! is that it empowers people – who otherwise would never be able to participate – to make their own maps and start publishing, sharing, and commenting on geographic data and the things we learn from those data. High-end, professional cartography is not going to disappear, and the world will always need premium map products (such as National Geographic Atlases or legally-binding land surveys). The same is true of professional authors and photographers; neither blogging nor Flickr have eliminated the need for these professionals, rather they have opened up these activities to a much larger group and drawn people into the process, rather than relegate them merely to being spectators to the process.

One thing is clear: As the GeoWeb/Web2.0 revolution continues, we need to move beyond paper map thinking and starting seeing maps much more broadly as services that can be integrated with other services. As a professional cartographer this means to me that the “rules” of cartography established through a century of study and practice are now up for grabs at the very moment mapping finds itself in a multi-billion dollar spotlight from both the private and public sectors. Some of the biggest companies in the world (Google, Microsoft, Yahoo!) are betting a big chunk of their digital future on maps and the central role they want cartography to play in their digital empires. With the backing of these companies, digital, on-demand maps have gone from technological curiosities to everyday tools worth billions of dollars. This begs the question: Where is mapping headed and what might our maps do for us in 10 years?

Further questions we need to think carefully about (these are the sorts of questions that keep us up at night!!)…

• How much of what we have learned about static maps—both in practice and theory—holds true when these maps become animated, interactive, and customizable?
• What are the relative merits of 2D versus 3D?
• How do we keep users from becoming disoriented and lost in 3D immersive maps?
• What are the perceptual limits of animation and for what kinds of map reading tasks (e.g., rate estimation, change detection) are animated maps especially well-suited (and how could those tasks be better supported)?
• How can we reduce the problem of “split attention” in immersive and visually-rich environments like Google Earth?
• How can we create intelligent Web-based software that is both easy to use and powerful? To what degree can the map-design process be automated to further the democratization of map-making? How can we help novices to think like experts?
• What should our map interfaces look like and why? How does the map interface structure the user’s experience? How do we know if our map interfaces work?
• Who benefits from these billions being invested in mapping?
• How does this technology change the way we do business and the way we interact with each other?
• What are the limitations and liabilities of decentralized data structures and technologies that run on volunteered geographic data?