Archive for December, 2013
Enhance Your Figure – Ground
One of the major Major MAJOR problems that bad maps have is a lack of sufficient figure-ground contrast. Let it be impressed on the new cartography student that there is almost never a time when there is too much contrast. You pretty much can’t go wrong when it comes to lightening up the background features in order to make the foreground more prominent. Rule of thumb: think that hillshade is light enough? Try 10% lighter.
Gestalt is a general term that describes a group of objects (physical, biological, or even psychological phenomena) that have a definition as a group that is different from their definitions when they are apart. This concept, borne of German psychologists in the early 1900s, when applied to graphic design, encompasses many concepts including image continuity, closure, similarity, and figure-ground. For the purposes of this discussion, we are interested primarily in the gestalt concept of figure-ground of course, which refers to the differentiation between an object and its background. GIS maps usually include objects that need to be emphasized and separated from the other objects on the map even though the other objects are also important for geographic context. This applies to feature pairings such as land and water, city points and land, or watersheds and forest stands.
In this map slice, we’ve got a National Geographic basemap at full saturation underneath future areas to be sewered in red-dash and ages and locations of existing septic systems as different colored dots (red is greater than 30 years old).
Nice basemap but insufficent contrast with overlay data
Increasing the transparency by quite a bit helps the data come to the forefront. You can increase the transparency in ArcMap by double clicking the basemap layer and setting it to about 50% in the layer properties > display tab. Here, I’ve actually done it in Inkscape, with the filter > transparency utilities > light eraser tool. The same thing can be done in CartoCSS, PhotoShop, QGIS, or whatever your GIS demon is.
Much better figure-ground contrast here
But we can go even further, increase the transparency to 60% or, in Inkscape by using the light eraser filter once again, and really achieve a nice looking contrast:
Even better contrast
Pre-rendered basemaps have never received the hype that they should have. They’ve made the workflow of the GIS Analyst a thousand times more productive, in my mind, since they first appeared. Even if you don’t use ArcMap you still have a wealth of pre-rendered basemap components available to you via Natural Earth Data and other sources. The main point here is to re-iterate the importance of making sure that basemap data is indeed “basemap data” by visually lessening its impact on the map while still retaining its efficacy.
Getting Along: The Objective and the Subjective in Mapping
In my morning reading I came across the following argument: people in fields where there isn’t a lot of debate about what the “right answer” is (e.g., math, chemistry) are nicer to one another than those in fields that are 100% subjective (e.g., art, architecture, music). In the fields that are 100% subjective, the only way to make your mark is to have an outsized ego, so the argument went, because a holier-than-thou stance on critique is the only way to get people behind your opinions. Loud and obnoxious wins in these fields. The corollary is that subjective fields of study are more competitive and less collegial than non-subjective fields of study.
Since our formula for map making is somewhere along the lines of
A Good Map = 0.5x + 0.5y, where
x = subjective items (aesthetic, feel, fashion, staleness, communicative ability, interpretation of data etc.)
y = objective items (projection accuracy, data precision and accuracy, spelling, normalization, etc.)
It stands to follow that we cartographers are justified in being 50% rude and 50% friendly to each other.*
Thinking back to some of my first attempts at public map making, here’s how this would break down. The subjective map critique would have been something like: I know Kitsap County is an awkward shape to map, but maybe you could do something different to make it more interesting. Tan for the land and light blue for the water, wow, how original! The roads look like the tentacles of an octopus. Those are some ugly suckers.
The objective critique would have gone more like this: The road shield images didn’t go through and the map has big red Xs where they should be. The color saturation on the water fades at the end of the map because the ink was starting to run out.**
Broadening the discussion from my sophomoric disasters to more general concepts, we have:
The Subjective Map Critique: Is the map a mess? In other words, are there so many extraneous details such as ridiculously thick feature boundaries, too many leader lines, a legend as long as an essay? Are there harshly clashing colors, misleading colors, or out-of-fashion colors? Is there not enough information? Is the map boring? Is it confusing?
The Objective Map Critique: Are the color connotations correct for the audience? In western countries, for example, red is used most often to mean “bad” or “a lot.” Don’t use red to demarcate areas where the habitat for a fluffy-cute animal that everyone wants to save is located. Do the interactive components, if any, actually work? Do they include the information promised? For example, a recent digital map I viewed confusingly had social media links under the headline “legend.” Is the spelling correct? Is the projection reasonable? Was normalization of thematic data that has a strong population component included and described? And so on.
When critically reviewing your own work and that of others, you must think in both the objective terms and the subjective terms. Indeed, judging criteria for map contests is often broken out into these two categories, even if they aren’t expressly labeled as such. Often, the criteria include one or two elements of objective ratings and 3-4 elements of subjective ratings. Why the subjective gets more weight in these contests is an interesting question. We assume that the subjective is where the major differences are going to be when judging cream-of-the-crop maps. When judging run-of-the-mill*** maps, however, these should be given equal weighting.
*Joke
**A short list because I’m a scientist, of course there wasn’t anything else objectively wrong…
***These idioms “run the gamut” from farm to factory.
More TileMill Tutorials
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 www.naturalearthdata.com 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:
/*————LABELS————–*/
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.)
-
You are currently browsing the archives for December, 2013
The Books
Recent Comments