Cartographer's Toolkit

Map Making Tips, Tricks, and Inspiration

January 6th, 2017

I’ve been using a new vector tile style editor to create some maps. The editor is called Maputnik and is still in early development, but it is usable even at this early stage. I’m really impressed with how much of the mapbox gl js spec has been implemented and the multitude of complex tasks that it makes easy.

Here’s a couple of screenshots from a style I’m working on called Camo:

screenshot1 screenshot2

Creating an Aspect-slope Map in GeoServer

June 22nd, 2016

An aspect-slope map (sometimes called a slope-aspect map) is an overlay of a semi-transparent slope map on top of an aspect map that is styled with a unique hue for every 45 degrees of slope direction. To put it visually:


To do this in GeoServer, you need slope and aspect raster datasets in degrees. Create an SLD for each with the following syntax (I’m not including the whole SLDs here for brevity).


<sld:ColorMapEntry color=”#999999″ opacity=”1″ quantity=”10″/>
<sld:ColorMapEntry color=”#999999″ opacity=”.66″ quantity=”20″/>
<sld:ColorMapEntry color=”#999999″ opacity=”.33″ quantity=”30″/>
<sld:ColorMapEntry color=”#999999″ opacity=”0″ quantity=”90″/>

Here we have a gray color being used to denote very flat areas where the slope is less than 10. The gray is increasingly transparent as the slope becomes steeper, thus revealing the underlying aspect layer with more brightness in the steepest locations. These parameters could be tweaked to allow more or less brightness to show through.


<ColorMapEntry color=”#9AFB0C” quantity=”22.5″ />
<ColorMapEntry color=”#00AD43″ quantity=”67.5″ />
<ColorMapEntry color=”#0068C0″ quantity=”112.5″ />
<ColorMapEntry color=”#6C00A3″ quantity=”157.5″ />
<ColorMapEntry color=”#CA009C” quantity=”202.5″ />
<ColorMapEntry color=”#FF5568″ quantity=”247.5″ />
<ColorMapEntry color=”#FFAB47″ quantity=”292.5″ />
<ColorMapEntry color=”#F4FA00″ quantity=”337.5″ />
<ColorMapEntry color=”#9AFB0C” quantity=”360″ />

The colors and class breaks are from this Esri/Buckley blog entry which, in turn, references the color scheme from Moellering and Kimerling’s MKS-ASPECT (GIS world 1991). The colors, in order, are shown here:




Using a two-layer syntax in the wms request mashes the two layers together. List the aspect layer first and the slope second. I had it switched around on my first try and it took me a bit of time to realize that it draws that second referenced layer on top. And no, the finished map does not have a hillshade underneath. The combination of aspect and slope creates that “hillshade” effect.



Thoughts on UI For Webmaps

April 26th, 2016

Webmap design is a lot different from static map design. Yet, writing a book about webmap design is difficult since the tech is changing so rapidly. (There is a book, called Web Cartography, that is worth having but I still don’t think it goes into everything we want to know.) Indeed, there are a lot of unknowns surrounding the idea of what good UI for webmaps even is.

Some people are using google analytics types of software to analyze how people are using their webmaps (e.g., maptiks) but I don’t see a lot of A/B testing out there, which is probably the ideal way to harness the power of webmap analytics results.

Certainly we can still make some guesses at what works. For example, we can guess that tools and functions that have been on webmaps for at least a certain amount of time, say 5 years, are well ingrained into the public’s knowledge base and probably don’t need a lot of explanation on your map. Zooming in/out, panning, and even the ubiquitous (and not often needed) measure tool are all pretty familiar concepts to most webmap users so they need only be indicated with the usual plus/minus/ruler buttons. Brand-new tools for navigating the map, such as oblique tilts, probably will slow your user down until web GL is more common. These tools may require user education, perhaps in the form of a pop-up info box on first use.

Let’s talk about disclaimers. These could really benefit from testing. Typically, an organization will require a long-winded disclaimer to be presented to the web user before they have even seen the webmap. I’d really like to know how many users leave the site without clicking “agree.” Furthermore, I’d really like to see if clicking “agree” really does hold the organization free from liability in court, or if not having a disclaimer could allow prosecution of the organization for some users’ misuse of the data. My guess is that a reasonable judge would allow neither of these but I’m no lawyer.

What if we A/B tested disclaimers specifically? One site shows the user the disclaimer on the page, and the user has to click “agree” before the webmap will load. Another site shows the disclaimer on top of the webmap such that a faded view of the webmap is visible so that the user gets a glimpse of the webmap. Lots of guesswork here, but the hypothesis would be that the B test would result in more users.

Now let’s take a look at the freshymap. I believe that their use of these three small buttons on the top of the map make it easier for first-time users to pay attention to the main attraction–the map–before they get bogged down in the details–the layers. This one small button can be discovered at some later date, when the user is already familiar with the site.


Contrast that with this Puget Sound Watershed Characterization Project map (that’s a mouthful). Once you get past the disclaimer, which by the way happens to mention a two volume rules guide!, and then figure out how to actually get into the webmap (I’ll let you brave souls go figure that out yourselves), you find yourself on a webmap.

I think you’ll see right away that there are a remarkable amount of superfluous details on what is, essentially, trying to be a cataloging of their data holdings. In other words, it is trying to be all things to all people. We don’t need share, print and find location buttons at the very top of the page. We also don’t need the words “interactive map” at the top of the visual hierarchy (aka top-left) because we already get that it is an interactive map. In fact, that’s something that goes under the category of “user is used to this–we’ve had interactive maps for more than 5 years now,” and there is simply no need to explicitly use up good page real estate in telling them what they already know. The layer transparency slider also being at top-left? Nope, probably not needed, or at least not there.


It’s not a bad webmap at all. It’s actually very interesting once you really take the time to explore it. I do like the basemap switcher on the right (not shown on the above screenshot), which seems much easier to deal with since it has little pictures rather than words (though Timoney states that basemaps switchers are used very little of the time, in one rare case of actual user testing.) I’d just like to see more testing of these things. In a way, it’s a grand place to be in because there’s a lot of room for people to really be creative and come up with some amazing new ways to present webmaps to users that have a lot of potential to really shake things up.

Even the little things can be improved, like the titles we use on webmap legends. For example, I spotted the title, “Explore & Compare” on a legend title today and thought that they were a good choice of words, a call to action for the user, if you will. Again, only some testing would prove if my instincts are correct on that.

Amazonia map hat tip @stamen

Amazonia map hat tip @stamen

Until we get some more expert guidance on this, the best we can do is to keep our eyes peeled for the ways in which people are making webmaps easier to use and try to incorporate the best UI features in our own designs. We can also push back against our bosses or our fellow scientists when they ask for everything but the kitchen sink in one single webmap. Perhaps a series of webmaps for each intended purpose could be proposed instead. Good luck with that.



Adventures in Plant Hardiness Zone Cartography

April 29th, 2015

Yesterday I spent some time looking at hardiness planting zone maps in my pursuit to buy vegetable seeds and starter sets that may  actually germinate this year. My historic gardening flubs aside, I was astonished by the bad quality of the maps that were listed at the top of the Google search results.

The first result for Colorado hardiness zone map is a site called Plant Maps that looks to be “optimized” (this word is used very loosely here) for ad revenue. It is also de-optimized for anything that would resemble a pleasurable experience including the fact that you can’t actually figure out what hardiness zone you are in. Oh wait, yes you can. After much perusal a viewer may finally realize that the colored squares on the left-hand side of the screen are, in fact, a legend of sorts, for the map that resides in the middle of the screen (with a nice vertical ad bar in-between).




Part of the problem with this site is the obtrusive ads, but another problem is what appears to be feature-creep: the insidious and rightfully maligned process that tends to get engineers into trouble. For example, clicking on their last blog entry (notably from 2011) shows us that they last added an interactive map of drought conditions across the United States, when their focus might have been raising the quality of the features that were already present on the site.

If you google plant hardiness zone map without the Colorado bit, you are pointed to the much more official USDA Plant Hardiness Zone page, which by comparison looks downright cutting-edge. But even this one could be so much better.




For starters, I’m willing to bet that their analytics will tell them that most visitors to the site are wanting to view the map rather than read about it. They probably know this, which is why they’ve allowed the map to take up a little more than 50% of the screen space. In reality, though, it should fill 75% or more of the screen space. The USDA logo, the text about how it’s the first time they’ve published a hardiness zone map, the Stay Connected buttons, the six tabs including the Help* tab? They all must go!



Clicking on the individual states pages brings up a new map, as expected, though zooming it to the current map would be better. But here we see that a bad symbology choice has left Colorado looking like blood-shot eyes. Are rivers a necessary addition to the map or could people know what they are looking at without the rivers? I’m going to wager a guess on the latter. Additionally, I wonder if the choice of blue works here, or does it suggest that Colorado will be inundated when the glaciers melt? Just wondering. :)




So when I read the first sentence on Stephen Few’s blog today, it seemed apropos:

We are overwhelmed by information, not because there is too much, but because we don’t know how to tame it.

In the case of the Plant Map website, I think we can conclude that in some ways it must be functional…for the owner of the website, who is apparently collecting enough revenue from its egregious number of ads to make it worth hosting despite the fact that the last update was in 2011. Perhaps this space is ripe for some disruption. A pared-down site along the lines of the wind map**, for example, with a few ads to sustain the maintenance costs and perhaps even provide a modicum of profit for the host would be just the thing.

Maybe I’ll just stick to indoor gardening.


My real-life hydroponic garden / mini-jungle

My real-life hydroponic garden / mini-jungle


*A map meant for the general public that requires a Help section means it’s not good enough.

**The Wind Map gets a higher google ranking (#1) than Weather Underground’s (#4) — which is not too bad but has quite a bit of feature bloat.


Edited to add some additional hardiness zone mapping resources from readers:




2015 GeoHipster Calendar

November 6th, 2014

At Boundless, we put together a nice and subtle world-wide basemap for our new product: Versio. It’s meant to be a basemap that shows you where your data is but doesn’t get in the way, thus the quiet color scheme coupled with ample data from OpenStreetMap.

A stitched together series of screenshots at about zoom level 14 in the San Francisco region provided a good entry for the 2015 GeoHipster Calendar and I’m pleased to announce that it has made the cover.


While I was the main designer for the map, we all know that cartography is only as good as its underlying data, and in the case of dynamic maps, as good as its underlying infrastructure. That’s why the map was really a

team effort by all of the Versio team at Boundless.

A short background on the map in case you’re interested: we used imposm3 to obtain a world-wide OpenStreetMap dataset with a customized mapping.json file that allowed us to get some generalized data for roads and things for the lower zoom levels while still getting the non-generalized data for the higher zooms. We also used quite a bit of NaturalEarth data for the lower zooms, including a raster hillshade for the ocean overlaid with a semi-transparent ocean layer to make it more subdued. Most of the labels are not cached, they are dynamic so that we don’t have any issues with double labels or labels cut off at tile edges. Because we aren’t using too many labels in the dynamic label layer, this doesn’t seem to affect performance. The map was made with most of the OpenGeoSuite components, including–yes, I’ll say it–SLDs that I basically edited by hand. GeoServer serves up the data + SLDs, PostGIS holds the OSM data, the NaturalEarth data are kept in shapefile format, geowebcache cuts the tiles, and OpenLayers shows them off on the webmap.

More TileMill Tutorials

December 4th, 2013

I’ve produced two more tutorials for the TileMill series. We’re still covering the basics here. If you missed the first (badly produced) one, you can look at it here:

That’s One Short Tutorial: TileMill

I promise better production quality in these two follow-ups, produced with camstudio and my nice studio mic. Transcript summaries follow!

While you’re watching, please consider subscribing.


Transcript Summary for Intro to TileMill 2: Adding Layers

Click on the Add Layers box in the lower left of the project window. There are lots of different file types supported by TileMill including CSV, shapefile, geojson, KML, GeoTiff, SQLite, and PostGIS. In this tutorial we use a GeoTiff from of hypsometric tinting (elevation tinting). Natural Earth is a good place to get data if you don’t have any map data yet or if you need to add some data layers to your collection. The data is free.

In the ID box of the Add Layer dialog you name the dataset that you’re adding. (Note: if you don’t put anything in that box TileMill will put something in there fore you.) We’re going to call our layer “Tinting.” That’s how it’s going to be referenced in the code. You aren’t required to put anything in the Class box. The only reason you would use it is if you have several data layers that are all describing the same sort of thing. For example, you could have a U.S. road layer, a Euro roads layer, and a world roads layer. For those three layers you could give them all the Class name of “roads” and then use “.roads” to reference them all at the same time in the code if you want them all to have the same styling (e.g. they all would be black and width=1). We won’t use the Class box today.

In the Datasource box, the only required box, you put the path to the dataset. You can use the browse button to browse for the dataset. Here I’ve just copied and pasted it in. (Incidentally: when I was doing a production level TileMill project a few months ago I had a notepad file open where I would put all these parameters so I could easily copy and paste them in while troubleshooting. Especially nice for the PostGIS tab which has more complex info to put in.)

SRS stands for Spatial Reference System. This is basically the projection that your data is in. You can use Autodetect, which works most of the time. I happen to know that my data is in WGS84, that’s because I took a look at the ReadMe file that came with the Natural Earth data that I downloaded and it told me that the projection was WGS84.

We’re going to leave the Advanced box empty and click Save & Style. If you just click Save, it’s not going to style your data for you in the code. So it’s a little easier when you’re just starting out to press Save & Style. And then magically you’ll see that it’s put my layer in the layer list and it’s also referenced in the code right here with some default styling. It’s also covered up the rest of my data with this greenish color. You can see the data a lot better if I zoom out, then you can see the hypsometric tinting dataset that I downloaded.


Transcript Summary for Intro To TileMill 3: Adding Comments

In this tutorial we’re going to start off with the hypsometric tinting layer showing, that we added in the previous tutorial, and learn about how to add comments to the code. The code on the right is called CartoCSS. Knowing how to comment things is pretty important.

Let’s start with just a basic comment. In part of this code I have a “marker-allow-overlap” parameter set to “true,” which is an uncommon thing to do. So you might want to make a comment to the effect of why you overrode it. It’s pretty easy to do, you just use a forward-slash star combination at the beginning of the comment and a star forward-slash combination at the end of the comment so it looks like this:

/*Override the default layer*/

Another reason that you might want to comment the CartoCSS code is that these stylesheets can get very long. You can visually separate different sections of the stylesheets by putting in section separators like this:


Whatever you put in between the /* and */ is just a comment. Another reason you might want to comment is to put a nice looking header at the top so that people understand who wrote it, when, and whatever other metadata information you want up there.


* PetersonGIS

* 12/4/2013


A fourth, very commonly used, reason to comment is to get rid of data in the map without actually deleting the styling. So if I want to make the hysometric tinting dataset not show up in the map but still have the CartoCSS code for it in the stylesheet, I can go ahead and put that /* and */ to comment it out. This is great for debugging when you aren’t sure what is breaking the map. The comments can help you figure out what’s going wrong. Also, if you’re going to be exporting slightly different maps to different customers, you can comment out map layers prior to rendering the tiles. (Note: you could also do this another way, by clicking the eye icon next to the layer name in the layers dialog, which effectively makes it disappear without actually deleting it or the code.)

Cartographer's Toolkit

Map Making Tips, Tricks, and Inspiration