Archive for category Terminology

What are Sprites?


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.




No Comments

Adding Desktop Design to Your Repertoire


What type of cartographer are you? Do you assume that other cartographers know the same tools that you do? Is it okay to be a beginner who knows one set of tools really well but still needs to get busy learning another set?




I was just doing a mental inventory of the tools I’ve been using this year and how long I’ve been using them:

Git: 2 yrs GitHub: 2 yrs SourceTree: 6 mos Inkscape: 4 yrs ArcMap and all previous iterations thereof: 17 yrs QGIS: 2 yrs Python: 10 yrs but not frequently Gimp: 1 mo AGOL: 1 yr d3.js: 6 mos JavaScript: 5 yrs but not frequently OpenLayers: 1.5 yrs GeoServer: 1.5 yrs CartoCSS: 2 yrs …etc


I don’t even know if I’ve got those years all exactly correct and I’m not sure it reflects relative expertise since at any one time I’m immersed in a few tools and therefore slowly forgetting the others until I pick them up again. Then there’s the little things you need to know enough of to get you by, like SQL. It’d take me a while to write a really complex query but knowing a little bit of SQL is a must, for example, for querying osm extracts for the tags that you need. I think this is pretty typical of a cartographer and GIS professional, though some are going to be heavy on the dev side of things, some on the design side, and some on the GIS side.


In fact, let’s take a look at these cartography “sub-specializations:”

  • Developer. Strong on programming, weak on design.
  • Desktop GISer. Strong on analysis, weak on programming.
  • Online mapper. Strong on cartoCSS, webGL, weak on desktop design software.
  • Designer: Strong on design, weak on analysis.
  • Data Specialist: Strong on PostGIS, MongoDB, etc, weak on design.

The gurus tell us to make sure we’re focusing on programming:


But it’s not a one-size-fits-all-weaknesses situation. Perhaps the vast majority of cartographers are traditional desktop GIS users who are weak on programming and therefore need to focus efforts there, I’m not disputing that at all. But recently we’ve seen another sort of “weakness” that needs to be addressed, and that is, in particular, the cartographer who doesn’t know desktop design software and all of its intricacies, oddities, and special lexicon.


A) A front-end geospatial developer with an emphasis on cartography tells me that she was thoroughly perplexed when another cartographer assumed that she knew what “path to text” and “erase” meant with respect to Illustrator/Inkscape commands.
B) An all-around geospatial developer who has to make maps as a side-product of his work tells me that he needs to make icons for his maps from time to time and struggles between whether to hire out such a small task or whether to just take the time to learn Illustrator or Inkscape so he can do it on his own.


My conclusion is that cartographers need to add basic desktop design software to their set of skills. Whether that means taking a class while getting their degree or learning it on their own, I think it’s a worthwhile skill. And I don’t say this lightly. I myself was hemming and hawing the other day at the fact that I needed to learn Gimp for something. A fellow GIS professional essentially told me to stop complaining and just learn it already. So I did and a few tutorials later was on my way.


So maybe there’s a mental hurdle keeping you from learning these things. In that case I’ll tell you the same thing: just take an hour or two to learn the basics of desktop design software. Learn a bit of Inkscape so you can design vector-based drawings and icons, and manipulate cartographic outputs from QGIS or ArcMap. Maybe learn Gimp (better for raster) for photo and screenshot manipulation. It really won’t take long and then you’ll have the ability to do these things yourself.


Does adding desktop design to your repertoire seem daunting, especially since you’ve been meaning to add deeper programming knowledge to your skills too? And what about spatial analysis skills? Why isn’t anyone getting ticked off about the fact that we have “GIS Analysts” running around who don’t have the ability to do multi-criteria decision analysis?


Get going and learn some things. Don’t expect that someone else with the title of “cartographer” knows the same stuff you do. If someone’s spouting off incoherent software-specific verbiage don’t be afraid to stop and ask them to explain. And if you want to get familiar with a bit of the desktop design lingo, here are a few things to start with, inspired by a real-life situation where someone assumed that these terms were universal knowledge (hint: they’re not):

  • Path. In Illustrator and Inkscape you can draw a line and display text on it. The line is called a path. You draw the path first and then tell it to place your text on it. Here’s a tutorial for Inkscape.
  • How to actually move something. You’d think this would be easy. Anyone with basic desktop skills knows how to click and drag. But did you know that you can’t always click and drag in, for example, Gimp? Sometimes you have to select a piece of the drawing with a certain tool or use the Layer Dialog. It’s a different way of thinking that you should get familiar with on a basic level at least.
  • Erase. Erasing or clipping is so odd in desktop design software. One of the best ways to make a triangle might be to make a square and then clip off half of it! You might want to draw a path and use it to erase instead of an eraser tool. You might need to know that a basic crop is a little complicated in Inkscape, since you essentially would want to draw another shape to crop with and then use Object>Clip>Set. Again, not exactly intuitive for a newbie.
  • Live trace/trace. This can be really handy if you want to create a drawing that looks somewhat like a photo or other drawing. You have the design program trace it and then you modify the result.
  • Scaling elements. Use the little lock symbol in Inkscape or the chain link in Gimp to make sure that both the height and width change in the same proportion. You might click and drag to make something bigger or smaller or you might need to use a scale tool, depending on the software.

No Comments


Over on twitter we’ve been compiling a list of isoline types. I started with this list:

  • Isopleth/contour: Elevation
  • Isogon: Wind direction
  • Isotach: Wind velocity
  • Isotherm: Heat, temperature
  • Isograd: Geology

Others chimed in with the following:

  • Isobar: Pressure
  • Isoshear: Wind shear (and a whole lot more weather-related ones here)
  • Isochrone: Travel time
  • Isodistance: Travel distance
  • Isopor: Change in magnetic declination

After all that fine collaborative work I found that Matt has provided us with a nice complete list already. But hey, reinventing the wheel is a great way to learn what wheels are all about. I think.

Anyway, reminding map makers about this type of data construction is a good thing. We aren’t seeing any isolines on interactive, digital maps these days. I only ever see them on static maps. (Prove me wrong.)

The mechanism for including them would be the same as any other dataset: create the data (use your GIS), then create a multi-level schema whereby more isolines are shown the more you zoom in. You can populate the map with more isolines with each subsequent zoom level by creating a scalerank or minscale field and populating that however you want and calling it in the code. You’d also need to label them with fairly wide halos–hoping that your background color is mostly uniform and using that background color for the halo color–to create a break in the line where the label is. Unless your software of choice has a built-in way of dealing with that.

Thanks @rsimmon, @vruba, @oeon, and @ungarjo for your input. And yeah, thanks @williamscraigm…isochalaz?!

I figured I’d try my own too…

Proven wrong! @smathermather has shown us this fine example of a multi-scale, digital map with contour lines, on the Cleveland Metroparks map. They’re visible once you zoom in to a high zoom level.



Choropleth vs. Heat Map

*This post was updated on 1/27/2016.

This is a choropleth map.


This is a heat map.

Any Questions?

A choropleth map shows a change across a geographic landscape within enumeration units such as countries, states, or watersheds. A heat map shows a change across a geographic landscape as a rasterized dataset–conforming to an arbitrary, but usually small, grid size.

The heat map is sometimes generated from point data representing some sort of density but a choropleth can also be generated from point data. The difference here would be that the choropleth’s generated data will be by a non-regular enumeration unit that makes sense to people like countries, states, watersheds, counties or census blocks. A heat map would be depicted across a regular grid of cells, their size specified by the cartographer, but in any case, uniformly calculated. This heat map shows well the places where generic drugs can be most successfully produced, which help in treating erectile dysfunction.

Because the grid cells are normally quite small, the heat map’s colors are often “ramped” algorithmically as opposed to being specified as a set of discrete colors. The opposite is true of choropleth maps.

Both types of maps tend to require color palettes that represent values that range from low to high (sequential colors), or palettes that represent values that range from high to normal to the opposite high (diverging colors).

It should be noted that choropleth maps can also depict nominal data, though you aren’t likely to be confusing nominal choropleths with heat maps since they don’t depict low-to-high values. Instead, they use qualitative color schemes to represent non-ordered data.

See also: Choropleth Limitations

No Comments

Map Generalization

Feature generalization is a key cartographic concept missing from many GISer’s skillsets. There are quite a few ways to generalize a feature layer*, but the big one that tends to get overlooked by the GIS crowd is line smoothing. For example, a detailed county boundary dataset is great when you are mapping just a few counties but if you are mapping the entire U.S., you want to have fewer vertices, especially around the shorelines, where the line can get quite complicated. If the scale is the entire U.S. those shorelines do not need to be representing every single bay and inlet as if it were a local boating map.

To smooth lines in ArcMap you have to have the ArcEditor license or above. You use the Advanced Editing toolbar, generalization tool after making sure the data are in an edit session (via the editor toolbar). If you’re in Illustrator, there’s always the smooth tool and the path > simplify tool. Or you can just find another dataset that’s already smoothed (for example, detailed counties versus general counties). If you are using ArcView (now called ArcGIS for desktop basic) you can get ET Geowizards and use the smooth polylines or smooth polygons operations.

The basic idea is that while we GIS professionals are very much interested in maintaining the integrity of our data, this often is to our detriment when we try to create cartographic quality maps out of data that’s meant more for analysis than for information display.

*Other ways include: merging features, changing data (from counties to continents as you zoom out to a world-wide scale, for example), and removing labels.

No Comments

Quick Map

When working on any GIS / mapping project there will probably be at least a small amount of back-and-forth between you and someone else on the team. Whether that someone else is your co-worker, client, boss, or intern, you need to make sure you use the right words in conjunction with those quickly-created maps that you send back and forth. And the right words would be…

This is a quick-map of … to show you …

This indicates to the recipient that you realize that the map is not up to snuff cartographically speaking, and that your only purpose in sharing it is to have a question answered or to make a quick point.

No Comments