From Cory Eicher

Monday, February 27, 2006

Cartography in GIS: It's not just assigning symbols to geometry

I saw that James just posted about Cartography and ArcMap ... actually, before I even saw it, a few colleagues emailed me to tell me that they saw it. Helpful people that they are, they knew that I'm looking for ideas for my blog. So, for this entry, I'll piggy-back a bit on James' post.

Color Brewer
First, a great online resource for cartography that everyone should know about is Color Brewer (www.colorbrewer.org). This site was created by Dr. Cindy Brewer and Dr. Mark Harrower both cartographers, and this is the place to go online if you're not sure about what colors to use on your maps... and believe me, you're not sure about what colors to use on your maps! The site can basically be used as a "map colorer", telling you which colors/schemes to use for different types of maps and data.

Evolution of cartographic facilities in GIS Software
Yes, there's some exciting new functionality coming in 9.2 for cartography. Admittedly I'm a bit biased since I knew this stuff from inside ESRI, but perhaps I'll do some more convincing for your here.

9.2 cartographic representations allow you to edit feature symbology on a feature by feature basis. Pretty powerful as you can imagine for cartographers, but also as ESRI's Paul Hardy likes to say, for people that "just want a better map". Oh, and please don't forget the database! Symbology edits are stored in the geodatabase together with the feature data. Have you been waiting for ESRI to store .lyr/.mxd information in a database? Well, this is the first step...

Is 9.2 the beginning of better cartography from a GIS software package...? Of course not. Sticking with ESRI products, I'd say that a lot started with the ArcView 1x/2x/3x packages. In my opinion, GUI-based software can, and I emphasize _can_, produce better maps. Sure, people got by with ArcPlot, but GUI-based software a) makes "trial and error" easier (although I wouldn't recommend trial and error printing to large format printers when you're footing the paper/ink bill...), and b) GUI-sofware tends to be more WYSIWYG than say, creating maps from a command line app. 9.2 cartographic representations (call 'em reps for short) extend WYSIWYG capabilities in ArcMap by providing the ability to edit symbology.

9.2 cartographic representations aren't just editable symbology, they also employ better "automated routines"... (think better symbols). With reps, your maps can have better dashed lines, you'll have more control over the placement of symbols along lines, etc... Cartographers will eat this up, probably starting at the "top". What I mean by this is, organizations that have really strict cartographic requirements will be the first set of users attracted to this functionality. But, the usefullness of reps will have their use trickle down to many, many users...

A New Editing Paradigm?
Ah yes, paradigm, the word that I, the engineer, heard but wasn't quite sure how to spell during the first weeks of my graduate education in geography. 9.2 also provides new representation editings tools. Simplifying things greatly, these tools are "illustrator-like" allowing you do do things that just aren't very easy using the standard arcmap edit tools... such as modifying multiple features at once. Cartographers need to do this all the time (think offsetting several road line segments from a creek or river) and they don't want to think about topology when they do it, at least not in the sense that this is necessary in the pre 9.2 ArcMap editing experience.

Depending on how 9.2 reps are received by the public, in my opinion, their usability could spell big changes for the data-editing experience in ArcGIS... There are rumors of a huge change to the look/feel/architecture of arcgis at the next major release (10.0?). A big change to editing could be part of this.

Understanding Cartographic Representations
Are cartographic representations hard to understand? My answer is, yes, er.. possibly. James' UC blog post suggested that reps might be hard to "get", and I know that even big ESRI customers that use ArcGIS for cartography want more detailed information about how they can best use this new technology.

The Devil is in the Data
Like a lot of other things, when you need to do a lot of something with GIS, and do it often (such as produce a lot of maps, and produce frequent updates to these maps), it helps: a) to have your data in a database -- hopefully the ESRI geodatabase ; ), b) to have well modeled data, and c) to have well defined processes for creating and updating your data.

My experience with dealing with organizations that produce a lot of maps from GIS is that, well, most of their work isn't in the cartography, it's in dealing with the data... I'd postulate that this is pretty universal, whether you're producing maps, or performing watershed analyses, it helps to have a), b), and c) in pretty good order.

Design is Important
Design will always be important in cartography. It's no secret that most cartographers would like to see better maps than what we're currently seeing. Some of us (not me certainly) are like film critics: we'll tell you what we like and what we don't like, but we probably won't be able to (or won't want to?) tell you how to get there from the start.

The evolution of tools for cartography in ArcMap offers the promise for "better maps", but everybody knows that the ArcGIS 9.x Geoprocessing tools/environment didn't immediately start producing better glaciation models or better site selection analyses... I'd say that the same goes for new 9.2 cartography tools. There's potential for better maps, but resources (online, as James mentioned) and I'd add software documention and even software defaults, are needed to help end users benefit the most from new functionality...

... after all, anyone that's worked with the ArcView 3x technology has problably seen the, well, hideous jagged lines that appear by default in ArcView legends. Not to pick on anyone, but here's an example. The problem is that that this "toppled Z" symbol is the default legend pattern in the software, and not than many people change software defaults. One consequence of this is that you can still peg an ArcView 3x map simply by the appearance of lines in the legend.

Talk to you soon,

-Cory

15 Comments:

Dylan said...

Interesting post. I have often wondered why people don't spend more time on the cartographic "quality" of maps that they produce with a GIS - and it might be as simple as someone sticking with the defaults as good enough. The reference to the ColorBrewer website was a good addition to this topic- just as it is simple to peg an Arc-product derived map based on a nasty legend, the same can be said for the default color schemes. To add a bit of perspective from the open source map making world, the generic mapping tools (http://gmt.soest.hawaii.edu/) offer an excellent approach to digitial map composition, entirely from the command line. Here is a link some examples of maps created with GMT: http://casoilresource.lawr.ucdavis.edu/drupal/node/102

Cheers,

Dylan

7:56 PM

 
Cory said...

Thanks Dylan for the comment and the links...

-Cory

11:37 PM

 
Anonymous said...

This post has been removed by a blog administrator.

1:33 PM

 
Anonymous said...

This post has been removed by a blog administrator.

10:07 PM

 
Anonymous said...

This post has been removed by a blog administrator.

2:04 PM

 
Anonymous said...

This post has been removed by a blog administrator.

7:07 AM

 
Anonymous said...

This post has been removed by a blog administrator.

4:25 PM

 
Anonymous said...

This post has been removed by a blog administrator.

3:07 PM

 
Anonymous said...

This post has been removed by a blog administrator.

10:09 PM

 
Anonymous said...

This post has been removed by a blog administrator.

9:37 AM

 
Anonymous said...

This post has been removed by a blog administrator.

10:18 AM

 
Anonymous said...

This post has been removed by a blog administrator.

7:35 PM

 
Anonymous said...

This post has been removed by a blog administrator.

8:13 AM

 
Anonymous said...

This post has been removed by a blog administrator.

8:13 AM

 
Anonymous said...

This post has been removed by a blog administrator.

11:49 PM

 

Post a Comment

<< Home