Cartographer's Toolkit

Map Making Tips, Tricks, and Inspiration

Cartonotes, random

June 12th, 2018

I’ve been up to my eyeballs in map styling lately. There’s the project for GeoServer that is currently at 18 SLD styles and then there’s the project involving 50+ layers in a mapbox gl js style. Stuff I’m dealing with on a daily basis:

  • Knowing the data inside-and-out. For the two styles mentioned above, there’s a, shall we say, intimacy one must have with the data in order to get anywhere fast. For example, how are the roads broken down by type? Depending on the dataset it will be different. OpenStreetMap data can vary depending on how you’ve downloaded it but in most cases you’ll have motorways, trunks, primaries, secondaries, tertiaries, tracks, cycleways, links and tunnels and bridges. Do not forget to use the tunnel and bridge codes! If you’re styling in a rural area and get those roads looking just fine you may not have even thought that as soon as you zoom over to a place with tunnels and bridges–Manhattan is a great test-place for this–that it doesn’t look the way you want it too. There are differing strategies for those tunnels and bridges. You might use a bolder casing for the bridges and a dotted casing for the tunnels. This is just one example and you should know that I just deleted another couple of paragraphs that went on and on about road tunnels and bridges so you can only imagine all the things one might need to know for all the other data out there. Give yourself a break, it takes back-and-forth exploration to discover all the nuances. Be someone who enjoys delving into things. Also, the term “test-place” is something I would like to propose a clever phrase akin to test-case but specifically used by cartographers. A list of classic test-places and what to look for when you are styling them would be very nice indeed.
  • Knowing the software inside-and-out. I have made many an SLD in GeoServer in my day. By the way, do you know if nausea induced by continous xml scrolling is treatable? Anyway, it only just dawned on me recently that you can combine filters with “in” like this. Previously I would have split these into separate functions with OR between them. Basically the point here is that there always seems to be something to learn that can make code more readable or a style looking better.

<ogc:Function name=”in”>

  • You can go in and change the json code for an AGOL database by adding “admin” between the rest and services part of the url. 

There was zero rhyme or reason for this post really, except to keep in touch. And know that whatever you’re struggling with, you probably aren’t alone. And that there are zillions of ways to make maps these days and as a cartographer, the more of them you know, and the more data you know, the better your ability to find the right tool for the right map. And that it is worth it in any case. I see the making of a map as putting together a puzzle. It is difficult, time consuming and at times tedious, but you can’t stop and each time a new piece is found and fit you feel a little bit more whole.

Slow Carto

May 7th, 2018


It’s okay to work slowly. Thoroughly. Tangentially. Thoughtfully.

Faced with programming problems that seem to need immediate solving, cartographic deadlines, and server configuration conundrums, what motivates is usually the end-goal: the map product to be served up to the customers. Needing to get to that goal as quickly as possible isn’t everyone’s hang-up but it is mine, and might be yours too.

Giving oneself permission to pour a cup of tea, listen to slow music, and simply explore the issue for an hour or even a day provides such a richness, a broadness, of education, that it could be likened to the learning experiences absorbed when vacationing abroad rather than close to home.


Perfection is attained by slow degrees; it requires the hand of time. -Voltaire



Map credit:  Regional Food from  Capital Country Villages , by illustrator Tiffanie Brown



Tools for Making Webmaps

April 25th, 2018


You call yourself an expert. You call yourself a consultant. And then you get a call asking how you would put together a web map for a small organization without much in the way of resources, that doesn’t know a lot about geo. And that’s when it hits you: sure, there are the big companies and products that come to mind like Esri’s AGOL, Mapbox, and Carto, but what else is out there? Could something new have popped up that I should advise they use instead? With an ever-changing landscape of products, both paid and open source, and all with varying nuances in terms of their limitations and strengths, how can we possibly know what the answer is with 100% surety?

Thanks to social media (not an oft-heard phrase these days, granted) I now have a great list of potential ways to make this map that I can pass along to the client. It seems this was a popular topic as the thread garnered quite a lot more discussion than most in the geo niche and as such, it feels like there is a need to put them all into one place in a post. Prefer to read the thread? Here you go:


Prefer a list? Here you go:


  • umap – open source and based on OpenStreetMap.
  • Google MyMaps – looks like it requires a google login. Upload a csv with latitudes and longitudes or addresses of up to 2,000 records. Or just plot straight on the map. Embed code provided.
  • Carto – make maps with on-the-fly analysis capabilities. Their site says they support educators (the field my client was in) with free plans.
  • Esri AGOL – you can probably do it all with AGOL and it isn’t too hard to get into even if you aren’t very familiar with geospatial technologies. The difficulty used to be in determining how much it would cost. But it looks like they may have changed their pricing plans to real dollars instead of points, so it might be easier. (Geoloket was mentioned as an example of an AGOL site that was built by one person for a small city.) Esri Story Maps were mentioned too, a sub-component of AGOL.
  • MapHub – upload via GeoJSON, KML, GPX and get embed code for the map.
  • MapMaker Enhanced – This is a WordPress plugin and hasn’t been updated recently.
  • mapzap – this looks pretty sweet. It provides a “builder” for making a map app and it is open source. Host on GitHub Pages for free.
  • QGIS – export from qgis to html, host on GitHub Pages for free. (Qgis2web was also mentioned.)
  • Someone who thought “doesn’t know much geo” meant that the person was a dev (they’re not) said “R, leaflet, and five lines of code.” But for a dev this is something to look into for sure. Someone else suggested the combination of Leaflet, QGIS, and json, which is along the same line in terms of needing dev expertise or at least geo expertise. While we’re mentioning these techs we should also mention GeoServer, OpenLayers, D3, Tegola, Maputnik, and Fresco! Again, expertise is needed for all of these (or a lot of time).
  • Astuntech’s iShareMaps (edited 4/26 to add info from Astun Technology) – aimed at local authorities in large, enterprise types of environments.
  • Geojson-dashboard – this looks pretty interesting. You need a GeoJSON file and I’m not sure what you do about basemap needs. 
  • Geopedia – this seems to be for satellite imagery?
  • Mapbox – you can definitely do everything needed with mapbox and they do have a free plan.
  • GitHub Gist was also mentioned.


Well, I’m exhausted. 


BTW: that list is in absolutely no order and I am not endorsing these or saying that any of them are better than any others. In fact, I know very little about several of these and it is very likely that good details have been left out. But it is always nice to have a handy list of potential tools to take a look at from time to time to keep the ‘ol consulting brain in tip-top order. 

Lastly, there is a wiki list of GIS software here. It does not contain all of the above ideas/options though and, indeed, a tool to make a webmap need not be a full GIS package and a full GIS package need not have the capability to create a webmap (it might instead do analysis and output static maps for example). So this list isn’t too helpful for the use case outlined at the beginning of the post but could be helpful to someone else with a different use case.

Creating Compelling Map Presentations: Borrowing From Web Design

April 17th, 2018

What if we used maps to “sell” an idea in the same way that newer websites are selling their products? This approach would be a hybrid between what some are calling “story mapping,” and small multiples, set up in such a way as to quickly convey your idea while visually explaining each component. You could argue it is also like a very simplified poster presentation.

Take a look at part of the AWS Lambda landing page:



Here’s an example mock-up showing how we could apply the pattern shown above to a map project:


Mockup-Not For Decision Making

Essentially what it comes down to is a highly organized, static, presentation of complex data with annotations to help the map reader understand the issues while also giving them the visuals to absorb the information. You know what they say:

Give a person a map and they’ll click away; give a person a story and they’ll stay.

(Ok, I said that.)

Natural Earth Quickstart Style Implemented with Tegola

April 6th, 2018






Natural Earth came out with a newly updated version recently and the group I’m working with decided to be one of the first to use it in a comprehensive vector tile map. There is a “quickstart” style implemented in QGIS and ArcMap but we wanted one implemented in Mapbox GL JS.

Check out the new Tegola Implementation of the Natural Earth Version 4 Quickstart here.

We’re using the minzoom feature of the new data in the Tegola set-up so that only features that have minzooms less than the current user’s zoom level show up. It’s such an easy way to filter data it’s almost not even fair.




The various files used in this implementation include the script to download the Natural Earth data into a PostGIS database, the configuration file that Tegola uses to configure that data, the style file that styles that data in Mapbox GL JS code, and of course the Tegola software itself (use the non “cgo” version for a PostGIS database, use the “cgo” version for geopackage data.)


I put together a quick visual guide on how Tegola can be used for those who maybe want to just see what it is all about without going through the process. 


There is some great, official, Tegola getting-started documentation to explore as well. And Eric Theise put together a Hello Tegola blog post that goes much more in depth.


See Nathaniel Kelso’s Natural Earth repo for more information on the data and to see the styling implemented in QGIS and ArcMap (the styling such as colors, line-widths and which datasets to show and how are all translated from those original Kelso styles.)


What are Sprites?

January 23rd, 2018


Sprites are a newish concept in the cartography world. I haven’t written about them here before as they didn’t really have a lot of relevance until Mapbox started using them in Mapbox GL JS. It turns out that sprites are a handy way to provide map icons to a vector tile project.

To be brief, a spritesheet is comprised of sprites, which are really just map icons. A vector tile map style displays map icons via a reference to a spritesheet. Spritesheets mush the sprites up into a very small amount of space to keep the file size small.

Here is an example of one portion of what actually is an unusually large spritesheet that will be used for icon-heavy nautical charts:




You may also see the term “spriteset,” which is referring to the two files that Mapbox GL JS spec uses to place these things on a map: the png file and the json file. The json file is really just a list of all these sprites by name and location in the png file. Something like this:




So you see the json file shows the location and size of each sprite and references them by name. As I’ve learned the hard way, the name is actually very important. You use the name in the json style to tell the map what to render. So for example:




Here you can see that the we are symbolizing data where type=tower with a sprite that is named “power-tower-12” in the spritesheet json. However, it would have been much nicer if it had been called “tower” in the spritesheet json. Why? Because here’s another bit of that same stylesheet, where you see how it works much better:




Here it will just go find whatever sprite in the spritesheet has a name that matches what’s in the type field (plus has the -18 on the end, which isn’t that important to know about for now but just is a way of referencing the size of the icon in case you maybe have two different icon sizes). The first way you would have to hard-code each and every icon name with whatever you are filtering for, the second way you simply name each icon/sprite the same thing as what it is referenced as in the data.

Alright, that’s it for this whirlwind intro to sprites. There’s a lot glossed-over here but serves to get us all acquainted I think.

P.S. I’ve been using TexturePacker to throw pngs and svgs into a spritesheet with a custom exporter I built for the Mapbox GL JS spec. There’s also spritezero to checkout for free.

P.P.S. Here’s a little view of TexturePacker and what looks like it should be my next corporate logo, the little green duckling.




Cartographer's Toolkit

Map Making Tips, Tricks, and Inspiration