Digital Mapping Techniques '04— Workshop Proceedings
U.S. Geological Survey Open-File Report 2004–1451

Geologic Data Assistant (GDA): An ArcPad Extension for Geologic Mapping

By Ralph A. Haugerud¹ and Evan E. Thoms²

INTRODUCTION

For two centuries, geologists have traveled with pencil, notebook, and base map and returned with records—field data—that support the production of geologic maps. At earlier DMT workshops there were reports on experiments using a computer to collect such field data, including a special session at DMT’01 (Soller, 2001). Reasons for exploring digital solutions have ranged from more rapid production of paper maps (Brodaric, 1997; Williams, 1997; Walsh, 1999), more efficient field work (Pavlis and Little, 2001), and more efficient creation of digital map data (Williams, 1997; Brimhall and Vanegas, 2001; Brimhall and others, 2002; Edmondo, 2002; van de Poll and Parsons, 2003), to better visualization of spatial relations (see the GeoPad effort at http://geopad.org).

We have followed these experiments with interest, looking for a digital field solution that increases the efficiency of our regional-scale (1:12,000 to 1:100,000) geologic mapping. In particular, we desire a field data collection system that:

• Transparently incorporates location that is determined by GPS,
• Allows use of digital base materials (assessor’s parcel maps, lidar topography, high-resolution orthophotos) that are commonly not available in paper form,
• Facilitates the collection of feature-level metadata (observer, time of observation, spatial accuracy and precision, etc.),
• Encourages standardization of observations, and
• Records data in structures and formats that can be translated by machine into our project-level geologic map databases.

We wish to accomplish these objectives while maintaining the portability, richness, flexibility, and graphical nature of the traditional notebook and field map.

Some digital solutions have depended on the processing power, operating system, and storage of a laptop (or tablet) computer. These are a problem because of the consequent bulk, weight, limited battery life, and excessive cost of ruggedized systems. Other solutions have used handheld or palmtop computers (personal digital assistants or PDAs) with software that does not support on-the-fly plotting of new observations. These are unacceptable to us because spatial reasoning from new observations is an important part of the mapping process.

ESRI’s ArcPad™ software, running on an off-the-shelf PDA with a daylight-readable color display, has the potential to bypass these limitations (e.g., Edmondo, 2002). At version 6, ArcPad incorporated an easy interface to commonly-available GPS units. ArcPad can now support many of the needs of geologic mapping, but to do so requires the development of a customized application. Such customization is costly: $1,500 to purchase ArcPad Application Builder, weeks to months of time to learn VBScript and the ArcPad object model, and days to weeks of coding and experimentation. The difficulty of customization seems to be reflected by the fact that in early July 2004, a Web search for “ArcPad application” geologic mapping yielded only a handful of pages, none of which offered a system that could be used for general geologic mapping without further modification.

Geologic Data Assistant (GDA) is our effort to fill this void. It is an ArcPad application that works well enough for Haugerud to use it routinely instead of a field map and notebook. We are publishing the GDA code (Thoms and Haugerud, in preparation) for the benefit of geologists who may find it a useful tool, and to encourage others to improve upon our efforts.

In the course of developing GDA we found ourselves examining our geologic mapping procedures more closely. We made compromises between the richly-structured geologic database of our dreams and the capabilities of ArcPad. We learned by trial and error that certain design choices were critical. This paper describes GDA and what we learned while developing it.

HOW GEOLOGIC MAPPING WORKS

Many person-years of experience with regional mapping suggest the following essential elements of a field-based geologic mapping process:

1. Before going into the field, one:
   • Assembles base maps, and
   • Compiles the results of previous geologic investigations.
2. While in the field, each geologist in a party develops a set of field data. This consists of several elements:
   • Field notebook, organized by station number, with stations numbered consecutively. Notes for each station commonly are formatted in some fashion, but may contain extensive free-form text,
   • Field map, that includes locations for all stations as well as graphical representations of many of the elements (particularly structure data, map units) recorded in the field notebook,
   • Short segments of contacts, faults, and unit polygons that are sketched on the map, and
   • Samples, photos, sketches, and other items. There may be zero to many of these elements at each station.
3. The mapping party maintains a compilation map that commonly has two elements:
   • Station (and sample) inventory, and
   • Compilation geologic map that adheres to geologic map rules: it shows units, contacts, and faults; it shows selected structure data; it has topology (i.e., certain topological constraints among lines and polygons are enforced), and it is inked and colored.

When one geologist is working alone, this process is still maintained.

The best geologic mapping is an exercise in graphical reasoning, using the topology and geometry of previous observations to guide the remainder of a traverse. We find that as we mature as mappers, we do more of our work on our field map and record less information in our field book. A digital field map is at least as important as a digital field notebook.

Note that field data are not simply a preliminary version of the completed geologic map. First,—at least at the beginning of a mapping project—field data serve to document an exploratory phase: What units are mappable? What lithologic and structural details are key to distinguishing them? At this stage of investigation one’s data structure must allow for evolving lithologic and stratigraphic vocabularies. A paper notebook and pencil are quite effective for this. Only later does one shift to the focused observations that make database design easy, and the controlled vocabularies that make database implementation efficient. Second, field data commonly contain numerous elements that are not preserved on the final map: the name of a landowner; whether a dog is friendly; the weather; who (in a multi-worker effort) made an observation; how, and how accurately, a position was determined; and, extensive lithologic detail and stratigraphic and structural speculation. Third, most workers find that their field maps are not geologic maps because not all contacts and geologic units are identified. With more complete fieldwork, a field map may closely resemble a geologic map but, commonly, full interpretation of an area depends on laboratory analyses, additional data from a colleague, or simply further thought.

ABOUT GDA

GDA is an extension to ArcPad, which is a simplified GIS for Microsoft Windows CE / PocketPC that also runs on Windows 95/98/NT/2000/XP. ArcPad is published by Environmental Systems Research Institute, Inc. (ESRI) and has moderately good display capabilities, good projection capabilities, and an excellent GPS interface. ArcPad cannot build, or even enforce, topology (e.g., find line intersections, interconnect line segments to form polygons) or handle sophisticated database operations (e.g., natively support relationships between tables).

ArcPad supports the limited display of raster images and shapefile-format vector files. Raster images are shown as opaque layers and cell values cannot be queried, thus they are most useful as backgrounds to vector data. Shapefile features are symbolized simply: polygons must be empty or filled with a solid opaque color, lines cannot be dashed, and basic geometric shapes or TrueType characters are used for points. Individual point symbols can also be rotated based on the value of a feature attribute. Shapefile features can be created, deleted, or moved. Editing of the geometry within individual features (e.g., moving part of a line) is difficult or impossible. Attributes of shapefile features can be edited through forms where values are entered either by hand (using an on-screen keyboard or through handwriting recognition software) or by choosing values from picklists that allow standardized attributes. Multiple shapefiles can be displayed as superimposed layers.

GDA (Figure 1, Table 1) extends ArcPad with custom XML (St. Laurent, 2001) and VBScript code. It adds 4 predefined layers in shapefile format (Stations, Structures, Geolines, Mylar), a handful of external DBF tables (Geologists, StrucTypes, Units, Photos, Samples), a toolbar to readily add new features and manipulate these layers and tables (Table 2), forms for creating and attributing features, and code to enforce one-to-many relations between the Stations shapefile and external subtables (Samples and Photos, see Table 1). Optionally, a free-form text file of extended notes can be created for any station.

Figure 1. A GDA screen view. The upper two toolbars are standard ArcPad, whereas the lower toolbar is created by GDA. The map shows a digital raster graphic (DRG) of a standard 1:24,000-scale quadrangle map as backdrop, and dots, colored by map unit, at previously established station locations.

Table 2. Tools on the GDA toolbar.
Name			Description
	AddStation		User adds a point where the station is located, and the Stations data entry form appears.
	StationAtGPS		Station is located by GPS, and the Stations data entry form appears.
	AddLine		User adds a line to Geolines.shp, and the data entry form appears.
	DigMylar		User adds scratch lines, annotation, sketches, etc. to Mylar.shp.
	OffsetStation		User provides a bearing and distance from current station to the next, and the Stations data entry form appears.
	Archive		Current data shapefiles and .dbf files are copied into an archive directory, and the map is re-opened with empty shapefiles.
	ToggleDrawToolbar		Toggles the ArcPad Draw toolbar on and off to either quickly expose shape-editing tool or maximize screenspace.

Most GDA picklists are stored within external DBF files and are related to a particular shapefile’s data entry form through VB script. GDA incorporates code so that some of these lists are self-updating. For example, at the start of the day the choices for Lithology of a certain unit might be gravel and sand. If one enters, as free text, gravelly sand for Lithology, the next time that particular unit is mapped the picklist for Lithology will have three values, gravel, sand, and gravelly sand. Each instance of GDA supports independent picklists—though as a mapping project evolves, it may be desirable for project participants to standardize picklists through compilation and discussion.

GDA can support multiple ArcPad mapping projects on a single PDA. Each project is a separate directory in the file system and has its own map projection, data layers, base layers, and picklists.

Because ArcPad performance declines with large, editable layers, and to add discipline to the process of uploading data from the PDA to the PC where map compilation occurs, GDA provides an archive feature. When invoked (typically daily), current data-layer shapefiles are moved to a new subdirectory; DBF files that define picklist vocabularies are copied to the same subdirectory; and empty, data-layer shapefiles are installed in the working directory.

Hardware and software needed

To use GDA in the field, one needs a Windows CE / PocketPC-based PDA with daylight-readable color screen (e.g., a Hewlett-Packard (HP) IPAQ). Some form of non-volatile memory for field data, coupled with a large amount of memory for images, is highly desirable. We add to the PDA an expansion pack with an extra battery and support for a Compact Flash memory card.

A GPS unit that communicates with the PDA is useful. For mapping at scales of 1:12,000 and smaller we use credit card-sized recreational GPS receivers (circa 10m accuracy, with averaging) that have no display and communicate via Bluetooth (short-range high-frequency radio; http://www.bluetooth.com) with the PDA. Because the PDA often is carried in a vest pocket, a GPS unit inside the PDA would be shadowed by the user’s body and thus is less desirable.

An IPAQ with expansion pack provides 12–14 hours of battery life. The Bluetooth-compatible GPS units have internal batteries that run for 6–7 hours before they need recharging. With ruggedized case, total cost for this hardware is about $1,000. Long traverses might require an external battery or a second GPS unit. Bulk and weight of this configuration are minimal (Figure 2).

Figure 2. GDA hardware. Top: Silva compass for scale. Middle (from left to right): ruggedized case, Hewlett-Packard IPAQ PDA with CF-card expansion pack, Socket Bluetooth GPS receiver. Bottom: the top of a scepter improvised from plastic pipe fittings that drops into a rucksack and carries the GPS receiver above shoulder level.

ArcPad version 6.0.3 costs $495 for a single-use license. An evaluation copy with full functionality—but that must be restarted after 20 minutes—is available for free download from the ESRI web site. GDA is freely available on the web (Thoms and Haugerud, in preparation).

A DBF editor is handy for creating initial picklists and for modifying picklists outside of an ArcPad mapping session. A DBF editor that runs on the PDA would be ideal, but we haven’t found one. We use Microsoft Excel on a Windows PC.

You can use GDA in the field with this hardware and software alone. To create custom base maps, to specify symbology, to compile multiple GDA data sets, and to create a compilation database with full topology—the digital equivalent of a compilation map—from GDA notes, most users will find it necessary to have a full-fledged PC—either laptop or desktop—with ESRI’s ArcGIS available at camp or back in the office.

Uploading and compilation

We upload GDA data to the PC by copying each completed archive directory. We commonly do this by removing the Compact Flash card that hosts the GDA project directories from the PDA and installing it in the PC, then copying the archive subdirectories to the PC’s hard drive. When appropriate, we incorporate digital photographs and other non-GDA digital data elements into the archive directory.

How we import GDA data into the compilation database on the PC depends on the GIS that is used for compilation. In ArcInfo, we run a script that converts the shapefiles in the archive into coverages. In ArcGIS, the shapefile features are appended to geodatabase feature classes in either ArcMap or ArcCatalog.

On the PC we then symbolize stations with spots of color that correspond to their geologic map unit. With map units thus color-coded at stations, with field-observed contacts as guides, and perhaps with other resources such as topography and aerial photography at hand, the geologist then digitizes more extensive linework (contacts and faults) and ultimately closes these lines to create unit polygons in the compilation database.

Customizing GDA

Some customization (symbolization, map projection, picklists) of GDA is easy, and necessary for GDA to be useful. Specification of symbolization, definition of map projection, and optimization of base materials are best accomplished in ArcGIS, then exported using the ArcPad Tools for ArcGIS extensions that ESRI supplies with ArcPad. Most picklists are easily modified and extended by editing the associated DBF files. Some picklists are defined in the .apl (layer-definition) file for a particular layer (Table 1). These files can be modified with any text editor (e.g., WordPad). Thoms and Haugerud (in preparation) provide instructions. Other customization (e.g., modifications to database structure and forms) requires a skilled programmer, probably working with ArcPad Application Builder.

SOME DESIGN CHOICES

The process of geologic mapping, the opportunities and constraints associated with explicit use of a structured database for storing geographic knowledge, and the capabilities of ArcPad conflict at certain points. While designing GDA we had to navigate these conflicts and make some compromises. We focus here on five design choices that are key to making GDA work.

Field notes, not a geologic map constructed in the field

When we began working with ArcPad, we assumed that because we were taking a GIS into the field we could treat fieldwork as a direct extension of building the compilation database in ArcInfo or ArcGIS (Black and Walker, 2001; Brimhall and Vanegas, 2001; Brimhall and others, 2002; van de Poll and Parsons, 2003; Geopad, http://geopad.org). This didn’t work for us. First, ArcPad doesn’t have the GIS functionality needed to build a completed units-contacts-faults layer for a geologic map. (Note that these cited efforts are laptop-based.) Second, we found that we soon had two versions of the same map database, one on the PDA and one on the PC, and no straightforward protocol for incorporating one into the other. Data remained on the PDA in volatile main memory–one day the battery on the PDA failed, and several days’ work was lost.

Thus, we learned that we needed to distinguish clearly between field data collected via PDA and the compilation database. Rather, field data stand alone as one or more separate databases that underlie the compilation database. This is consistent with traditional mapping practice. As Pavlis and Little (2001) suggest, “a standard map compilation step. . .may be a preferred method to insure map accuracy.”

While our decision to not construct a geologic map in the field primarily reflects our innate conservatism and the limitations of ArcPad, it is also a step towards clarifying the distinction between observation (field data) and inference (completed geologic map database)—a distinction that geologists don’t always make. (Note, however, that as in most other sciences, most of our so-called observations are actually sophisticated abstractions or inferences.)

A partly-normalized database: Locations in one layer (almost)

A database that is “normalized”—stores each elemental fact (observation, inference, etc.) once and only once—is easier to update and less prone to accumulate errors than an “unnormalized” one. For example, if locations are stored both with the list of samples collected and with the list of map-unit observations, and a location is later corrected, it must be corrected in both the sample list and the map-unit observation list for the database to remain error-free. This can be difficult to achieve. Ideally, locations would be recorded once in a single file (i.e., shapefile) and then referenced as needed. For example, a single location might have multiple lithologies, map units, and samples; thus lithology, map unit, and sample information would be stored in related tables.

ArcPad does not enforce the relations between tables that would be required in such a database. Furthermore, ArcPad cannot symbolize observations (such as map unit) that are not stored directly in a shapefile. Thus we compromise, and store location, map unit, some outcrop information, lithology, and Station ID in the Stations (location) layer. We rationalize this practice by noting that a geologic mapper should observe and record geologic map unit at every possible occasion. Furthermore, if stations have infinitesimal extent there can be only one lithology and one map unit at each station. Multiple map units and lithologies correspond to multiple, closely spaced stations—which while not practical on an analog map, are easily accommodated in a digital map database.

Data about samples and photographs are recorded in separate tables without location information. Station ID is used as a key to relate sample and photo data to the Station layer. GDA includes code to explicitly enforce one-to-many relations between records in the Station layer and the records in these tables. We have not provided tables for other occasionally-repeated observations, such as property ownership and access.

GDA supports freeform text notes by opening, as requested, a text file named with the Station ID. Multiple notes can be appended to such files; associated with each note are the date and time at which it was initiated. Similarly, a sketch file can be created for any station. All related files are stored in the same folder as the associated shapefiles.

Because it is important to symbolize structural observations on the fly, and because ArcPad cannot symbolize observations that are not part of a shapefile, we repeat locations that correspond to structural observations in a second, Structure, shapefile. There are no locations in the Structure shapefile that are not also in the Stations shapefile, thus the Structure shapefile can later (within a more powerful GIS) be reduced to a location-less table related, by station ID, to the Stations shapefile. Our data structure for observations at a point is depicted in Figure 3.

Figure 3. Data model of GDA entities associated with the Stations shapefile.

Pick-lists: Project-specific vocabularies

The appropriate data structure to be used for description of geologic features and the vocabulary used to populate this data structure are controversial. There are great benefits to be gained from a universal data structure populated from a closed (controlled) vocabulary. On the other hand, there is no agreement on what this data structure and vocabulary should be: after years of discussion to resolve such inconsistencies, the geologic community does not agree on definitions for the common terms mylonite and Holocene. Precise geologic communication still requires explicit definition of terms, usually by incorporation of external definitions (e.g., “This report uses the GSA time scale and Streckeisen’s nomenclature for igneous rocks.”). The “standard terminology” problem is most acute for lithology and map-unit attributes.

The geologic community has expended much effort on standardized map-unit vocabularies (e.g., USGS, undated; British Geological Survey, undated) and there is a strong argument to be made for incorporating appropriate subsets of these vocabularies into a digital geologic mapping tool. On the other hand, much geologic mapping is essentially stratigraphic research aimed at modifying and extending these vocabularies. It would be unfortunate to hobble this research with closed, or difficult-to-extend, vocabularies.

Working with pencil, notebook, and field sheet, we record extensive outcrop-level descriptions of lithologies and map units mostly during the early stages of a project when we are learning or creating the local stratigraphic vocabulary. We discover which lithologic attributes distinguish map units. For mapping in one area, we learn that shale-sand ratio, syndepositional deformation, and sheen (corresponding to the grain size and degree of segregation of microscopic metamorphic phyllosilicate grains) are important discriminators. In another area we find it useful to concentrate on observing the presence or absence of visible titanite and the extent of post-crystallization deformation of biotite. In another project, we note whether sandstones are cross-bedded and zeolitic or plane-bedded and altered to low greenschist facies. Project-specific shorthand vocabularies for lithology and map unit eventually emerge.

Explicit recording of such attributes in a form-driven database would require the development, in the early stages of each mapping project, of a project-specific Station-layer DBF that included the relevant attributes and new forms and picklists to populate the DBF. Alternately, one could create a Station-layer DBF, forms, and picklists that encompass the universe of all possible attributes, but the vast majority of these attributes would remain unspecified at most stations and the system would be impossibly unwieldy. A universal Station-layer DBF with lithologic attributes restricted to manageable dimensions (e.g., a few dozen rock types, dominant grain size, and color) would make it impossible to document important distinctions between map units in many areas.

We found it useful to mimic our paper-based protocol in GDA. Extensive descriptions are recorded in free-format text files. Database fields are used for a few simple shorthand attributes, including map unit and lithology, which are populated from picklists with open, project-specific vocabularies. For simplicity and flexibility we sacrifice the benefits of discipline-wide controlled vocabularies.

Multiple projects, multiple directories. Archive to subdirectories

A GDA project can be defined as data with a particular extent, map projection, symbolization rules, and set of vocabularies. We have adopted the convention that each GDA project resides in its own working directory. Each project directory contains an ArcPad map definition file that defines the current layers and extent of the project; current GDA shapefiles; an optional GPS tracklog shapefile that records traverse routes, generated by ArcPad; DBF files for samples, photos, and picklists; and optional per-station files of extended notes and sketches. Also present are subdirectories for base data, earlier geologic mapping which is used as a backdrop for the current project, and blank GDA template layers. Data for a project are archived by moving data shapefiles, the tracklog shapefile, sample and photo DBFs, and copies of the current picklist DBFs to a new archive subdirectory on the PDA. These archive subdirectories are later copied to the PC for incorporation into the project compilation database. This convention allows us to maintain multiple projects on a single PDA, each with its own map projection (e.g., State Plane for one project, UTM for another) and its own lithologic and stratigraphic vocabularies.

Unique, independently-calculated Station IDs

Initially we used record number in the Station layer as the Station ID. It quickly became apparent that merging multiple record sets (from multiple workers, or multiple sets of field data from one worker) would require complicated and error-prone updating of the Station IDs in the Stations layer and in all the related tables in order to keep Station IDs unique. It is much simpler if, a priori, all Station IDs are unique, at least within the universe of a single mapping project.

We found it difficult, within ArcPad, to maintain a continuously incrementing station number across multiple projects and multiple archive events. Therefore, GDA uses Station IDs of the form IIYYMMDDHHNN, where II are the initials of the geologist making the observation, YY are the last two digits of the year, MM is the month of the year (01–12), DD is the day of the month (01–31), HH is the (24-hour time) hour (00–24), and NN is the minute (00–60). Advantages of this convention are:

• Station IDs can be calculated independently and simultaneously by several different workers and remain unique. The last (or next) Station ID need not be carried from one ArcPad session to another,
• Station IDs encode the time and date at which the location was established, and
• Station IDs can be sorted alphanumerically and their chronologic sequence recovered.

Multiple stations created within a single minute, such as offsets generated by a laser rangefinder, could be distinguished by appending additional characters (seconds, tenths of seconds). An alphanumeric sort would still recover station sequence. GDA uses a field length for Station ID that is longer than presently needed, to allow for this expansion.

SUMMARY

GDA uses the capabilities of ArcPad to turn a lightweight, low-cost PDA into an effective field tool for collecting geologic mapping data in digital form. Implementation of the GDA interface required comprises between desirable database structures, the ideal user interface, and the capabilities of ArcPad. In making these compromises we were in large part guided by previous experience with pencil-and-paper mapping.

We expect that many geologists will find GDA sufficiently complete and flexible to be useful in its present form. We hope that others will build upon our effort and experience to create even better mapping tools.

ACKNOWLEDGMENTS

We thank Ray Wells for continued support of our efforts and encouragement to collaborate. Jordan Hastings and David Soller provided very useful reviews of this manuscript.

REFERENCES CITED

Black, R., and Walker, J.D., 2001, Development and use of a laptop-based geological mapping system: experiences at the University of Kansas, in Soller, D.R., editor, Digital Mapping Techniques ’01—Workshop Proceedings: U.S. Geological Survey Open-File Report 01-223, p. 127-131, accessed at http://pubs.usgs.gov/of/of01-223/black.html.

Brimhall, G.H., and Vanegas, A., 2001, Removing science workflow barriers to adoption of digital geological mapping by using the GeoMapper Universal program and visual user interface, in Soller, D.R., editor, Digital Mapping Techniques ’01—Workshop Proceedings: U.S. Geological Survey Open-File Report 01-223, p. 103-114, accessed at http://pubs.usgs.gov/of/of01-223/brimhall.html.

Brimhall, G.H., Vanegas, A., and Lerch, D., 2002, GeoMapper Program for Paperless Field Mapping With Seamless Map Production in ESRI ArcMap and GeoLogger for Drill-Hole Data Capture: Applications in Geology, Astronomy, Environmental Remediation, and Raised-Relief Models, in Soller, D.R., editor, Digital Mapping Techniques ’02—Workshop Proceedings: U.S. Geological Survey Open-File Report 02-370, p. 141-152, accessed at http://pubs.usgs.gov/of/2002/of02-370/brimhall.html.

British Geologic Survey, undated, The British Geological Survey Lexicon of Named Rock Units, http://www.bgs.ac.uk/lexicon/lexicon.html, accessed 9 February 2005.

Brodaric, B., 1997, Field data capture and manipulation using GSC Fieldlog v3.0, in Soller, D.R., editor, Digital Mapping Techniques ’97—Workshop Proceedings: U.S. Geological Survey Open-File Report 97-269, p. 77-81, accessed at http://pubs.usgs.gov/of/1997/of97-269/brodaric.html.

Edmondo, G.P., 2002, Digital geologic field mapping using ArcPad, in Soller, D.R., editor, Digital Mapping Techniques ’02—Workshop Proceedings: U.S. Geological Survey Open-File Report 02-370, p. 129-134, accessed at http://pubs.usgs.gov/of/2002/of02-370/edmondo.html.

Pavlis, T.L., and Little, J., 2001, Using handheld personal computers as field data collection tools: some lessons learned in the school of hard knocks in the Wingate Wash Project and related projects using Fieldlog/Fieldworker software exported into ArcInfo, in Soller, D.R., editor, Digital Mapping Techniques ’01—Workshop Proceedings: U.S. Geological Survey Open-File Report 01-223, p. 115-121, accessed at http://pubs.usgs.gov/of/of01-223/pavlis.html.

Soller, D.R., 2001, editor, Digital Mapping Techniques ‘01—Workshop Proceedings: U.S. Geological Survey Open-File Report 01-223, 248 p., accessed at http://pubs.usgs.gov/of/2001/of01-223.

St. Laurent, S., 2001, XML: A Primer: M&T Books, New York, 560 p.

Thoms, E.E., and Haugerud, R.A., in preparation, GDA (Geologist’s Digital Assistant), an ArcPad extension for geologic mapping: Code, prerequisites, and operating instructions: U.S. Geological Survey Open-File Report. USGS, undated, National Geologic Map Database Geologic Names Lexicon “GEOLEX”, http://ngmdb.usgs.giv/Geolex/geolex_home.html, accessed 9 February 2005.

van de Poll, H.W., and Parsons, C., 2003, From CARIS GEMM 4 to Carta for Geology software: Our responses to geology education challenges in the age of digital mapping, in Soller, D.R., editor, Digital Mapping Techniques ’03—Workshop Proceedings: U.S. Geological Survey Open-File Report 03-471, p. 47-55, accessed at http://pubs.usgs.gov/of/2003/of03-471/vandepoll/index.html.

Walsh, G.J., Reddy, J.E., and Armstrong, T.R., 1999, Geologic mapping and collection of geologic structure data with a GPS receiver and a personal digital assistance (PDA) computer, in Soller, D.R., editor, Digital Mapping Techniques ’99—Workshop Proceedings: U.S. Geological Survey Open-File Report 99-386, p. 127-131, http://pubs.usgs.gov/of/of99-386/walsh.html.

Williams, V., 1997, Using the GSMCAD program with GPS for data collection in the field and as a quick and efficient way of creating Arc/Info geologic map coverages, in Soller, D.R., editor, Digital Mapping Techniques ’97—Workshop Proceedings: U.S. Geological Survey Open-File Report 97-269, p. 83-87, accessed at http://pubs.usgs.gov/of/of97-269/williams.html.