Cartographer's Toolkit

Map Making Tips, Tricks, and Inspiration

Creating a new Hot OSM map

April 27th, 2017

 
Using Tegola and Tegola-OSM I’ve been working on approximating the HOT OSM map style in Mapbox GL. Using the handy CartoCSS available for this style, by-eye comparisons with the raster tile map, and personal interpretation for the 3d building elements, we’ve got this going:
 
nyc2

 

View the demo live here. It’ll be a bit slow and not so great at zoom 4, but we are working on that. I mean, it’s the OSM data of the entire world styled at all zoom levels (plus a bit of natural earth data for admin boundaries and more to come) so there’s a huge amount of data to work with here and lots of things to work out to get right.

If you aren’t familiar with vector tile maps, note that you can shift the pitch (tilt) via Ctrl + left-click + drag. That’s something that we cartographic consultants need to start teaching our clients. Also, different parts of the GL spec are operational on desktop vs iOS vs Android so depending on your device your results will vary a bit at this time.

Maputnik, for the most part, makes it “easy” to style a map as long as you have an endpoint like Tegola serving up some good data (the Tegola endpoint is still very much under development and is undergoing some optimizations and doesn’t have every single map item we’d like to have quite yet).

I say “easy” in quotes because as with everything there is still a learning curve and, as with everything, it is still under development as well. There are a few things that have to be added to the style.json by hand so anything beyond its interface capabilities will require knowledge of json.

Like the data-driven styling on the buildings in this map. You can see an example of that in the image above where the hospital building (type=hospital) is a bit reddish compared to the other buildings. In Maputnik this style still looks like all the buildings except the hospitals and schools are black whereas live it looks the way it is supposed to. Thus I await with eagerness the incorporation of all the cool new things available in the GL spec. :)

Here’s that bit of code for the building tilt data-driven styling. You can see the “default” property isn’t used and instead, mysteriously, the empty quote does the job for providing the default gray color.

codesnip

 

One of the more interesting style choices that came up was where to put the road labels. Google maps puts road labels above 3d buildings when you view on your mobile device and tilt (two finger swipe). This might be ideal for a small amount of screen real estate when you’re using the map for navigation but I think that on larger screens and with different map purposes the street labels can look cleaner when they are beneath the 3d buildings. Take a look at this thread for some opinions on this:

 


 
 

————————————————————————————————————

January 6th, 2017

I’ve been using a new vector tile style editor to create some maps. The editor is called Maputnik and is still in early development, but it is usable even at this early stage. I’m really impressed with how much of the mapbox gl js spec has been implemented and the multitude of complex tasks that it makes easy.

Here’s a couple of screenshots from a style I’m working on called Camo:

screenshot1 screenshot2

Creating an Aspect-slope Map in GeoServer

June 22nd, 2016

An aspect-slope map (sometimes called a slope-aspect map) is an overlay of a semi-transparent slope map on top of an aspect map that is styled with a unique hue for every 45 degrees of slope direction. To put it visually:

aspect_slope_visual

To do this in GeoServer, you need slope and aspect raster datasets in degrees. Create an SLD for each with the following syntax (I’m not including the whole SLDs here for brevity).

SLOPE SLD

<sld:ColorMapEntry color=”#999999″ opacity=”1″ quantity=”10″/>
<sld:ColorMapEntry color=”#999999″ opacity=”.66″ quantity=”20″/>
<sld:ColorMapEntry color=”#999999″ opacity=”.33″ quantity=”30″/>
<sld:ColorMapEntry color=”#999999″ opacity=”0″ quantity=”90″/>

Here we have a gray color being used to denote very flat areas where the slope is less than 10. The gray is increasingly transparent as the slope becomes steeper, thus revealing the underlying aspect layer with more brightness in the steepest locations. These parameters could be tweaked to allow more or less brightness to show through.

ASPECT SLD

<ColorMapEntry color=”#9AFB0C” quantity=”22.5″ />
<ColorMapEntry color=”#00AD43″ quantity=”67.5″ />
<ColorMapEntry color=”#0068C0″ quantity=”112.5″ />
<ColorMapEntry color=”#6C00A3″ quantity=”157.5″ />
<ColorMapEntry color=”#CA009C” quantity=”202.5″ />
<ColorMapEntry color=”#FF5568″ quantity=”247.5″ />
<ColorMapEntry color=”#FFAB47″ quantity=”292.5″ />
<ColorMapEntry color=”#F4FA00″ quantity=”337.5″ />
<ColorMapEntry color=”#9AFB0C” quantity=”360″ />

The colors and class breaks are from this Esri/Buckley blog entry which, in turn, references the color scheme from Moellering and Kimerling’s MKS-ASPECT (GIS world 1991). The colors, in order, are shown here:

 

aspect_slope_palette

PUTTING THE LAYERS TOGETHER

Using a two-layer syntax in the wms request mashes the two layers together. List the aspect layer first and the slope second. I had it switched around on my first try and it took me a bit of time to realize that it draws that second referenced layer on top. And no, the finished map does not have a hillshade underneath. The combination of aspect and slope creates that “hillshade” effect.

————-

 

Thoughts on UI For Webmaps

April 26th, 2016

Webmap design is a lot different from static map design. Yet, writing a book about webmap design is difficult since the tech is changing so rapidly. (There is a book, called Web Cartography, that is worth having but I still don’t think it goes into everything we want to know.) Indeed, there are a lot of unknowns surrounding the idea of what good UI for webmaps even is.

Some people are using google analytics types of software to analyze how people are using their webmaps (e.g., maptiks) but I don’t see a lot of A/B testing out there, which is probably the ideal way to harness the power of webmap analytics results.

Certainly we can still make some guesses at what works. For example, we can guess that tools and functions that have been on webmaps for at least a certain amount of time, say 5 years, are well ingrained into the public’s knowledge base and probably don’t need a lot of explanation on your map. Zooming in/out, panning, and even the ubiquitous (and not often needed) measure tool are all pretty familiar concepts to most webmap users so they need only be indicated with the usual plus/minus/ruler buttons. Brand-new tools for navigating the map, such as oblique tilts, probably will slow your user down until web GL is more common. These tools may require user education, perhaps in the form of a pop-up info box on first use.

Let’s talk about disclaimers. These could really benefit from testing. Typically, an organization will require a long-winded disclaimer to be presented to the web user before they have even seen the webmap. I’d really like to know how many users leave the site without clicking “agree.” Furthermore, I’d really like to see if clicking “agree” really does hold the organization free from liability in court, or if not having a disclaimer could allow prosecution of the organization for some users’ misuse of the data. My guess is that a reasonable judge would allow neither of these but I’m no lawyer.

What if we A/B tested disclaimers specifically? One site shows the user the disclaimer on the page, and the user has to click “agree” before the webmap will load. Another site shows the disclaimer on top of the webmap such that a faded view of the webmap is visible so that the user gets a glimpse of the webmap. Lots of guesswork here, but the hypothesis would be that the B test would result in more users.

Now let’s take a look at the freshymap. I believe that their use of these three small buttons on the top of the map make it easier for first-time users to pay attention to the main attraction–the map–before they get bogged down in the details–the layers. This one small button can be discovered at some later date, when the user is already familiar with the site.

freshymapbuttons

Contrast that with this Puget Sound Watershed Characterization Project map (that’s a mouthful). Once you get past the disclaimer, which by the way happens to mention a two volume rules guide!, and then figure out how to actually get into the webmap (I’ll let you brave souls go figure that out yourselves), you find yourself on a webmap.

I think you’ll see right away that there are a remarkable amount of superfluous details on what is, essentially, trying to be a cataloging of their data holdings. In other words, it is trying to be all things to all people. We don’t need share, print and find location buttons at the very top of the page. We also don’t need the words “interactive map” at the top of the visual hierarchy (aka top-left) because we already get that it is an interactive map. In fact, that’s something that goes under the category of “user is used to this–we’ve had interactive maps for more than 5 years now,” and there is simply no need to explicitly use up good page real estate in telling them what they already know. The layer transparency slider also being at top-left? Nope, probably not needed, or at least not there.

ecologysitecritique

It’s not a bad webmap at all. It’s actually very interesting once you really take the time to explore it. I do like the basemap switcher on the right (not shown on the above screenshot), which seems much easier to deal with since it has little pictures rather than words (though Timoney states that basemaps switchers are used very little of the time, in one rare case of actual user testing.) I’d just like to see more testing of these things. In a way, it’s a grand place to be in because there’s a lot of room for people to really be creative and come up with some amazing new ways to present webmaps to users that have a lot of potential to really shake things up.

Even the little things can be improved, like the titles we use on webmap legends. For example, I spotted the title, “Explore & Compare” on a legend title today and thought that they were a good choice of words, a call to action for the user, if you will. Again, only some testing would prove if my instincts are correct on that.

Amazonia map hat tip @stamen

Amazonia map hat tip @stamen

Until we get some more expert guidance on this, the best we can do is to keep our eyes peeled for the ways in which people are making webmaps easier to use and try to incorporate the best UI features in our own designs. We can also push back against our bosses or our fellow scientists when they ask for everything but the kitchen sink in one single webmap. Perhaps a series of webmaps for each intended purpose could be proposed instead. Good luck with that.

———

 

Adventures in Plant Hardiness Zone Cartography

April 29th, 2015

Yesterday I spent some time looking at hardiness planting zone maps in my pursuit to buy vegetable seeds and starter sets that may  actually germinate this year. My historic gardening flubs aside, I was astonished by the bad quality of the maps that were listed at the top of the Google search results.

The first result for Colorado hardiness zone map is a site called Plant Maps that looks to be “optimized” (this word is used very loosely here) for ad revenue. It is also de-optimized for anything that would resemble a pleasurable experience including the fact that you can’t actually figure out what hardiness zone you are in. Oh wait, yes you can. After much perusal a viewer may finally realize that the colored squares on the left-hand side of the screen are, in fact, a legend of sorts, for the map that resides in the middle of the screen (with a nice vertical ad bar in-between).

 

PlantZones

 

Part of the problem with this site is the obtrusive ads, but another problem is what appears to be feature-creep: the insidious and rightfully maligned process that tends to get engineers into trouble. For example, clicking on their last blog entry (notably from 2011) shows us that they last added an interactive map of drought conditions across the United States, when their focus might have been raising the quality of the features that were already present on the site.

If you google plant hardiness zone map without the Colorado bit, you are pointed to the much more official USDA Plant Hardiness Zone page, which by comparison looks downright cutting-edge. But even this one could be so much better.

 

right4

 

For starters, I’m willing to bet that their analytics will tell them that most visitors to the site are wanting to view the map rather than read about it. They probably know this, which is why they’ve allowed the map to take up a little more than 50% of the screen space. In reality, though, it should fill 75% or more of the screen space. The USDA logo, the text about how it’s the first time they’ve published a hardiness zone map, the Stay Connected buttons, the six tabs including the Help* tab? They all must go!

everythinggo

 

Clicking on the individual states pages brings up a new map, as expected, though zooming it to the current map would be better. But here we see that a bad symbology choice has left Colorado looking like blood-shot eyes. Are rivers a necessary addition to the map or could people know what they are looking at without the rivers? I’m going to wager a guess on the latter. Additionally, I wonder if the choice of blue works here, or does it suggest that Colorado will be inundated when the glaciers melt? Just wondering. :)

 

co3

 

So when I read the first sentence on Stephen Few’s blog today, it seemed apropos:

We are overwhelmed by information, not because there is too much, but because we don’t know how to tame it.

In the case of the Plant Map website, I think we can conclude that in some ways it must be functional…for the owner of the website, who is apparently collecting enough revenue from its egregious number of ads to make it worth hosting despite the fact that the last update was in 2011. Perhaps this space is ripe for some disruption. A pared-down site along the lines of the wind map**, for example, with a few ads to sustain the maintenance costs and perhaps even provide a modicum of profit for the host would be just the thing.

Maybe I’ll just stick to indoor gardening.

 

My real-life hydroponic garden / mini-jungle

My real-life hydroponic garden / mini-jungle

 

*A map meant for the general public that requires a Help section means it’s not good enough.

**The Wind Map gets a higher google ranking (#1) than Weather Underground’s (#4) — which is not too bad but has quite a bit of feature bloat.

 

Edited to add some additional hardiness zone mapping resources from readers:

 

 

 

2015 GeoHipster Calendar

November 6th, 2014

At Boundless, we put together a nice and subtle world-wide basemap for our new product: Versio. It’s meant to be a basemap that shows you where your data is but doesn’t get in the way, thus the quiet color scheme coupled with ample data from OpenStreetMap.

A stitched together series of screenshots at about zoom level 14 in the San Francisco region provided a good entry for the 2015 GeoHipster Calendar and I’m pleased to announce that it has made the cover.

GeoHipster_2015_calendar_cover_layout

While I was the main designer for the map, we all know that cartography is only as good as its underlying data, and in the case of dynamic maps, as good as its underlying infrastructure. That’s why the map was really a

team effort by all of the Versio team at Boundless.

A short background on the map in case you’re interested: we used imposm3 to obtain a world-wide OpenStreetMap dataset with a customized mapping.json file that allowed us to get some generalized data for roads and things for the lower zoom levels while still getting the non-generalized data for the higher zooms. We also used quite a bit of NaturalEarth data for the lower zooms, including a raster hillshade for the ocean overlaid with a semi-transparent ocean layer to make it more subdued. Most of the labels are not cached, they are dynamic so that we don’t have any issues with double labels or labels cut off at tile edges. Because we aren’t using too many labels in the dynamic label layer, this doesn’t seem to affect performance. The map was made with most of the OpenGeoSuite components, including–yes, I’ll say it–SLDs that I basically edited by hand. GeoServer serves up the data + SLDs, PostGIS holds the OSM data, the NaturalEarth data are kept in shapefile format, geowebcache cuts the tiles, and OpenLayers shows them off on the webmap.

Cartographer's Toolkit

Map Making Tips, Tricks, and Inspiration