The Aesthetician and the Cartographer

An ugly map

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

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

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

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

A beautiful map

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

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

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

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

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

A map that needs some 'splainin

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

* You’ll have a cart attack. Ha!

Advice to the Aspiring Interactive Cartographer

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

Four new typographic maps for summer 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!


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 The map is also available on the American side of the pond, of course.

London typographic map

London typographic map


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


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


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!

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

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.


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.


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(',' % 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 = [

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.

Your Map and the Internet

Sometimes it’s important to explain the fundamentals, just to make sure everyone is starting on the same page and to keep expectations in check. Because our heads are constantly caught up in maps and the internet, we sometimes forget that there are a few basic underlying concepts that others (clients, friends, family, etc.)  might not be grasping fully when they use our maps. A better understanding might help them through potential rough spots and frustrations, often simply resulting from a poor internet connection. We found that explaining these concepts with words alone didn’t get the message across very well. Words like “server”, “code” and “wireless” can stick better when accompanied by a picture, as can the broader concepts that surround them related to how computers request and receive code and data for mapping purposes. This is the internet infographic we came up with:



Don’t Panic: An Absolute Beginner’s Guide to Building a Map Server

There are a lot of great mapping applications out there that run on a server. They can be intimidating to install and configure so I thought I would document my steps so everything would be in one place. This a a guide for the absolute beginner so if you have some command-line experience, I promise I’m not being condescending. Future posts will cover how we’re actually using these tools to build our maps.

This tutorial should take you from absolutely nothing to a fully-functional web server containing:

  • PostGIS: A PostgreSQL database optimize to store spatial information. It can easily import shapefiles and OSM data using command line tools as well as connect to mapping services like QGIS and Mapnik.
  • Mapnik: A very powerful tool for automatically generating maps from geographic data with lots of control over cartographic display and rendering.
  • TileStache: A simple way to efficiently serve geographic data to mapping applications. It can send tiled vector or raster data and will speed up any application that needs to load lots of data.

Basic Setup

I’m going to be using a Rackspace Cloud Server for this example. It’s a cheap way to get a server up and running and I’ve found them to be great with support. They automatically build your server and install the operating system. You just need to select 3 things:

  1. Operating System: Ubuntu 11.10 (Oneric Ocelot)
  2. Server Name: tiles
  3. Server Size: 1024 MB of RAM and 40GB of disk

The RAM and disk space are the bare minimum requirements. Fortunately, Rackspace let’s you upgrade your server at any time so it’s easy to configure it small as a sandbox and then beef it up if you decide to put it into production later on.

Once you click “Create server” you’ll see your new root password. Copy it to the clipboard but don’t worry about keeping it super-safe. We’ll change it as soon as we log in for the first time (they also email it to you). Setup will take about 5 minutes to complete and they’ll email you when it’s finished.

Terminal and Remote Access

Since this server is in the cloud (ooooooh), the only way to access it is remotely through SSH. Open any SSH client you like (Terminal is already installed on OSX) and get comfortable. First thing we need to do is to log on to our remote server. Make sure you have that email with your root password and IP address and type into the terminal window:

ssh root@(<strong><em>your ip-address)</em></strong>

That command tells the terminal to start an SSH session, logging in as root to the server at the specified IP address. The root username is the default admin of the server. We’ll do most of this setup as root since it has full control over the system.

When it asks, just paste your root password from the email and you should be logged in and should see something like this:


The # tells you the system is ready to receive commands. Let’s now change the root password into something we’ll remember. Type:


and hit enter and follow the prompts.

Now we want to do a quick software update to make sure everything is secure. Run both of these commands:

sudo aptitude update
sudo aptitude upgrade

We’ll use the sudo command often. It tells the server to perform the task as a super-user which gives you extra permissions to modify the system. Here’s another top-tip: At the command prompt, you can hit the up arrow on your keyboard to cycle through your previous commands.

Installing the Web Server Bits

This part of the tutorial is taken from symana.labs

The next step is to install the LAMP stack. LAMP stands for (Linux, Apache, MySQL, PHP) and has all the basics to turn your server into a web server. It can be installed with a single command:

sudo tasksel install lamp-server

and follow the prompts. To secure the MySQL server from common database attacks, run:


Enter the password you set in the previous step and then enter “n” to keep it. Enter “Y” for the rest of the questions.

If you think you are going to be using MySQL for other applications on the server, you can install phpmyadmin to give you a graphical way to interact with the DB by running:

sudo apt-get install phpmyadmin

When the install completes, we need to modify the Apache2 config file to include information about phpmyadmin:

sudo nano /etc/apache2/apache2.conf

Use Ctrl-V to scroll down to the bottom of the file and add:

# Include phpmyadmin configuration:
Include /etc/phpmyadmin/apache.conf

Press Ctrl-O to save (write out) the file and press Enter to save it in its current location. Then press Ctrl-X to exit editing the file.
When you’re done configuring everything, restart apache with:

/etc/init.d/apache2 restart

To configure a fully qualified domain name for apache type:

echo "ServerName localhost" | sudo tee /etc/apache2/conf.d/fqdn

Now we have to configure the server’s hostname so we can contact it via a URL instead of the IP address. If you enter:

hostname -f

you should see the server name you entered when you setup the server. We want to turn that into a subdomain for our primary domain (for me it will be but you can skip this if you don’t have your own domain (you’ll just keep using your IP address to connect to the server). To tell the server what the rest of the domain is, we’ll need to edit a few text files using nano, the built-in terminal text editor.

sudo nano /etc/hostname

Will show you something like:


You’ll want to change that to:

tiles.<strong><em>(primary domain name).</em></strong>com

We are using for ours. When you’ve edited the file, hit Ctrl-X (not command if you’re on a Mac) then enter Y to save changes and hit Enter to overwrite the file. Do the same thing and add your domain to the second entry in:

sudo nano /etc/hosts

To make the changes stick, reboot your server with:

sudo reboot

The final step is to add a DNS record with your web host that points back to the server. From your server management page in Rackspace, click the DNS tab then click your domain name. Click “Add” to enter a new record with values:

  • Type: A
  • Name: tiles.(primary domain name).com
  • Content: (server ip-address)

By this point, the server will have rebooted so you can log in again with:

ssh root@(<strong><em>your ip-address)</em></strong>

To allow established connections to continue to function:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

To allow SSH traffic:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

To allow HTTP traffic:

iptables -A INPUT -p tcp --dport 80 -j ACCEPT

To allow HTTPS traffic:

iptables -A INPUT -p tcp --dport 443 -j ACCEPT

To allow remote database connections:

iptables -A INPUT -p tcp --dport 5432 -j ACCEPT

Drop all remaining traffic:

iptables -A INPUT -j DROP

Save all the rules to a file:

sudo iptables-save &gt; /etc/iptables.rules

To enable the firewall, we need to add the rules to the network adapter by editing the interfaces file:

sudo nano /etc/network/interfaces

and add the line:

pre-up iptables-restore &lt; /etc/iptables.rules

just after iface eth0 inet static and make sure it is indented like the other lines. Save and exit the file then reboot the server.

This is a good time to create a server backup. In Rackspace, click on “Images” then click “New On-Demand Image” to create a backup of your server. This way, if something goes wrong, you can be up and running again quickly.

Installing PostGIS

Some parts of this tutorial is taken from OpenStreetMap Wiki

To give us access to all the software we’ll need, we need to add an additional software repository. First, enter:

sudo apt-get install python-software-properties

to install the command that will allow us to add new repositories. Then we can add a GIS-specific software repository by doing:

sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable

Now we need to update the system to allow it to pull down the available software from the new repository:

sudo aptitude update

We should be ready to install all of the PostGIS packages with:

sudo apt-get install postgresql-9.1-postgis postgresql-contrib-9.1

Now we need to setup PostGIS to make the newly installed database ready for GIS. Swtich to the database user:

sudo -u postgres -iH

Now we will create a user within the database that can access your maps:

createuser -SdRP gisuser

Enter a password for connecting to the database (it should be different from your root password).

Now we will create and configure a database to hold your spatial data:

createdb -E UTF8 -O gisuser gis
psql -d gis -f /usr/share/postgresql/9.1/contrib/postgis-1.5/postgis.sql
psql -d gis -f /usr/share/postgresql/9.1/contrib/postgis-1.5/spatial_ref_sys.sql
psql gis -c "ALTER TABLE geometry_columns OWNER TO gisuser"
psql gis -c "ALTER TABLE spatial_ref_sys OWNER TO gisuser"

Now we need to configure access to our database first by editing the access file:

sudo nano /etc/postgresql/9.1/main/pg_hba.conf

Scroll down to the bottom of the file and change the words ident and md5 to “trust” (there should be 3). If you want to connect to this database remotely (to view your data in an external manager or view it in QGIS) you should add the line:

# Enable remote connections:
host    all         all             md5

to the bottom of the file and then save and close. You’ll also need to enable remote listening by editing the main configuration file here:

sudo nano /etc/postgresql/9.1/main/postgresql.conf

and change the line:

#listen_addresses = 'localhost'


listen_addresses = '*'

(don’t forget to remove the “#” in front). Save and overwrite the file. To apply the changes, restart the database server:

sudo /etc/init.d/postgresql restart

To test if everything has been installed properly, log into the database as the new user we created.

psql gis gisuser

If you type \d you should be able to see all 3 tables. Then type \q to return.

Installing Mapnik2

Copied exactly from the Mapnik Wiki

To install Mapnik, enter:

sudo add-apt-repository ppa:mapnik/nightly-2.0
sudo apt-get update
sudo apt-get install libmapnik mapnik-utils python-mapnik

That’s it!

Installing TileStache

Some parts of this tutorial is taken from TileStache on GitHub

The first step in installing TileStache is to install mod_python which is the interface TileStache will use to communicate with the web server. You can install it with:

sudo apt-get install libapache2-mod-python

Then restart your web server with:

sudo /etc/init.d/apache2 restart

Now we need to install some more packages that TileStache depends on. First we’ll switch to the directory where we’ll keep the new applications:

cd /etc

Install packages Curl and Git via aptitude to help with the install:

sudo apt-get install curl
sudo apt-get install git-core

Now install some python tools and libraries that are required:

sudo apt-get install python-setuptools
sudo aptitude install python-dev
sudo apt-get install libjpeg8 libjpeg62-dev libfreetype6 libfreetype6-dev

We’ll grab and install PIP to easily install python modules:

curl -O
sudo python

Now install the required python modules

sudo pip install -U werkzeug
sudo pip install -U simplejson
sudo pip install -U modestmaps

The Python Image Library module has some quirks in Ubuntu 11.10 so we need to do some quick fixes:

sudo ln -s /usr/lib/x86_64-linux-gnu/ /usr/lib
sudo ln -s /usr/lib/x86_64-linux-gnu/ /usr/lib
sudo ln -s /usr/lib/x86_64-linux-gnu/ /usr/lib

Before we can install it:

sudo pip install -U pil

Finally we’ll download TileStache from GitHub:

git clone

And install it globally by running the install script:

cd TileStache/
python install

Finally, we’ll have to add the mod_python configuration to tell our web server which URLs to have TileStache process. Start by editing the apache configuration file:

sudo nano /etc/apache2/httpd.conf

and add this:

&lt;Directory /var/www/tiles&gt;
  AddHandler mod_python .py
  PythonHandler TileStache::modpythonHandler
  PythonOption config /etc/TileStache/tilestache.cfg

This will direct any web traffic to the “tiles” folder containing the file extension “.py” to TileStache. We just need to add a tiles directory to the web directory so we don’t get an error:

mkdir /var/www/tiles

Reboot your server to finish it off:


Testing Your Server

Once your server reboots, we can test to make sure TileStache is installed correctly and is running through mod_python and receiving maps from Mapnik.

In your browser, go to:

You should see a OSM tiled map fullscreen, confirming TileStache is correctly installed and running. When you work with TileStache, you can always preview your tilesets at …/tiles/

Now go to:

You should see a simple gray country map which confirms that TileStache is talking to Mapnik, rendering a shapefile stored in the TileStache directory.


Now that everything is installed, you can go nuts with TileStache, Mapnik and PostGIS to render your own tiled maps. We’ll come back to this point in the coming weeks to show examples of how you can actually use these tools to make some maps. Some sample topics might include:

  • Thematic cartography with TileStache and Mapnik
  • Combining raster and vector tiles to optimize mapping for iPad
  • Custom map tiles from OSM data

indiemapper is free

With the start of 2012, we’ve decided to make indiemapper free to use. Since indiemapper launched in 2010, our business has grown and changed to where supporting and maintaining indiemapper is no longer a major part of what we do at Axis Maps every day. We’re making indiemapper free so that it can continue to exist as a useful tool for map-makers while freeing us up to be as awesome as possible at our custom cartography business.

To allow us to give it away for free, we’re scaling back what indiemapper does. We’ve removed all account-based online functionality including usernames / passwords, cloud storage, and map sharing. Everything else, we’ve left as is. The map-making process is still the same except you don’t have to log in AND you need to export your map before you close your browser. We’re also moving our support operations over to GetSatisfaction to let the community of indiemapper users share their knowledge amongst themselves.

We’re really happy about this change and we hope you are too. If you have any questions about the new direction of indiemapper, please let us know in the comments.

Launch indiemapper

“But hasn’t everything already been mapped?”

In a recent post I remarked on the common reaction people have when I say that I’m a cartographer. In my experience people are usually mildly astounded and fascinated by this exotic profession (and just like that we are new best pals), and as the conversation progresses they ask if that means something like Google Maps. But sometimes it’s the most dreaded, annoying question that every cartographer has heard: “hasn’t everything already been mapped?”

There is of course a real answer to that question (perhaps it’s something like, “everywhere, but not everything” or perhaps it’s “there’s actually this one spot in Idaho we haven’t hit yet”), but it’s more amusing to dwell on the things we cartographers hear from our new acquaintances than on what we say in reply. In that spirit, a week or two ago I posed the following on Twitter:

Survey time. Cartographers, fill in the blank based on your experience. Person: “What do you do?” You: “I’m a cartographer.” Person: ______

It generated some excellent replies. If you’re not a cartographer, when you meet one remember that these are things we’ve all heard. If you are a cartographer, please comment to share your experiences too!

@stefanie_gray has heard several good ones.

“You’re a cartographer? But isn’t the map done?!” (Yes, there is only one map! Ever! And it’s DONE!)

“Why would you study cartography if every place has been discovered?” (Uh, did I say I was in ‘conquistador studies’?)

“Hahaha making maps? On the computer? There’s already Google Maps, no need for anything else!”

@wallacetim‘s neighbor doesn’t like his prospects.

“Where’s the money in that?”

@kg_geomapper seems to hang around a mix of high-tech and low-tech map users.

Person: [response always involves mention of either a road atlas or google maps!]

I also get “oh yea, I love old historical maps”

@mapgeek reports a modern twist on the old “hasn’t everything been mapped” bit. Google did it!

“But hasn’t everywhere already been mapped by google?” aargh

She has also, much to my horror, encountered someone who is less than impressed with cartography. And from a geologist at that!

I also got a “god, how boring” response once!

I think he may have been something to do with geology! oh the irony!

@fgcartographix has also found uninterested people (which is too bad, because I usually count on cartography for an easy conversation topic) but also the usual Googlers.

Person: and then changing the subject.

Person: There’s still area to map with Google Earth? (got that one twice…)

@desjardins meets people who have a passing familiarity with a dictionary.

“um, so what does a cartographer do?” or “that’s maps or something, right?”

@NadiiaGorash knows a similar crowd.

Person: WHO?!? Me: …. Person: I see. Mapmaker!

But @nichom finds people a step behind.

Person: < blink> (mental search for what ‘cartographer’ means) Me: I make maps. Person: Cool! (let fun conversation ensue)

@vtcraghead points out that those with good taste (my judgment, not necessarily his) may know about cartography because of Arrested Development.

We are living in the shadow of Buster:

@clubjosh has figured out a good reply to the standard line.

usually get the “hasn’t everything been mapped” line which gets my “Yeah, but some moron keeps changing things” retort

@g_fiske talks to the good ones. The ones who appreciate us.

Person: “Oh, I love maps!”

And @musingbouche is not a cartographer, but knows what to say if she meets one.


Did I miss any? Comment on this post with any other good ones you’ve heard!

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.

New letterpress maps of San Francisco and Manhattan

San Francisco letterpress

Just a quick note to say that we’ve released several new limited edition letterpress prints in our typographic maps store. Check them out, and as always thanks to everyone for the feedback and encouragement in recent months!

San Francisco 2nd edition: This is a new design of the San Francisco letterpress map we made earlier this year, featuring waterlines for a new coastal style. Available in blue or black ink.

Manhattan: This is divided into two maps. A Lower and Midtown Manhattan shows the island from its southern end to 61st St, and Upper Manhattan features Central Park in an extent from 57th to 159th Street. Available in blue or black ink, and individually or paired together.