Cartographer's Toolkit

Today a few of us decided to create a new organization called Emotional Cartographers Anonymous. While I am decidedly not an emotional cartographer–in fact there was another faction arguing for a Rational Cartographer’s Guild or some sort that I would be a reasonable fit for–I think it would be rather fun to attend an ECA meeting. I imagine there would be lots of shouting concerning the acceptability of halos on labels, old-school vs. new-school color schemes (think light vs. dark), and of course an open source vs. proprietary discussion in which someone inevitably brings up child labor. Or something.

And when we’re done with the meeting we can all gather around and have some map cake, which won’t make us upset at all.

All kidding aside, I also managed to publicly declare today that: You really have to understand the infrastructure underlying your map to be an effective cartographer. This statement received a fair bit of attention on twitter. The reason I’m pointing it out is that it may seem like a departure from my oft-repeated stance that to be a good cartographer you have to learn the fundamentals of cartographic design independent of the software tools.

If you think about it though, these are not two opposing ideas. It is true that excellent cartography is based on a sound foundation of basic principles as well as application of both analytical and creative forces to the data and design. None of that has to do with software and shouldn’t be constrained by software.

If you want to create a certain visualization that is perfect for your purpose and you don’t have the ability to do that within your normal day-to-day software then you should seek software that does offer that functionality (or, if you’re a dev type, build it). In other words, I don’t have to teach software in order to teach cartographic principles.

Figure-ground differentiation, label-font hierarchy, balance of margin elements, choropleth color maximums, and many other principles remain the same regardless.

However, what I perhaps have not emphasized enough is that there’s also a need for the cartographer to understand exactly how features and maps are created, stored, styled, modified, updated, and published in order to have a maximum of control over stylistic changes. In short, if you can’t operate your map stack technology then you’ll be relying on others to do it for you, which will represent a significant delay in getting edits published. It also leaves a gap in your knowledge of what the possibilities/capabilities of your stack are.

So, learn cartographic principles. That’s key. Also learn data analysis, general design, and creative skills. Finally, learn your software, whether that’s traditional desktop GIS or an entire map stack comprised of a map server, a statistics package, a web mapping client, a tile cacher and so on.

This is a lot and you probably can’t be an expert in all of it. In fact, team effort is fully warranted, particularly if you are serving up complicated maps. For sure a lot of speed is garnered from a team that has a server expert, a styling expert, a design expert, a front-end developer, and so on. But a cartographer should be familiar enough with all these pieces to be able to at least ask the right questions and coordinate the experts to provide a substantial, informative, and timely map product.