Archive for category Cartography Profession

Recency Bias in Mapping, an Exploration

 

I’ve been thinking about recency bias lately. In finance, recency bias is the problem whereby people think that securities trends from the recent past will continue into the future. Instead of focusing on market fundamentals or buy-and-hold strategies, people tend to jump on bandwagons instead, which works until the cycle changes.

Recency bias also applies to many other aspects of human behavior, so how might it apply to map design? One way it applies is that, until the cartography landscape was disrupted around the late 2000s, people tended to make all their GIS maps very similarly. I say “GIS maps” because there were some people making well-designed maps with Illustrator and other design tools before that but the GIS people, for the most part, hadn’t caught on to those skills or those techniques.

Along came some new tools like TileMill (now MapBox), an influx of design-oriented mappers to the field, and new and interesting datasets to map, and suddenly the bar of map design was raised. I predicted this in the 1st edition of GIS Cartography in 2009. Those who were assuming that GIS map design would remain the same were creating increasingly obsolete visualizations.

 

Let’s show this by example.

Prior to the late-2000s disruption, we frequently encountered maps that appeared to be slapped together, often with a multitude of diagonal hashes making one feel rather dizzy like in the map shown below. These maps would contain some superfluous details to meet edge-cases (observe the grid-like layer in this map example) and would omit basemap information such that no underlying geographic context could be ascertained. Now, admittedly, these were not always the fault of the map maker. Indeed, the edge-case layers would have been included at the behest of some boss who was the only one who wanted to see that information. Similarly, the basemap information would be omitted due to a lack of availability of that kind of information.

 

aldc_spd_lrg

 

Thankfully we see many fewer of the types of maps shown above and many more of the maps shown below. In this map we have geographic context, gleaned from a nice and subtle baselayer of buildings and streets along with some very nicely done trees. There is some hashing but it comprises a small minority of the overall space. Interestingly, this map manages a significantly better visual experience with much more information. The richness of information makes it both more functional and more beautiful.

 

12546_KTCP_UD014-Framework-Generational-Plan-Overall-480x528-1402446397

 

What kind of recency bias in mapping do we see today? What kind of recency bias is affecting your map designs? Could an adherence to established practices be holding back your cartographic potential?

No Comments

Colorado Geo Meetups, Groups, and Lists

 

Are you a Colorado geo-professional who would like to do some networking while learning more about all things spatial? I recently put together this list of resources for those residing in our state–along with a couple of more general twitter groups–and wanted to share it on the blog. Anything I left out? Please tweet me or write a comment.

 

Meetups:

Maptime Boulder. Evening gatherings to learn together, sometimes OSM focused. Beginners welcome.

GeoDev Meetup Group. Run by Esri. Typically in Fort Collins at the Rio.

NoCo GIS Users Group. Run by Brian Sullivan, presentations and networking. Loveland, Greeley, Fort Collins, the location rotates.

Geospatial Amateurs, Denver. Run by Peter Batty, Brian Timoney, and Nate Irwin. Local pub, evening gatherings, networking time plus a few presentations.

MaptimeMileHigh, This group is just getting started. Evening gatherings to learn together, sometimes OSM focused. Beginners welcome. @maptimemilehigh on twitter for updates.

 

General code groups/contests:

Women who Code Boulder/Denver.

Go Code Colorado

 

Lists, etc:

Rocky Rogues. They do “night out” events and also maintain an online job board.

GIS Colorado an active listserve and website.

GIS in the Rockies Conference

 

Twitter groups, non Colorado focused, you can follow along even if you’re not on twitter:

#geowebchat, 1:00 MT on 1st Tuesdays

#gistribe, 1:00 MT on Wednesdays

 


 

 

No Comments

When do you call yourself a cartographer?

Q) When do you call yourself a cartographer?

A) When you

  • Spend sufficient time on revising that it is as if your reputation and your finances are at stake (whether they are or not).
  • Study modern and historic maps on a regular basis for both general insights into the creative process and practical ideas about color, font, layout, and symbolization.
  • Begin with the design idea and then look to see how it can be achieved.
  • Constantly dabble in or otherwise familiarize yourself with new technologies that can expand your mapping repertoire.
  • Keep track of new data that can support projects in the pipeline and beyond.
  • Learn to decouple the data from the design at the end stages of a cartography endeavor on one-off design-heavy masterpieces (e.g., use Illustrator or Inkscape).
  • Create and follow a shop book that contains typefaces, color palettes, and feature size, shape, and width guidelines. Examples of maps that follow common guidelines include most of the largest news outlets including the New York Times and The Economist. (There are exceptions.)
  • Realize that in cartography there are exceptions to the rules. There are always exceptions.
  • Understand that cartographic feature symbology defaults are almost never adequate from a design standpoint (e.g., what size should the points in a user-supplied dataset be? It depends on the number of points, zoom level, background map, and so on.) Someone will probably come up with an elegant algorithm to solve this in the near future. But until then generalized defaults have to suffice.
  • Compile a portfolio of your work and have hundreds of finished maps to choose from.
  • Know that finished maps are both personal to you, and personal to your map readers.

4/24/2015 Edited to add twitter commentary from ever faithful readers:

 

 

 

As a result of all this I’m going to add one more bullet point:

  • You can call yourself a cartographer when you are a NUT.

No Comments

Opportunity Costs: To Make the Map or Not?

If you fear making a map due to the critiques it might engender, think of it this way:

Is the opportunity cost of not making the map that you won’t steer people wrong…literally? Then it’s important to re-think the map data and concept. Maps with incorrect information that you have sufficient belief that people will rely on should not be published. All maps have some incorrect information so you would need to ascertain the severity of the incorrect information (is there a road that will lead drivers over a cliff?) as well as the quantity of the incorrect information and then make a subjective decision.

But, if the opportunity cost of not making the map is that you don’t embarrass yourself by putting something ugly or even maybe unusable out there, then still consider making the map. After all, you have to start somewhere. We all do. We’ve all made ugly maps and maps that nobody has used. Like the child who stops drawing after kindergarten, we mustn’t let our unfounded “lack of creative talent” become a blocker. Creative “talent” is borne of experience and trial and error, not innate capability.

1 Comment

Friday Thoughts on Cartography

Today a few of us decided to create a new organization called Emotional Cartographers Anonymous. While I am decidedly not an emotional cartographer–in fact there was another faction arguing for a Rational Cartographer’s Guild or some sort that I would be a reasonable fit for–I think it would be rather fun to attend an ECA meeting. I imagine there would be lots of shouting concerning the acceptability of halos on labels, old-school vs. new-school color schemes (think light vs. dark), and of course an open source vs. proprietary discussion in which someone inevitably brings up child labor. Or something.

And when we’re done with the meeting we can all gather around and have some map cake, which won’t make us upset at all.

USA Cake

All kidding aside, I also managed to publicly declare today that: You really have to understand the infrastructure underlying your map to be an effective cartographer. This statement received a fair bit of attention on twitter. The reason I’m pointing it out is that it may seem like a departure from my oft-repeated stance that to be a good cartographer you have to learn the fundamentals of cartographic design independent of the software tools.

If you think about it though, these are not two opposing ideas. It is true that excellent cartography is based on a sound foundation of basic principles as well as application of both analytical and creative forces to the data and design. None of that has to do with software and shouldn’t be constrained by software.

If you want to create a certain visualization that is perfect for your purpose and you don’t have the ability to do that within your normal day-to-day software then you should seek software that does offer that functionality (or, if you’re a dev type, build it). In other words, I don’t have to teach software in order to teach cartographic principles.

Figure-ground differentiation, label-font hierarchy, balance of margin elements, choropleth color maximums, and many other principles remain the same regardless.

However, what I perhaps have not emphasized enough is that there’s also a need for the cartographer to understand exactly how features and maps are created, stored, styled, modified, updated, and published in order to have a maximum of control over stylistic changes. In short, if you can’t operate your map stack technology then you’ll be relying on others to do it for you, which will represent a significant delay in getting edits published. It also leaves a gap in your knowledge of what the possibilities/capabilities of your stack are.

So, learn cartographic principles. That’s key. Also learn data analysis, general design, and creative skills. Finally, learn your software, whether that’s traditional desktop GIS or an entire map stack comprised of a map server, a statistics package, a web mapping client, a tile cacher and so on.

This is a lot and you probably can’t be an expert in all of it. In fact, team effort is fully warranted, particularly if you are serving up complicated maps. For sure a lot of speed is garnered from a team that has a server expert, a styling expert, a design expert, a front-end developer, and so on. But a cartographer should be familiar enough with all these pieces to be able to at least ask the right questions and coordinate the experts to provide a substantial, informative, and timely map product.

 

2 Comments

Friday Reading

Some Friday reading for you.

No Comments