Cartographer's Toolkit

Map Making Tips, Tricks, and Inspiration

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

That’s One Short Tutorial: TileMill

October 14th, 2013

Everyone and their brother has been asking for TileMill tutorials. I have zero time for a full-on, production level, quality video series. Sorry. :( But I do have time for a 1 minute long, cell phone attached to a tripod made of Legos, weird screen glare, introduction! Hooray!

I went for the non-screencast format in favor of the friendlier, “I’m actually here” format. If we produce a whole series then we’ll have to switch to a screencast where you can see the screen better. And I’ll have to take that bad*%( microphone down from the top of the bookshelf. Until then…

Digital Map Wrongs and Rights

September 25th, 2013

Murphy’s Law: What can go wrong will go wrong.

Let’s count the ways that your digital map can bite the dust.

1. Labels get cut off at tile seams. (Increase map buffer area.)
2. Effects at land/water boundary don’t work if the two datasets lack topology. Mouths of large rivers and canals? (Use data that was built to work together like Natural Earth.)
3. Layering isn’t correct. Trailhead symbols underneath park shading. (Do lots of testing and moving code and stylesheets around as needed.)
4. Symbols not appearing. (Remember to include them in the right folder and call correctly. Hello.)
5. You forgot to normalize thematic, population-related data. (Normalize.)
6. Line widths aren’t changing incrementally. When you zoom in they just get bigger and bigger until pretty soon the entire map is one road. (Specify a different line-width for every zoom level or groups of 2-3 zoom levels.)
7. Lines are jumbled or too thick at low zooms. (Generalize the low-zoom data. Simplify the lines using a simplifying algorithm.)
8. All features show up but with no styling, all black and Arial and width = 1. (Re-code, nesting isn’t working right.)
9. You published it but nobody cares. (Remove half the functionality and increase the prominence of the central purpose.)
10. You published it and everybody cares but in the wrong way. (Remember the most vocal voices are not always the majority opinion.)

Zoom Levels, Pixel Sizes, and Scales, Oh My

September 9th, 2013

Ever wondered what the map scale is at each zoom level in a digital map? Well, it’s not an easy answer, since almost all webmaps are in the Web Mercator projection (some are in Web Mercator Auxiliary Sphere), which has a greatly varying scale depending on your latitude.

The varying scales of a Mercator projection:

Assuming a 96 DPI*, we can translate the zoom levels to map scales and pixel sizes, and for the sake of simplicity they have been recorded only for locations at the equator. Here’s the very useful Esri chart for this. Obviously these will change depending on how far from the equator your features are. But it is a good start to get a handle on, say, what datasets will look good at what zoom levels. For example, you might want to use some Natural Earth large scale data that comes in 1:10m resolution. You’ll see from the chart that it will look good through zoom 6.

The Esri chart is, like I said before, quite handy. However, you might want to see just approximate scale equivalents as you go about looking at various datasets and plotting which ones are good at which zoom levels. Incidentally, if you’re doing an exercise like that, I highly recommend making a data chart in a spreadsheet and putting these values across the top, horizontally, and then xing out or coloring the squares that correspond to each dataset’s resolution. This gives a handy visual way to scroll through 100+ datasets to see what resolution they have.

REMEMBER these are just APPROXIMATE scales for each zoom level. Not only does it vary by latitude but these have been significantly rounded:

zoom approx. scale
0 1:500m
1 1:250m
2 1:150m
3 1:70m
4 1:35m
5 1:15m
6 1:10m
7 1:4m
8 1:2m
9 1:1m
10 1:500,000
11 1:250,000
12 1:150,000
13 1:70,000
14 1:35,000
15 1:15,000
16 1:8,000
17 1:4,000
18 1:2,000
19 1:1,000

You’ll note that in the Esri zoom level document they also wrote out how many meters, at the equator, one pixel is. Why would this be at all important? Simply put, if your features are less than one pixel in size, this may have implications for how much of that data you show and how you style it. For more on that and some other very interesting dot styling information, see Eric Fischer’s excellently illustrated Mapping Millions of Dots article.

*See this post on why I/we/everyone shouldn’t be assuming 96 dpi. Required reading!

Zoom Level Design, A First Attempt at What to Teach

August 22nd, 2013

So I’m going to do some writing on zoom-level design techniques or tactics for digital, interactive, mapping on devices. I figure this is one of the biggest issues we face as cartographers of digital map products so it merits quite a bit of in-depth instructional material. However, that kind of material hasn’t really been written up in a systematic way that I know of yet. We’ve got some guidance on it over at Mapbox (Styling for zoom levels) but not much else.

These are some of the topics that I think should be covered, but I am sure there are more:

  • How to create and use a zoom field in your data. This would be a tutorial on, for example, showing only the larger cities at larger zoom levels and adding in smaller cities as the user zooms in. To do this you have to specify both the zoom level that the user has clicked on as well as specify what data to grab using the zoom field. So let’s say you have a zoom field in the data called “zoomlevel”, you’d have code that looks something like

    [zoom<8][zoomlevel=1] {styling for cities with zoomlevel of 1}

    [zoom>=8][zoomlevel=2]{styling for cities with zoomlevel of 2}


  • How to incrementally change the styling based on the zoom level. So your line styling for road widths might increase by .5 at each  zoom level, for instance. Along with this is the idea of best practices. If you are using the same width for all road lines at zooms 3 through 5 you could just denote it in one line of code such as

    [zoom>=3][zoom<=5] { styling }

    This has the benefit of simplifying and lessening the length of your code. But it might be better to separate it out into different lines so that you can go back in and tweak the styling more easily (I prefer it this way as long as it doesn’t get too long):

    [zoom=3] { styling }

    [zoom=4] { styling }

    [zoom=5] { styling }


  • I think there should be some tips on how to test as well. For example, I’ve found that testing figure-ground separators (land/water halos) at zooms 3 and 4 is easiest when looking at small islands, because then you can really see if you are completely obscuring the land or not with your halo. Other testing tips* might include making sure you pan around to find where the seams are in the tiles to ascertain whether or not labels are being cut off, and what to do if that occurs.


  • Including a nice table on how zoom levels relate to map scale would be handy for the reader too.


  • Guidelines on which common map features might be best to show at which zoom levels. Maybe this would also be a table that shows, for example, that local roads should show up at zooms 12 and higher. Of course, these would just be guidelines for those who need to construct quick maps, not standards to adhere to at all costs.

This is just a start. Please, if you have anything to add that will help those who are just beginning to create digital maps, things that you wish you had known from the get-go, let us know in the comments!

* Could be a whole chapter of itself. Especially if you open the can of worms called “unit testing for maps”. Which is sorely needed. Anyone having information on techniques for that or links for us please share.

Learning Digital Cartography

May 15th, 2013

A reader recently asked what he needs to know to be a digital cartographer. It’s a potentially complicated answer because there are a lot of emerging technologies in this space. What I might recommend now could be superseded by something else as soon as 6 months from now. Given that, I wouldn’t hard-code (so to speak) the advice that follows. Instead, keep your learning flexible and explore all paths that it leads you down. For now, here are some tools/technologies you can familiarize yourself with as you seek to become a digital cartographer extraordinaire.

Note that I’m not getting into a myriad of datasources and haven’t even touched on the design portion of cartography, which in no way diminishes the importance of those. Also note this is just one pathway of many possibilities.

The list is particularly heavy on OpenSreetMap but the associated tools are good to know regardless. A combination of these tools could be used in a classroom exercise. In no particular order:

*There is some controversy surrounding these tutorials. However, I’ve still found them to be useful. If you have alternative tutorial suggestions please post them in the comments.

Cartographer's Toolkit

Map Making Tips, Tricks, and Inspiration