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.

Nope.

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:

http://localhost/...

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:

file:///Users/...

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:

d3.json()

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

$.ajax()

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) {
   map.selectAll("path")
      .data(topojson.feature(us, us.objects.states).features)
      .enter()
      .append("path")

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:

map.selectAll("path")
   .data(topojson.feature(us, us.objects.states).features)
   .enter()
   .append("path")

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:

Tween

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

5 Comments

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

Income

Black Population

Black

Percent Residents on Medicare

Medicare

Percent Uninsured

Uninsured

Unemployment Rate

Unemployment

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!

7 Comments

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

5 Comments

Four new typographic maps for summer 2012

by Andy Woodruff on August 7, 2012

Our typographic maps store took a little summer vacation last month and has now returned with some big postcards of the four cities it visited: London, Philadelphia, Seattle, and Minneapolis. Perhaps you’ll enjoy them yourself!

London

Our maps have ventured outside the US for the first time, to everyone’s favo(u)rite summer 2012 city. With that, we’ve launched a UK store for orders (pre-orders for the moment) there and internationally at store.axismaps.co.uk. The map is also available on the American side of the pond, of course.

London typographic map

London typographic map

Philadelphia

Or celebrate American independence from London in the Cradle of Liberty. We’ve got Philly’s astoundingly dense network of streets and, of course, a nod to Rocky.

Philadelphia typographic map

Philadelphia typographic map

Seattle

Grab your coffee and your 90s grunge music and head to the west coast. This watery Seattle map will show you where to hang out.

Seattle typographic map

Seattle typographic map

Minneapolis

In the summer, enjoy the parks and lakes in this city on the upper reaches of the Mississippi River. In the harsh Minnesotan winter, wrap yourself in this map for warmth.

Minneapolis typographic map

Minneapolis typographic map

More maps are coming soon. Stay tuned!

1 Comment

The ‘Why Not The Best’ map: thematic mapping with Leaflet

by Andy Woodruff on July 31, 2012

We’re pleased to mention our most recently completed project: an interactive quality-of-health-care map for Why Not The Best, done in conjunction with IPRO for the Commonwealth Fund. This is actually the second incarnation of this map, which is now built with more modern technology and is better integrated with the Why Not The Best site.

Why Not The Best map

We first built the Why Not The Best map in Flash about two years ago, using the Flex-based indiemapper framework we had developed for ourselves. Flash was a good solution the time, as this was a relatively simple vector thematic map. However, the map’s functionality and features later grew to the point where it incorporated multiple shapefiles, several layout modes, and embedded Google Maps—resulting in a very complex project and a large SWF for users to load. At the same time, non-Flash web mapping technology was improving rapidly, opening new doors for building this kind of map. As such we again worked with IPRO and completely rebuilt the map in HTML 5 and JavaScript.

We’ve learned a few things from this and similar projects and thought we’d share some experiences from this map, in case other folks just getting into this kind of work can benefit from the same tricks.

Leaflet

The web mapping library I’ve settled on as my choice lately is Leaflet, which is developed by CloudMade. Leaflet offers “slippy map” and overlay basics but also a lot of opporunity for easy custom extensions. While there is little built-in support for thematic cartography like choropleth maps (although the very recent release makes more strides in this direction), it’s not difficult make it happen in completely custom ways. Below is an overview of what we did in this case.

Choropleth

Our choropleth map, in brief, is drawn from tiled GeoJSON served by TileStache and colored by data requested from IPRO’s database. Although I suppose it will be part of the Leaflet release some day, there’s currently no built-in support for tiled GeoJSON layers; however, as you’d expect with an open-source project, third-party developers have come up with solutions. We used this TileCanvas layer with some additional modifications.

GeoJSON is commonly drawn to SVG, but just as we learned long ago in Flash, a ton of vectors rendered on screen at one time can really bog things down. We wanted to try the canvas element instead, rendering the vector data as static rasters and faking the mouse interactivity that SVG would have allowed. Sure enough this did seem to perform better, especially when we needed to draw our county layer in high detail. Thus the GeoJSON TileCanvas layer, which builds upon Leaflet’s canvas layer, was handy.

To make this all work interactively and allow on-the-fly coloring based on data, we had to perform a couple of behind-the-scenes tricks. The main technique was introduced to us by our friend Jeremy White, a Graphics Editor at the New York Times whose fantastic interactive work you have undoubtedly seen and who has explained this in a couple of talks. Basically, it’s this:

Canvas choropleth: behind the scenes

Beautiful, right? This green thing is a map layer that ordinarily is invisible underneath the actual choropleth layer. It draws each enumeration unit (counties here) with a unique color based on a unique ID number for that unit. That number could be its position in an array, or in our case an arbitrary number included in the original shapefile (again, though, it’s just the row number of each record). On a canvas element we can’t do much more with the mouse than detect the coordinates of the mouse position and the pixel color under the mouse. By assigning colors this way, we can read that pixel color and turn it back into the ID number, thereby learning which county is under the mouse.

Unique colors for canvas choropleth

Our method for assigning colors, also more or less following Jeremy’s tips, was to use the red and green channels, each of which has 256 possible values. It works like this for my county of residence, which had an ID number of 1222:

  1. 1222/256 = 4.77. We only want the integer for this part, so Red = 04.
  2. 1222 mod 256 = 198, or in hexadecimal, C6. Green = C6.
  3. Blue = 0.

In other words, we just run down the sequential list and increment the green value by 1 until reaching maximum green (255), at which point red is incremented by 1 and green rolls over to 0. In our code, a feature’s color looks like this: "rgba('+Math.floor(feature.properties.ID/256)+','+feature.properties.ID % 256+',0,1)"

Having detected a color on the map (#04C600 here), we can reconstruct that ID number.

  1. Red = 04. 4 * 256 = 1024.
  2. Green = C6 (198). 1024 + 198 = 1222.
  3. Looking at our data, we find that 1222 is Middlesex County, Massachusetts.

The blue channel is not used at all for the counties and is instead reserved for drawing borders between them. Some confusion of pixel color can happen where two or more counties come together, sometimes appearing as a totally different color that belongs to a unit elsewhere. We draw blue over the borders as a kind of buffer. If any blue is detected while moving the mouse around, we know that it’s very close to a boundary and we don’t try to discern a county. Using only the red and green channels in this manner, 65,536 unique colors—and thus unique map units—are possible. If the blue channel were also used, it would be more than 16 million.

Our map doesn’t actually store a list of the all the counties and ID numbers. Instead we store the JSON attribute information along with the geometry on the custom TileCanvas layer. On a county mouseover, we loop through the features on the tile to find which one matches the ID number of the detected color. That way we know both the attribute information and the geometry, allowing us to display the name, etc. and also redraw the choropleth tile with a yellow highlight added to the correct county.

Proportional symbols

Marker symbols in general are easy to implement in Leaflet, but using them thematically is not straightforward. For one thing, it’s difficult to maintain an association between the symbol and the data that it represents. Again, though, it’s not hard to extend Leaflet’s capabilities, so we just added our own modified type of marker layer that allowed us to pass in data to control the symbol size and label. We shied away from SVG here too and used div elements for the symbols, something which was also just introduced in this week’s new Leaflet release. The CSS border-radius property can be used to make circles.

Proportional symbol divs in Leaflet

Multi-scale mapping

Even though raster basemaps tend to be designed for multiple scales (often 18ish unique scales), it’s easy to overlook the importance of doing this for vector data in web maps, too. Our map needed to work from continent level all the way down to street level, at 15 or so scales, half of which include the vector choropleth layer. We ended up using three levels of generalization, thanks of course to MapShaper.

Generalization at different scales

Beyond good practices, generalization was important for performance. Note the file sizes on the image above. At the smallest scale, all of the country is visible, meaning we need to download and render all of the vector data. If we didn’t generalize the geometry, that would mean the whole 13MB!

Each of the three generalization levels is a different layer in TileStache. Rather than implementing three separate layers in Leaflet, we added a couple of methods to the TileCanvas layer to allow for several different source URLs, automatically switching between them as the zoom level changes. We could give it an object like this and not worry about it thereafter:

var countiesURL = [
{url:tilestacheBase+'counties-smallscale/{z}/{x}/{y}.geojson',min:0,max:4},
{url:tilestacheBase+'counties-medscale/{z}/{x}/{y}.geojson',min:5,max:7},
{url:tilestacheBase+'counties-largescale/{z}/{x}/{y}.geojson',min:8,max:20}
];

Thematic web maps: getting better!

There’s much more to the new Why Not The Best map than has been described above, so go check it out. To say nothing of the many design challenges, these were just a few of the most interesting technical challenges, which, thankfully, Leaflet and TileStache made it pretty easy to solve. (Now if only it were as easy to avoid the Mercator projection in choropleth web maps!) It’s been a good experience in learning how non-Flash web mapping libraries have improved for thematic cartography, even if they don’t support it natively. If you’re new to this, check out the Leaflet documentation and tutorials, as well as TileStache and our blog post tutorial on how to set up a tile server.

1 Comment