Creating Compelling Map Presentations: Borrowing From Web Design

Posted by G.P. in Design on April 17, 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:

awslambda

 

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

No Comments

Natural Earth Quickstart Style Implemented with Tegola

Posted by G.P. in Web Maps on April 6, 2018

 

NaturalEarthQuickstartStyle2

 

NaturalEarthQuickstartInspector4

 

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.

 

minzoom

 

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

 
 

No Comments

What are Sprites?

Posted by G.P. in Terminology on January 23, 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:

 

nautical_sprites

 

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:

 

sprite_json_snippet

 

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:

 

power-tower_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:

 

variable_usage_in_icon-image

 

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.

 

green_duckling

 

No Comments

Cartonotes

Posted by G.P. in Design on January 8, 2018

Presenting a few random cartonotes from various digital maps I’ve been working on lately:

Indicate marine parks, preservation areas, and state beaches that extend into the water as transparent polygons with solid or dashed outlines. This allows the feature to be seen without giving the impression that it is solid land or some other solid feature.

State Beach

 

When symbolizing road features it can be easiest to simply use a single color for all road types. This is simple but effective.

Simple Roads

 

However, if you are interested in more complex road symbology using road casings and different colors for the different classes (e.g., highway, primary, secondary), then take care to make sure that bridges are separated and placed on top of the other road features.The feature order list will be something like this:

  1. highway bridges
  2. primary bridges
  3. secondary bridges
  4. highway, not bridges
  5. primary, not bridges
  6. secondary, not bridges

In other words, the bridges go above everything else that isn’t a bridge, even if the bridge is of type primary or secondary. You can see a secondary bridge (peach color) in the screenshot below that runs over a highway (purple color).

Complex Roads

 

It is pretty typical to use the same hue with a slightly darker value for polygon outlines, as shown in the airport outline below. Hexcolortool is handy for lightening or darkening a color by a given percentage. Of course you can also adjust the value in the HSV color system or the lightness in HSL color system to achieve this.

Typical Outine

 

Labels for features that are higher in order do not necessarily need to be darker in color. In the following example label hierarchy is achieved with larger state labels in a lighter color, while city labels are smaller but darker.

labels

 

No Comments

Map Design Basics*

Posted by G.P. in Crazy on October 11, 2017

It isn’t April Fools’ Day but this is one of my old workshop hand-outs that came across my desk again today. Spruced up and embellished, it makes some great points about how to be a good cartographer. Or, erm, it makes some points anyway. 😉

schooled

  • Neat-line boxes must surround every element. Think maximum containment and minimal flow.
  • Ignore figure-ground. Land can be white and water can be white. Why use more ink than you have to?
  • You don’t need to bother with labeling features but if you do, try under the line, on the point, and on all parts of multi-part polygons.
  • Definitely include a large row of clashing logos.
  • Legends don’t need to explain everything, let the map reader guess a little.
  • Spell-check is overrated.
  • Legends with underscores, cryptic numbers, and things like “z5” make you look smart.
  • Orient your maps in highly unusual ways.
  • Make sure map readers understand each and every disclaimer, including those that have never been tested in court, before they are allowed to even see the map.
  • Talented map designers only need about 30 minutes to turn out a good map.
  • It’s important to make the map for yourself not for the audience.

 

*Kidding!

No Comments

In case you missed it

Posted by G.P. in News on August 25, 2017

  • FOSS4G was last week, had the biggest turnout yet, and included some guy on stage rubbing his feat with lotion (or so the story goes, I wasn’t there to witness that historic event.) Some recaps of the week: Carto’s take, the GeoSolutions presentations, DirectionsMagazine. If you have one to add let me know.
    Added 8/29/17: geoMusings FOSS4G Recap
  • There were a lot of eclipse maps. A LOT. All non-eclipse maps seemed to be eclipsed by the eclipse maps.
  • Brian Timoney, of MapBrief fame, said something about Excel on twitter, AGAIN. I was using Google Sheets last week and I swear it read my thoughts and did my calculations for me. I think you should switch to Google Sheets.
  • I mentioned the Einstellung effect, which according to wikipedia is, “a person’s predisposition to solve a given problem in a specific manner even though better or more appropriate methods of solving the problem exist.” As a professional cartographer, this should not dissuade you from keeping a mental catalog of map types and techniques (e.g., hex maps, dynamic clustering, cartograms, etc.). It should also not dissuade you from keeping an eye on all the new map types and techniques that are currently being developed and floated on social media. In most cases one of those is going to be the best idea for your map viz too. But it may not be. So to combat this psychological wall, you need to do some things when you are planning a new map. First, try framing your task as a question like, “is there a completely different approach I could take?” Second, if you are drawing out your ideas, switch to writing them out with words or vice versa. This helps you switch from right-brain to left-brain thinking (or vice versa), which gets you out of your usual thinking processes and may enable new insights to occur. Third, and this is always my own biggest issue, take the time to really think through the problem. To get myself to stop hurrying into solution-mode I’ll run the problem by colleagues to get their thoughts, take a walk to think more, or draw it out.
  • City Maps was cited in an academic paper. So was one of Anita Graser’s papers. Double fantastic. The World’s User-Generated Basemap is More than 80% Complete.

 

——————————————————————————————–

 

No Comments