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.

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.

*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

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.

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.