Skip navigation

Category Archives: geologic mapping

I do have a couple of new toys for the digital mapping crowd, but I only have time to post a totally cool aerial image of a part of Nevada that I am working in:

Effects of flooding on alluvial fan along the east shore of Walker Lake, Nevada

Effects of flooding on alluvial fan along the east shore of Walker Lake, Nevada

This image of an alluvial fan along the east shore of Walker Lake, Nevada is totally cool, no? Check out the way the flood interacts with the array of recessional shorelines that record the demise of the lake. Gotta grow alfalfa to feed cows to feed people, right? Surely they grow some other stuff upstream…In any case, the geomorphic signature of lake shrinkage is striking and, combined with the natural demise of the lake since the late Pleistocene, provides an obvious succession of timelines in the landscape that are quite useful for constructing a chronology of events.

Note from Kyle: A new contributor has entered the froth! I think he is smarter than I am…

We’ve all read Kyle’s rants against paper maps, and we’ve all seen some of the potential for online, digital mapping by using websites like MapQuest or software like Google Earth. So if we want to try and step away from producing flat, paper maps and want to be able to share our digital geologic data with each other, what kind of format are we going to use? The answer is that we’re going to need to learn to use map services.

Your users are desperate to get your data

Your users are desperate to get your data

What is a map service? Think of it this way: Your map and data exists on a computer somewhere that everyone can see over the Internet. Everyone wants to see your map data, but you can’t just open the barn doors and let them all tear into it. Think wolves starved by the longest, harshest New England winter suddenly turned loose inside the barn where your sheep have been warm, toasty and chubby for months. This just won’t do. Instead of a wild feeding frenzy, you need some organization. A map service provides organization by specifying how to ask for the data, and how it will be returned. In these terms, a map service lets the wolves have all the sheep they want, as long as they ask nicely.

This allows for a variety of client applications (for example your web browser, Google Earth, or ArcGIS Desktop) to provide an interface by which people can look at your map data. As long as an application knows how to ask the right questions, and what to do with the answers, it will be able to view the map.

Map services are an important step in moving our geologic maps off of paper and getting them online. They allow us to share both our data and our cartographic work with each other. Ever downloaded a “map package” that consisted of an indecipherable slew of files, databases, interchange formats, acronyms and cryptic field names? Well map services are the solution, providing not only an image of your map, complete with all the cartographic work you put into it, but also a simple interface for grabbing the data itself.

At the Arizona Geological Survey, we’ve put together a map service for the geologic map of the State of Arizona. You can view it here:

AZGS Map Services: Geologic Map of Arizona

Quickly and easily view and query the map within ArcMap

Quickly and easily view and query the map within ArcMap

In the future we’ll be putting together more and more of these services, and including with them more information – photos, field notes, descriptions of important contacts and structures, etc. Perhaps the most intriguing part of all this though, is how easy it is to create these map services. If you have a functioning web server and have access to ArcGIS Server, then you have absolutely no excuse not to start figuring out how to use it. If you don’t have a web server or ArcGIS Server, well, stay tuned, because the AZGS is also working on putting together a software package, or “stack”, of entirely free, open-source applications that do very similar things to what ArcGIS Server can do. Our goal is to make it possible for everyone to begin exchanging maps and data using map services.

I recently came across Scribd while reading the New York Times online (during lunch of course). Turns out that this is a very useful site to store and easily share a variety of documents. Given my obsession with maps–both analog and digital–I investigated further and soon started uploading all of my maps that are worth uploading. It is simple to say the least. It also turns out that it is simple for someone on the other end to comment on your map, to download your map, and to send it to their plotter / tree-killer. You also have the option to make your uploads private so that you can only share a map, poster, document, etc., with selected colleagues.


The interface takes a few seconds to minutes to figure out. It is a cleaner, more efficient, and more user-friendly interface than the one hosted by my agency. It may not be for you, however. It also requires that you are willing to freely provide maps showing data that were compiled with (usually) tax-payer money. Hopefully the extreme budget crisis facing my state will not force me to pull down the free maps.  Check out my uploaded maps using the Scribd link in the right sidebar.

Ok. I moved the blog. This is my inaugural post.

Lately I have been desperately trying to finish up some maps that are really going to get in the way as a huge project looms larger and larger…and I mean larger. Today I spent some time working on the Spirit Mountain Northwest Quad.  This is one of those maps that has some intricately stacked  stuff in a few relatively small areas that are separated by large swaths of planimetrically intricate but geologically straightforward surficial deposits. Also, this map has a big fat lake in it…freebie! Right?

Well, no. Turns out that I am interested enough in the history of the Colorado River to have claimed that I will do what I can with what is available to map the submerged geology. Luckily, the USGS recently published a bunch of sidescan sonar data for the lake bottom: as well as an interpretation of the imagery:

It turns out that the latter publication suffered from an unawareness of existing, pre-reservoir topographic maps. Nonetheless, their interps are good, but can be improved by evaluating the sonar image in conjunction with the historical map. Notably, the historical map is a detailed plane-table topographic survey by the USBR in 1939. It includes topography as well as some geological and ecological descriptions. Very handy. Combining these sources of data with my familiarity of the river in general and from 1939 aerial imagery of other, roughly similar reaches I can develop a map with reasonable confidence.  It is actually pretty helpful to have a good characterization of the river for interpreting the lower piedmont relations.

I am not yet finished with the terrestrial or subaquatic mapping, but thought I would share while I figure out a new blogging program (note that North is to the left in the maps):

DRG with draft Geolines

DRG with draft geolines including lake bottom lines

Historical Land Survey

Historical Land Survey with draft geolines and useful annotations.

Sonar image (not elevation, but return intensity)

Sonar image (not elevation, but intensity). Amazing stuff for a guy like me.

A colleague and I recently finished up the north half and you can check out the preliminary version here. I am now busily mapping away on the south half as well as the bottom of the lake.

We (I have some partners in crime now) have recently been exploring the application of generalization routines in Arc to one of my excessively detailed published geologic maps. As part of a larger mapping effort (ND2MP: The Nevada Digital Dirt Mapping Project) I am walking the fine line between the rationality of automated generalization and the impracticality of manually generalizing detailed mapping that I have already completed.

A lot of basic concepts of cartography in general and geologic mapping in particular come to the fore when you start visualizing blotch maps (i.e. those based on polygons) at different scales. Some interesting complexities involving the analog to digital map world also arise…those issues will eventually be aired on the ND2MP blog. For now, I will show some of the results of automated generalization routines in Arc.

The detailed map in question is NBMG Map 156, a map of Ivanpah Valley, Nevada that was compiled at ~1:12k but was released in Dead Tree Edition at 1:50k so it would fit on the plotter/tree killer.

After perusing various options, we decided that the ‘aggregate’ generalization tool was the closest to what we wanted…but not exactly what we wanted. This tool melds polys/blotches together on the basis of only a couple of criteria: how close together two like polys can be before they meld into one, and how small the resulting polys (or holes) can be. Both of these concepts involve deciding on a minimum mappable unit (MMU) dimension (a post and discussion for another day fellow mappers).

The map below is an ungeneralized version of a part of the Ivanpah Valley map (in this case the Jean 7.5 Quad) shown at (roughly) 1:150k:

A generalized version wherein two groups of the most intricately mapped surficial units are aggregated is shown below at the same scale (the yellow and red ones):

At face value, the lower map is a bit more legible. In this instance we aggregated like-polys that were less than 40m apart and eliminated polys (in the same group) that were smaller than 5 ha (50,000 sq. meters). We are considering an MMU of 9 ha for a final compilation of Clark County surficial geology to print (yes…I said print) at 1:150k. Note that the centroids of the eliminated polys will be retained as a point data set in case it actually matters that they are gone.

The generalization routine shown above essentially eliminated numerous reaches of narrow, active desert washes. We are interested in retaining these for various reasons, but maybe only as lines. If anyone has a suggestion for how to extract the lines from the eliminated wash reaches as part of the generalization process (or has a suggestion for a better generalization routine) please speak up!

Here are the maps side by side for better comparison:

No, not because I spend so much time hiking in the desert or because I lugged way too much crap down the South Kaibab Trail last month…not those quads. What is killing me is being a victim of mapping 7.5 minute quads. Mapping 7.5 minute quads is a waste of time. It is efficient only in a clerical sense, not in a scientific sense. Mapping on the basis of 7.5 minute quads amounts to mapping in a rectangular frame with boundaries that are (aside from some amazing coincidence) completely arbitrary with respect to geology.

Obviously, the implied goal of mapping 7.5 minute quads is to allow for a systematic framework for eventually mapping a bunch of officially circumscribed rectangles that cover an entire state or region. The key words here are ‘officially’, eventually’, and ‘rectangular’. Morevover, the concept of mapping quads is so deeply mired in the deeply pre-digital history of the USGS and the history of printing that it has become an ultra-anachronism.

I have been foolish enough to map a patchwork series of quadrangles along the lower Colorado River in an attempt to better understand the river’s geologic history. Each time I move into a new quad, I learn more about that history (or more variations on it) that inform previous maps. Why in the hell I didn’t just try to get funding to map the deposits of interest along the corresponding length of river is beyond me. Eight years later, I am still trying to finish some of those maps (sure, I am a perfectionist, but there are other reasons).

My most ambitious mapping project, the Ivanpah Mega-Map (Ivanpaviathan), is a classic example of how mapping quads can (temporarily) wreck your life. In that case, I stupidly proposed to map the entirety of all of the quads that fell even partly into the boundary of the watershed of interest. WTF? What an idiot. That is how mired I was in the Quad Mapping Model (QMM). I paid and paid dearly for that bit of stupidity.

My job involves mapping a lot of quads in Nevada. My agency has a goal of eventually mapping the entire state. Ha! That is not going to happen at 1:24,000 in my or my kids’ (or their kids’) lifetimes. In fact, this is simply not going to happen ever! Deal with it. Pick the areas that really matter (for whatever reason you like) and map them. Don’t worry, you can still circumscribe the area with a quadrilateral that has easily defineable corner coordinates….

I attended the USGS-AASG sponsored ‘DMT’ meeting for the first time this year. I should have been attending this meeting for the last several years. This year, it was in Moscow, Idaho. I applied too late to give a talk, but forced myself on the audience anyway under the guise of a discussion.

Principal Take Home Messages (through the cynical filter of DrJerque):

1. Paper maps aren’t dead, but they are dying, albeit slowly.
2. ESRI is coming to terms with the power and sway of Google Earth and kml
3. Existing USGS 24 k basemaps are no longer loved by all (and hated by some)
4. LiDAR kicks proverbial butt.
5. Some geologists still use Garmin 12xl GPS units….ouch!
6. Geotagging digital photos is still news to some.
7. Geologists are generally uninterested in carting computers around in the field.
8. Many state surveys still publish maps using graphic arts programs.
9. Archiving digital data is a major concern.
10. Geologic data standards are emerging. They need to be adopted.

Geotagging photos, diagrams, and map excerpts is an excellent way to aid in illustrating stratigraphic and geomorphic relations to colleagues. I have recently been doing field work in the Lake Mohave area and have photographed some key outcrops (see related posts here and here) that may be of interest to colleagues who are also trying to understand stratigraphic relations along the lower Colorado River. The slide show below includes those photos and illustrates another way to share geodata online.

Want to see the images on a map? Click this link and then you can view as online photo album or you can view it in Google Earth for the full effect. In cases where high resolution imagery is available, it only takes a little geo-imagination to comprehend the context of the image. No match for a field trip per se, but I think that it is one hell of a lot more illustrative than a discussion over the phone or showing a slide in a talk if you are simply trying to share information about a key outcrop.

I am currently experimenting with integrating several of my projects with online geotagged photo albums that include annotated stratigraphic diagrams, photos, and geologic map snippets. This is in the interest of developing quasi-interactive geologic data sets available for online evaluation, commentary, and review.

Digital geologic mapping has many advantages over ‘analog’ mapping. A really big one that is often ignored is the utility of a desktop digitizing tablet. Clicking away with the mouse along an elaborately shaped contact trace is bad for your wrist (and possibly, your brain) and falls far short of the speed and accuracy of using a pen. Just try writing your name in script with a mouse if you don’t believe me. Most of us have been using writing implements in our hands since we were toddlers. I use a Wacom Intuos Tablet at home and at the office and can’t imagine doing it any other way. You can program buttons on the pen and on the tablet to perform common program tasks to un-tether yourself from the mouse and the keyboard.

On the road and in the field I use a Tablet style notebook PC which allows you to use the pen directly on the screen.

A far better option for office use is a Pen Display:

This would be an extremely useful addition to any GIS / mapping oriented enterprise, no?

For the times when you just need paper but want to stay digital, there is a way. ADAPX has developed a digital pen and digital paper product that is rugged for the field. Check out the website:

Below is a snippet from their website (looks promising):

More Power to Paper with Digital Data Collection

Using Capturx for ArcGIS, you get fully digitized GIS data from paper maps automatically. Because you don’t have to change the way you work, you eliminate the need for additional training on data collection, importing, and editing processes.

Capturx for ArcGIS is a powerful, easy-to-use, digital data collection solution that enables you to keep using paper maps. If you use ESRI ArcGIS® 9.2, the Capturx for ArcGIS extension is the ideal way to create, import, edit, share, and act on paper-based data in and between geographic information systems (GIS).

Capturx for ArcGIS 9.2 enables you to print out any ArcGIS map and feature legend on digital paper, and then make changes and annotations to the map in ArcGIS by simply writing on the printed map.

There is no need to modify your existing ESRI products because Capturx for ArcGIS can be used with any ArcGIS Desktop licenses, including ArcView®, ArcEditor™, or ArcInfo®, and is compatible with geodatabase feature classes, such as personal and enterprise ArcSDE®.

Image Download the datasheet for a complete list of key features.

This is a huge topic for geologists using Arc software. Here are some basic tips (many more will be added over time):

1. Make sure you have ‘snapping’ on. This is a two-tiered issue. Most importantly, make sure that you have two options selected in the ‘Edit sketch’ window. This will ensure that your draft (sketch) lines will snap. This is particularly relevant for sketching closed features.

2. Build topology for the geolines layer. This is simple. The most basic need is to enforce the ‘no dangles’ rule. This will flag sites where your lines overshoot or undershoot. Undershooting lines will not build polygons. Overshooting lines are unnecessary.

3. If you use ArcInfo, be sure to select the ‘overwrite geoprocessing operations’ option in the ‘Options’ menu. Doing this allows you to build polygons repeatedly into the same polygon layer, thus keeping only one layer and also retaining the layer’s graphic attributes (i.e. colors and patterns. Note: In ArcEditor, you can only build polygons in ArcCatalog and you cannot build into an existing polygon layer as previously described.