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

by David Heyman on January 15, 2012

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@(your ip-address)

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:

root@tiles:~#

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

passwd

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:

mysql_secure_installation

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 tiles.axismaps.com) 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:

tiles

You’ll want to change that to:

tiles.(primary domain name).com

We are using tiles.axismaps.com 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@(your ip-address)

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 > /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 < /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"
exit

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         0.0.0.0/0             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'

to

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 https://raw.github.com/pypa/pip/master/contrib/get-pip.py
sudo python get-pip.py

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/libjpeg.so /usr/lib
sudo ln -s /usr/lib/x86_64-linux-gnu/libfreetype.so /usr/lib
sudo ln -s /usr/lib/x86_64-linux-gnu/libz.so /usr/lib

Before we can install it:

sudo pip install -U pil

Finally we’ll download TileStache from GitHub:

git clone https://github.com/migurski/TileStache.git

And install it globally by running the install script:

cd TileStache/
python setup.py 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:

<Directory /var/www/tiles>
  AddHandler mod_python .py
  PythonHandler TileStache::modpythonHandler
  PythonOption config /etc/TileStache/tilestache.cfg
</Directory>

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:

reboot

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: http://tiles..com/tiles/tiles.py/osm/preview.html

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/tiles.py//preview.html

Now go to: http://tiles..com/tiles/tiles.py/example/preview.html

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

Finished

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
5 Comments

indiemapper is free

by David Heyman on January 5, 2012

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

10 Comments

“But hasn’t everything already been mapped?”

by Andy Woodruff on December 15, 2011

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: http://www.youtube.com/watch?v=tj7RlQdF25A

@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.

cool!

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

15 Comments

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

by Andy Woodruff on December 5, 2011

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

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

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

THOROUGHLY DELIBERATE, PURPOSEFUL DESIGN

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

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.

DATA → DESIGN → CODE

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

Data

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

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

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

Interface complexity vs user motivation (Roth and Harrower)

Design

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

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

FInding the design solution

Code

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

Our coding process goes something like this. 1) Load the data. 2) Make things work. 3) Make things pretty. Like I mentioned before, having everything designed ahead of time is vital. We can start with something rough but functional without worrying about design, because we already know how it will look and behave in the end. It also lets us know when we’re finished; interactive projects have a way of never ending if there are no clear goals at the outset.

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.

WHERE DOES DESIGN BEGIN?

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

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.

WEB MAPPING, or PUTTING THINGS ON TOP OF OTHER THINGS

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

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

8 Comments

New letterpress maps of San Francisco and Manhattan

by Andy Woodruff on August 11, 2011

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.

1 Comment

Representing ‘No Data’ on Interactive Maps

by Ben Sheesley on June 13, 2011

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

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

 

Proportional Point Symbols

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

Jewish population in Chicago, c1890

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

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

 

Choropleth

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

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

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

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

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

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

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

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

Basemap

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

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

3 Comments

Cantabrigian Namesakes

by David Heyman on June 3, 2011

Andy’s made a great looking map of small-multiples showing the breakdown of how streets were named in Cambridge, MA. Those of you familiar with the area will have fun trying to recognize the highlighted streets. Everyone else can marvel at how useful the small-multiple technique is at making easy comparisons across a complex dataset.

Cantabrigian Namesakes

No Comments

The Furniture District

by David Heyman on May 6, 2011

Over on the Bostonography Blog, Andy is muses about the spatial arrangement of humorous retailers in Cambridge. It’s inspired by The Simpsons and has some great looking maps (like the above) from GeoCommons.

The Furniture District

No Comments

London Low Life

by David Heyman on May 5, 2011

This week, we’re happy to begin a 30-day preview of one of our most distinctive interactive mapping projects: The London Low Life Map. This map was produced for Adam Matthew Digital, a digital publishing company based in the UK. Adam Matthew produces digitized archives of historic primary source documents, collected around a central theme, for higher education institutions. This map was built as part of their London Low Life collection that explores the seedy underbelly of Victorian London. It examines the documents of sex, drinking, gambling, and the institutions that sprang up to combat those very vices. As the map is integrated into Adam Matthew’s collection, we will only be able to grant access to our readers for 30-days. I encourage you to explore the map and enjoy Adam Matthew’s fantastic collection of historic maps and images. Since we’ve pulled the map out of the collection, I wanted to give you some context on what is included.

View the map >>

London Low Life-2-2

Historic Basemaps

The full London Lowlife project gives users access to a mountain of primary source documents from Victorian London, so it only makes sense that we start with maps made of greater London during this era. We’ve included some metadata with each of these maps (author, date, publisher) to give historical context and placed them on top of a custom Cloudmade basemap (with adjustable opacity) to give some modern context as well.

London Low Life-3-2

Taking these historical maps from raw image to geographically accurate overlay was an incredibly intricate procedure. While some maps existed as single, contiguous images, others were scanned in their current forms as pages, separated by fraying canvas. Before we could rubbersheet the maps to OpenStreetMap data (with the help of the UW Cart Lab), we had to manually remove the seams and align the resulting image fragments to one another. Furthermore, because these maps were at different sizes and scales, we had to build a system that would identify maps with limited resolutions and restrict the zoom levels available on the fly.

standford1884.tif-1-2

It’s fascinating to view the changes in the street maps over time, especially which streets were given primary status then and now.

Tallis Streetviews

In the mid-nineteenth century, John Tallis drew detailed views of the fronts and façades of buildings along Central London’s streets. Originally designed as a “visual yellow-pages” (businesses would pay to have their shops labeled), his 88 plates now survive as a first-person perspective into the streets of Victorian London.

London Low Life-4-2

We wanted to make these plates as immersive as possible. With the help of AMD’s editorial staff, we took Tallis’ original image and added some color to sharpen the images, shadows to depth, and a blue-sky background to increase the realism of the images. Finally, the images were run through Google Sketchup to create the perspective views that place you in Victorian London and allow you to look down either side of the street.

Be sure to click the “view original” button to see the original plates to view the intricate detail surrounding the street images.

Thematic Data

While the historic basemaps and Tallis Streetviews of the London Lowlife map attempt to provide insight into the qualitative aspects of Victorian London geography, we also wanted to explore the changing character of the population through quantitative thematic mapping. Simple demographic measures like population and density can provide a major insight into the nature of a city. However, we believe the most telling indicator of life in Victorian London, and certainly true to the name “low life” ascribed to this project, is the explosion in social services that sprung up throughout the city to deal with the new urban population.

London Low Life-5-2

By dragging the timeline to view an animation of the entire century, you can watch population increase in various sections of the city and then the services emerge to try and meet the need.

Victorian London

The final section of the map gives a taste of the larger London Lowlife project by placing a selection of the primary source documents on the map. It’s an engaging way to explore city by viewing some fantastic records of the landscape and people of Victorian London.

London Low Life-6-2

Mouse over a category point on the legend list to quickly highlight all corresponding points.

View the map >>

1 Comment

New typographic maps of Washington DC and New York

by Andy Woodruff on April 26, 2011

DC and NYC typographic maps

Earlier this month we launched our new store with two new typographic maps we had been working on since last autumn: Washington, DC and New York City (Manhattan). These 24×36 inch posters, along with the existing line of cities, are now done in super sharp detail as offset prints, and all are now found at the new store.

In addition to the new cities, we also released limited edition letterpress prints of San Francisco, which managed to sell out almost immediately. We’re now looking into future letterpress editions of this and other cities.

So if you haven’t checked it out yet, have a look at our typographic maps store and all five cities for sale:

As always, thanks to everyone for all the encouragement and support we’ve received for this project!

2 Comments