Computer-based data acquisition and visualization systems in field geology: Results from 12 years of experimentation and future potential Open Access

Until recently, the tools of the field geologist have seen little change since the nineteenth century: a hammer, a hand lens, and a geologic compass with inclinometer. We have now entered a new era in technology where rugged, lightweight field computers, geographic information system (GIS) software, global positioning system (GPS) receivers, digital cameras, recording compass inclinometers, compass-inclinometer devices that log data and position, and laser rangefinders allow us to do things that were impossible only a decade ago. This technology allows new approaches to obtaining, organizing, and distributing data in all field sciences. This technology will undoubtedly lead to major new advances in field geology, and hopefully revitalize this foundation of the geosciences.

In this paper we explore this issue of changing field technology based on 12 yr of experience, during which we have progressed from using computerized field notebooks to using a variety of field GIS systems for research and teaching applications. We describe the present state of field mapping technology from our experience, and discuss the advantages and disadvantages of different approaches and technologies. Key to this discussion is a philosophical difference in attitudes toward how data are collected and organized. Finally, we provide some thoughts on how we might proceed in the future.

One important lesson we have learned is that no single system is perfect for all applications, and the worst systems are ones that seem logical in the laboratory but are totally impractical in a field situation, or vice versa. We discuss how these technologies can be applied to metamorphic geology as well as economic geology, and describe how further development of these technologies will be crucial to future planetary geology expeditions. We then consider the similarly revolutionary impact the technology can have on teaching field geology.

Until the mid-1990s, computer systems were not practical in the field for any application other than simple data logging or for support of geophysical surveys, the latter typically associated with substantial logistical support (Table 1). The problems with early portable computer systems were fourfold.

1. Power. The battery life of laptops of the time was far too short for a full day in the field without large packs of spare batteries. Moreover, the lead-acid and nickel-cadmium batteries in common use at the time were heavy, bulky, and slow to recharge.

2. Portability. Computers were too heavy and bulky to carry the large distances geologists travel on foot. Furthermore, the hardware was fragile and not impact, water, and dust resistant as is common with modern, ruggedized field computers.

3. Displays. All of the early liquid crystal displays (LCD) became unreadable in bright sunlight.

4. Processing and communication. Processing power for early portable computers was insufficient to run even the modest GIS software that was available. In addition, wireless communication and GPS positioning technologies were not widely available.

With the introduction of the first handheld computers in the early 1990s, many of these issues were overcome with a device of manageable size and heft, a long battery life, and a satisfactory (initially monochrome), outdoor-readable display. That development led many to consider using these devices by the mid-1990s (Table 2).

With the present generation of devices and software, computerized field mapping is straightforward and routine. A critical development has also been the commoditization of GPS positioning devices, which now allow spatial precision not possible as recently as the early 1990s. Other recent developments (Table 2) like automated compass and/or inclinometers, increasing availability of light detection and ranging (LIDAR) data sets, and high-resolution satellite imagery suggest this is only the beginning.

In the mid-1990s, two of us (Pavlis and Serpa) began experimenting with systems that combined handhelds for field data acquisition and standard laptops (including early pen tablets) for data compilation (Table 2). This early system used Fieldlog software developed at the Geological Survey of Canada along with a commercial software package, Fieldworker, for the Apple Newton handheld (Brodaric, 2004; Brodaric et al., 2004). This system emphasized a point-based GIS approach where the handhelds and Fieldworker were used for recording point-based observations, and the graphical tasks of mapping were typically done on paper and later digitized using the Fieldlog application. Fieldlog was essentially a series of applets running under a computer-aided design (CAD) program for database and graphics management. The advantage of the system was that the software was designed with a simple interface for field applications and was intended to insulate the user from the complications of a full-blown GIS system (e.g., see Brodaric, 2004; Pavlis and Little, 2001).

During the late 1990s we experimented with Fieldlog during two research projects, one in Death Valley (e.g., see Guest et al., 2003; Golding-Luckow et al., 2005) and the other in southern Alaska (e.g., Bruhn et al., 2004; Pavlis et al., 2004). The dusty, hot dry weather of Death Valley and the cloudy, cold, rainy weather in southern Alaska provided a range of conditions in which to test the survivability of the hardware. Because of large power needs of this hardware and the remote wilderness areas in which we were operating, painful power availability issues, which we continue to face today, became apparent. It is interesting that in these field projects we never used ruggedized devices, yet over the course of three field seasons on both projects we experienced only one device failure, amounting to only a one-day data loss.

By the late 1990s, a software package called Penmap (www.Penmap.com) became available. We attempted to use this software as well as a later customized geologic graphical user interface (GUI) called Geomapper (Brimhall and Vanegas, 2001; Brimhall et al., 2002, 2006). We also experimented with using Fieldlog on newly available pen tablets in the field. Although they both seemed to be ideal tools, we ultimately rejected both Fieldlog and Penmap largely because of the limitations of pen tablet systems, including (e.g., Pavlis, 1999; Pavlis and Little, 2001) their high cost and excessive weight, and the continued lack of outdoor-readable displays. These problems remain to this day. In addition, Penmap was a relatively “buggy” piece of software and the Geomapper GUI emphasized a polygon input system that was inconsistent with the approach we had developed independently (see following discussion).

From our perspective, an important advance for field data acquisition came in 2000 when ESRI (formerly Environmental Systems Research Institute, Inc.) released the first version of the mobile GIS package, ArcPad. Together with ArcGIS, this software system combined a simplified software interface for field-based data acquisition with a sophisticated GIS for data manipulation in the laboratory or camp. With the release of ArcPad it was also possible to assemble an affordable system for instruction, and as a result, we and others began to experiment with teaching using handheld devices (e.g., Clegg et al., 2006). At the time of this writing we have collectively used variations of this system teaching field geology classes at the University of New Orleans, Massachusetts Institute of Technology, and University of Texas at El Paso (UTEP) with groups ranging between 7 and 15 students. We have also used the system in day-long field exercises as part of several other classes in groups as large as 22 students. Most important, however, we have continued to use the technology in our field research activities in dozens of field-based projects, and paperless field work is now the norm, not the exception. We have so thoroughly adapted to the system that we now tend to get frustrated with paper mapping as highly inefficient with very limiting capabilities.

Collectively, our experience is broad enough that we believe we have probably made most of the likely mistakes one can make in using these systems, and we have developed a practical approach that is exportable to virtually any academic institution. Some key lessons that we have learned from our experimentation include the following.

1. The technology has advanced rapidly in the past 5 yr, and even since Clegg et al. (2006) evaluated these systems. Thus, if someone was introduced to early versions of the technology and found it lacking, we suggest people take a new look at the systems.

2. There are still important, unresolved issues, particularly software limitations, and anyone interested in this technology needs to recognize the time commitments required (see discussion following).

3. Our approach is just one of several, parallel approaches to using this technology that have been undertaken. Specifically, most of our experience has been in an academic context and we have emphasized systems that are sustainable without a large financial commitment.

We use a system that employs Windows Mobile handheld devices running ArcPad and Windows XP tablet personal computers (PCs) with ArcPad and ArcGIS for use as both field tools and office and/or camp tools (Fig. 1). We also use ArcGIS and ArcPad Studio (also called ArcPad Application builder) software on the tablet PCs to create and export GIS project files to the handheld units. We rarely use ArcGIS directly as a field-mapping tool, preferring to use it to edit maps in camp or at the office, and generally use ArcPad as the primary field tool. This approach is similar to Geopad (http://geopad.org/) and projects described by Clegg et al. (2006), but our effort is an independently developed system emphasizing handhelds over pen tablets.

For research applications, most of us have also chosen the handheld over a tablet PC. The main reason for this is convenience. Compared to tablet PCs, small, lightweight handhelds are much more portable. In addition, because we used handhelds from the beginning of our experimentation for field applications and in teaching, we have become comfortable with using them for research. In the future, this may change (Table 1) as tablet computers become smaller and cost less (e.g. ultramobile PC's, netbooks, and the iPad tablet), and smartphones replace PDA (personal digital assistant) type handhelds. In many respects the new small tablet devices are an ideal compromise because they are lightweight (<1.5 kg) and small enough to carry easily, yet their screens are large enough (7–15 cm) to display more information than a handheld. In addition, the processing power and storage of these devices is now sufficient enough that higher end visualization software can run on these machines, and companies like Midland Valley are porting a version of their Move software for field applications because of these developments (see www.Midlandvalley.com). Conversely, the transition from PDAs to smartphones is a negative development because of the smaller screen size of most smart phones and the popularity of stylus free touch screens on many of these devices.

For software, we have become firm believers in not using a fully featured GIS program like ArcGIS as a field tool. Although ArcGIS is very versatile, its versatility can be a curse in the field because features like cascading menus, right-click requirements, and complex options can produce confusion for anyone but experienced users of the software. Customized interfaces like that employed in the Geopad project (http://geopad.org/) and that of Walker and Black (2000) and Black and Walker (2001) can improve ArcGIS as a field tool, but in our opinion, the program generally is too user hostile for the field environment. From our perspective, ArcPad represents a better field tool because it can be easily customized for the field environment, minimizing the potential for an inexperienced user to become overwhelmed by the software. However, ArcPad is still flexible enough that it can be adapted in real time in the field. Moreover, while most people can learn the basics of ArcPad in a single 2–3 h training session, few new users would feel even marginally comfortable with ArcGIS in that time frame. Nevertheless, it is important to realize that with ArcPad it is essential that at least one person in a field party has the technical ability to build a project in ArcGIS and ArcPad Studio, to export the project to the handhelds, and to debug occasional software and hardware problems. However, this is generally significantly easier to achieve than assembling an entire field party that is familiar with ArcGIS.

An alternative software product, Map IT (http://www.uniurb.it/ISDA/MAPIT/) was developed in Europe, and Clegg et al. (2006) evaluated its utility for various applications compared to using ArcPad of ca. 2005 vintage. We have not experimented with the software, in large part because it requires use of a tablet PC, but the program has been used in the Geopad project (http://geopad.org/). From descriptions, it appears to be a better choice for geologic mapping applications than ArcGIS, because like ArcPad, it has a simplified GIS front end. Clegg et al. (2006) considered Map IT superior to ArcPad, and although we consider some of the same issues here, their comparison is already somewhat outdated in the latest versions of ArcPad.

An important characteristic of any GIS is that data (attributes or linked information) can be attached to features or groups of features on a map. The ability to attach information to map objects gives the user the ability to change the display based on attributes, overlay transparent layers, or even visualize the data in three dimensions (3D), all of which represents a huge advance in our ability to solve field problems. Although these features are the real strength of GIS, geologists often treat GIS as simply a method for drawing maps. To this day, most digital geologic map releases do not take advantage of the true power of GIS because they typically use minimal attributing. This is particularly true of most regional maps digitized from older paper maps where little, if any, useful information is attached to the map that was not available on the paper map. A very different type of map can be built, however, when the data are collected in digital form in the field with attributing capabilities of GIS in mind.

The field GIS approach introduces a wide variation in possible procedures for field work. Setting up a data structure that takes advantage of the GIS framework is nontrivial, and will require new field habits (e.g., Brodaric et al., 2004). The challenge to a field geologist is to take advantage of this capability while not getting bogged down in collecting too much data or ending up with an unworkable mass of poorly organized data (Asch, 2003, 2005).

Early experience with the Fieldlog system quickly taught us that a data structure set up for a laboratory environment is not necessarily workable in a field environment. Specifically, a data manager in the office might imagine a data collection scheme that includes a standardized set of data that can be rapidly sorted and analyzed in the office. Unfortunately, if that data scheme is too complex, even the most patient field person will quickly abandon it if each stop involves data entry into multiple pull-down menus with complex pick lists. Thus, all data schemes are ultimately a compromise between the critical data to be attached to map objects in the field and the other data that can be later entered in the laboratory, saving valuable field time. This last point is critical, and often misunderstood by geologists who have done little field work. Field time is extremely valuable, not only because of real monetary costs, but also because small increments of lost time can prolong a field project, or lead to poorer results because critical areas might not be visited. As a consequence, we believe the efficiency of the data scheme used in field data collection systems is critical to the success of field GIS mapping. In particular, three major issues are apparent.¹

1. Polygon objects should be avoided. This is because they are too dynamic to build in the field and may require constant reconstruction as mapping progresses. There are a few cases where this rule might be eased, e.g., in surficial mapping or bedrock mapping with scattered outcrops. Our experience, however, is that using polygon objects to build a map always leads to difficulties because of unforeseen topologies that invariably develop. Thus, we use labeling or even hand-coloring of printouts during field work and only build polygons as derivatives after the field work is completed.

2. Keep it simple stupid, or KISS, is an important rule for field GIS systems. Essentially, this means simplifying all field data entry to the minimum amount needed for the project. Our rule of thumb is that point objects (e.g., stations) should contain no more than 6–8 attribute fields for data entry, and most of these should not be fields that are required every time a data point is collected. Examples of high-priority attributes in a station file might be: station identification (ID), geologist, date, location method, and a note. For line objects an even stricter rule should be enforced; line objects should contain no more than 3–4 attributes. This rule for line objects arises because attributing can be distracting when drawing the linework on a map. For example, consider the process of drawing a contact that is intermittently exposed with several covered intervals. On paper, this can be performed with little thought. However, in GIS the simplest method for graphic approach is to assign a “quality” attribute field (see sample data), and when a new set of attributes must be entered for each new line segment, it can be frustrating. A second rule is that any pull-down menus with pick lists must contain no more than 6–10 options with no cascading (nested) pull-down menus. Finally, to overcome any limitations these guidelines impose, the simple inclusion of a “note” field, with adequate space for generic data entry not covered in the fixed data fields, often proves invaluable.

3. Set up the data structure to allow a natural workflow in the field. It is crucial to develop a compromise between display and data entry issues, display always trumping data entry. GIS systems allow data sorting by layers and by attributing data, i.e., assigning values to a data table. Data layers are a first-order attribute and represent one simple way to separate information, but excessive use of data layers can also be confusing. For most geologic operations we use four types of point objects and 4–10 line types as data layers (Fig. 2). The point objects are stations for noting observations, sample locations, structural measurements, and photographs. The line objects always include the four basic types of geologic contacts: depositional, unconformity, intrusive, and faults. In addition, other structural elements, e.g., foliation traces, thin dikes, and fold axial traces, can be added as layers when needed. These point and line elements are the natural building blocks of geologic mapping, and we typically include each type as a separate data layer, and each data layer is then attributed further (Fig. 2). A sample blank geodatabase and set of shape files using this data structure are included herein as an appendix.

For many studies virtually all field data are point observations. Even in areas of extensive outcrop, point-based observations are an important part of the field data set, and significant field time has traditionally been devoted to point-based observations. This is the traditional station approach, in which field notes are keyed to a specific map position. We have experimented more with point-based GIS than any other part of the data structure, and our philosophy is influenced strongly by the approach taken by Brodaric (2004). Nonetheless, formulating rules for this part of the data structure puzzle remains difficult. This arises in large part because of different styles among field workers; thus, it is difficult to establish a data structure that works well for everyone. The data structure shown in Figures 2 and 3 is developed primarily for bedrock mapping, but we believe the basic form of the data structure can be easily molded to other applications. Specifically, although we recognize the common use of four types of point data (station notes, photos, samples, and orientations), we typically combine the first three into a single station layer and store orientations in a separate layer so that they can be more easily plotted as strike and dip symbols (Fig. 3). From our experience, most of the other point data is archival information that is accessed later and is not useful as part of the field map display. During routine mapping we often make the station layer invisible, the computer mapping equivalent of using pinholes in paper maps with station numbers written on the back of the map.

Our typical “orientation” data object (Figs. 2 and 3;  Appendix 2) illustrates one of these principles. In this file we limit data entry to a single strike and dip with the option of including a trend and plunge measurement, and include an attribute field to record the type of orientation data being measured (e.g., bedding versus cleavage) and a note field to record any subsidiary information. The orientation data are then displayed directly on the map using layer definitions imported from ArcGIS. In areas of relatively simple structure with only sedimentary bedding, this layer also can serve as the primary data entry form, e.g., a quick record of orientation data to be plotted on the map with a short note on rock unit, or other information.

In more complex areas, however, this simple format may be insufficient. For example, in metamorphosed rocks, multiple orientation measurements might be made in a small area, and although these data are needed, plotting all these data on the map soon produces confusion. With the recent development of recording digital compass and/or inclinometers (http://www.gsinet.co.jp/english/geoclino/index.html), the volume of orientation data obtainable in these types of studies can rapidly grow to unmanageable size. In such cases, we choose which measurement to display using the orientation layer, and we relegate all the other data to either a separate data file that is later linked into the database, or to the station table. Alternatively, a Boolean “plot to map” field (Fig. 3) can be incorporated into the data structure in ArcGIS. Unfortunately, plotting in the present version of ArcPad is restricted to single attributes, and thus this type of more complex ArcGIS layer definition cannot be directly exported to ArcPad.

Other point-based data produce different challenges. Foremost among these is the traditional station, which can serve many purposes, depending on the field project and the individual (Brodaric, 2004). Most geologists are familiar with this type of data object from paper mapping, but input tends to be a freeform personal preference. What constitutes a station varies among individuals. For example, many field geologists number all stops as stations, while others may use a different code for sample locations versus notes versus orientation measurements versus photographs, whereas others may mix all four in various permutations. Thus, although we typically combine station notes, photo descriptions, and samples into one point file, this is largely a personal preference. One approach to this issue is the approach used by Brodaric (2004) in Fieldlog. A station object in this approach is the place-keeper for spatial position, but the data table for the object is largely composed of metadata, including, e.g., a station code, position, date, the person making the observation. Other data are then linked to this data layer by a common station code, which is written to all associated data tables. In many ways, this is the ideally flexible system and emphasizes the capability of modern database systems (Brodaric, 2004). This approach was used in both a successor to Fieldlog (Geofield) developed at the Yukon Geological Survey (Lipovsky et al., 2003) and applets developed for ArcPad 6 (Geologic Data Assistant, GDA) developed at the U.S. Geological Survey (Thoms and Haugerud, 2006). Nonetheless, Murphy's law (i.e., the adage, “anything that can go wrong will go wrong”) always applies to field projects, and we have become hesitant to use this approach because of a hidden potential for data loss. Specifically, because all other point data have their spatial reference linked to the station file, if that single file were to be corrupted there is a high potential for complete data loss. Routine backups minimize this issue, but when using this approach in both GDA and Geofield we had partial data losses that required hours of work to reconstruct.

Because of these issues, our recommendation is that station point objects should be set up with a specific project in mind, with at least one point object file aimed at the specifics of the project. Thus, for projects emphasizing sampling, there should be a specific sample file, and the other data can be relegated to one or two other objects. Similarly, for bedrock mapping, orientation information is often a focus of the work, and thus we typically separate that object in this type of work. Notes tagged to these files can also take different forms: text fields as a field in the attribute table; linked data files defined as attributes with the linked files representing text files, photos, sketches, hand-written notes; and separate data tables.

Most linework is given a primary attribute for outcrop quality (exposed, approximate, or concealed). We use that attribute as a primary display parameter in part because of a long tradition in geology. However, there is no particular reason that this exact approach be used other than tradition, and the field GIS can allow a more flexible approach. We have used an expanded list, containing exposed, exposed_projected, approx_float, approx_float_projected, and inferred, the “projected” implying a contact that is extended using aerial photography or sketching from a distance. We have experimented with a quantitative attribute for contact quality (e.g., <10 m, 30 m, inferred), but found that this procedure confused people familiar with the conventional map scheme.

Depending on the project being undertaken, a number of other attributes can be given to linework. For mapping in sedimentary rocks (e.g., Figs. 2 and 3) we have commonly used a “contact type” attribute. In an area with well-established stratigraphic units, this attribute can be used to define the standard contact, but for areas with poor stratigraphic control or thick units, we also include a “sedimentary_bedding_trace” attribute to identify the line as an intraformational bedding surface trace distinct from a traditional formational boundary (Fig. 4). For detailed sedimentary studies, sequence boundaries, flooding surfaces, and hierarchical bounding surfaces can also be added. The ability to zoom into a small area is particularly important for mapping smaller scale features, such as bounding surfaces, because until now, these surfaces typically have been traced only on outcrop photos. Alternatively, in volcanic rocks, or areas with volcanic rocks interbedded with sedimentary rocks, the contact type attribute can be used to distinguish volcanic versus sedimentary contacts. We always include a note attribute with a large data field where additional information can be added. This information is the type of narrative or descriptive material a geologist would traditionally write in their field notebook. It is interesting that having this recorded digitally as an attribute of a specific GIS object ultimately changes many people's note-taking habits. Specifically, the note field for an individual line element can be used to add information about the feature that could never be done with paper mapping. For example, notes like “this contact is speculative” or “this is accurate to ∼1 m through GPS positioning and high-resolution aerial photography,” are possible.

Working in metamorphic rocks leads to a somewhat different linework data structure (Fig. 5), where more complex attributing may be needed to allow a particular type of data display. Similar issues also arise in economic geology (Brimhall et al., 2006). For example, in complexly deformed metamorphic terranes, in addition to primary compositional layering, there is typically more than one structural fabric (e.g., S0, S1, S2) and surface traces of these features can be routinely mapped. It may also be desirable to map other structural elements (e.g., axial traces of multiple fold generations, linear fabric traces), and features such as metamorphic isograds or hydrothermal alteration zones. Because these field GIS systems allow us to simultaneously map and selectively display these multiple surfaces, it is in these environments where we have found the most profound improvement over traditional paper-based mapping.

Because there are so many lines (each potentially with several attributes) being drawn on a map, implementing a field GIS system for metamorphic and economic geology work strongly underscores the KISS rule. We have typically settled on a simplified data structure with a data layer for each linetype (e.g., S0, S1, S2), each with no more than two basic attributes (quality and note), and with no requirement that these attributes be set in the field. In practice, to speed field operations, we generally do not attach any attributes for foliation traces other than layering and we use notes or photographs to clarify the quality of the mapping. In this case, attributes can be added later, including linework groupings in an ArcGIS geodatabase, to clarify the nature of the information. For fold systems it is tempting to develop a complex data structure that would encompass the entire range of possible fold types, a strategy that in practice becomes unworkable. Thus, for folds we use only one layer for fold axial traces, typically limiting the fields to an attribute for graphical display. In our sample data file, for example, we use only a fold form attribute, and other data (including fold generation, orientations) are entered in a long note field. An alternative data structure is to use both a form and generation attribute, but the assignment of folds to generations routinely can cause confusion if this approach is used in a new field area where generation assignments may be in flux for days.

An important element in GIS-based field studies is compilation at the end of the day, which includes both routine backups and data entry and/or repair. The procedure can be as simple as downloading a digital camera, changing file names, and linking the photos to the database. However, more complex procedures can be developed, including revision of linework using aerial photography, digital elevation model (DEM) shaded reliefs, or both, as well as editing attribute tables. These editing operations are all GIS-related functions that can be done outside the field environment, and the extent of this exercise depends on the project, the personnel in a project, and the preferred procedures for the group. This editorial step, however, is critical, and is the digital equivalent of “inking of lines” or daily map compilations. Conceptually, this step can be very important for both students and a researcher as a reflection on the day's work, is crucial in planning for the next day, and can be a critical metacognitive step in field problem solving (e.g., http://serc.carleton.edu/NAGTWorkshops/metacognition/index.html).

In our experience, it is important to evaluate the field project at hand, the field personnel, and the project's specific needs, in determining how much effort is spent on daily data compilations and/or editing versus field data entry versus post–field work data compilation and/or editing. If a field project is working in a remote site, evening field time may be limited, and thus, required evening data compilation and/or editing should be minimized. Alternatively, if a project has extensive logistical support (office and/or room for evening work with no power limitations), field efforts can be maximized by delaying many steps to evening data compilation.

Similarly, there are hybrid field procedures that may be appropriate, depending on individual preferences. For example, we have found many people prefer to use a traditional paper notebook in the field for developing sketches and notes, minimizing data entry in the field. For teaching applications this may be a preferred technique to encourage good note taking. However, when this type of hybrid approach is used, it magnifies the need for evening data compilations; either forcing evening data entry or at least correlation of notebook entries to the digital data files.

Field geology projects are often undertaken in remote areas where electrical power is limited (or nonexistent) and where environmental conditions can take a harsh toll on electronics. Both of these issues are closely related.

Since most hardware has, at most, three days of useful battery life, a field party needs to develop a plan for keeping equipment operational that includes redundancies in the event of equipment failures. In group exercises for geology field classes, this may require something as elaborate as a generator, and multiple power outlets for charging devices. For smaller groups or applications in extremely remote areas, the best power solution we have found is solar-powered, portable 12 V charging systems. Careful consideration, however, must be placed to balance space and/or weight limitations with power needs. This is problematic since first-time users are unfamiliar with how to budget the wattage per day required, the critical criterion for selecting the size solar panel required. Similarly, most car batteries are a poor choice for a solar charging system because they are generally prohibited in aviation cargo, cannot tolerate deep-cycling, and they typically have a much larger capacity than needed. From our experience, a field party of 2–4 can be maintained with a sealed 10–15Ahr battery charged with a 20–40 W solar panel. A critical piece of electronics that is often overlooked in constructing a solar charging system is a voltage regulator to avoid destroying a battery by overcharging, a device readily obtained from businesses that sell solar power equipment.

The physical environment (e.g., weather, altitude, wildlife) requires logistical planning similar to that required for geophysical field experiments. Weather issues, for example, affect the kind of power system that is most practical for a project. For example, preventing short circuits in a wet environment is a fundamentally different challenge than working in a desert where dust and sand might clog terminals and cooling fans. Equally important is that someone in the field party takes the responsibility of technical expert. That person must be knowledgeable enough to maintain all equipment in working order.  Appendix 3 gives a simple checklist of useful spare equipment, tools, and suggestions for troubleshooting.

As a final logistical note, geologists should not proceed to a remote location until they have spent several days of actual mapping in an area where they have access to high-tech support—software, hardware, or both. The list of potential problems is long when users are unfamiliar with the system. Thus, new users need to gain experience with the equipment in an area where there are no time pressures and high-tech resources are available, not in a remote site with limited or no communication.

Field geologists have a poor record of developing collaborative field efforts, a tradition that goes back to Roderick Murchison and Adam Sedgwick's well-known feud in the nineteenth century. This problem arises from the basic nature of traditional field work. First, geologic maps are a derivative of a series of point observations, each of which can be subject to random chance and subjective interpretation (e.g., Ernst, 2006). As a result, a geologic map becomes “fuzzy data” wherein facts are mixed with interpretation. Second, collecting basic field data is laborious and, in some cases, dangerous. As a result, the intellectual property encapsulated by a geologic map has a very high value to the producer of the map, yet to the broader community the information is merely a part of a broader collection of knowledge.

We suggest that if all field geologists began to use the type of GIS system described here and elsewhere (e.g., Clegg et al., 2006; Brimhall et al., 2006), the community would ultimately develop a different attitude about field data. The “fuzzy data” issue can be entirely eliminated because in a GIS there can be an explicit segregation between objective, quantitative data collection and subjective data interpretation. The basic data used to develop a map, such as field descriptions, photographs, and orientation data, can always be extracted from the database. Furthermore, if the basic field data are always collected in digital form within a GIS, the data are inherently archival, and ultimately can be easily shared with the broader community. This database would also allow other workers to directly examine the basic observations that support the geologic interpretations on the map. This is a remarkable advance in how field geology is done because it greatly facilitates the equivalent of reproducing an experiment in other branches of science.

How field data are archived is beyond the scope of this paper, but we believe that it is imperative that this problem is addressed in the near future. Clearly there is a time window during which field data should be the sole intellectual property of the scientist who produced it. After a project is completed and main results published, however, it is a waste for that information to disappear into a file drawer, which is the typical case today. Thus, it should become a routine procedure to archive basic geologic data as we move into digital mapping. The ease of data archival in a GIS format makes this a straightforward process, but the data structure of the archival information is not. The U.S. Geological Survey has developed one archival model (http://ngmdb.usgs.gov/Info/standards/NCGMP09/) that minimizes required attributes in the GIS but allows more extensive attributes in nonstandard fields. Although this “one size fits all” approach is an important step for regional map compilations in a large organization (Haugerud et al., 2009; Thoms et al., 2009), there are undoubtedly complications in detail as these systems evolve. It is important for the broad geoscience community to contribute to these evolving issues because although the standardization of data structure for data release is important, in field systems a standardized data structure may stifle creativity.

In using field GIS technology we have concluded that a number of long-held paradigms for field work need to be reexamined. This extends not only to the research environment but also to the way we teach field geology to undergraduates.

A paradigm of field geology has been that when you leave the field on a given day, all linework should be complete. This paradigm is so firmly entrenched that it is a mantra emphasized in virtually all field geology classes at the undergraduate level. We suggest that although it is still critical to impress on students the need to complete linework and descriptions in the field while the geology is in sight, overemphasis on this concept can be a handicap when using modern technology. Specifically, in the interest of increasing field efficiency, some field tasks are best accomplished as an iterative process of field observations, cleanup, and further field observations.

In conventional paper-based mapping, the mapping process began by referring to any previous geologic mapping, and these maps might or might not be carried into the field for appraisal. In the field, the typical procedure would be to map directly onto a topographic map, aided by aerial photography if available. In some cases, orthorectified aerial photographs (or satellite imagery) could be used with or without a topographic map overlay, but generally most geologists carry imagery as separate stereo pairs. The result of having so many disparate paper map products was the “field map shuffle”; i.e., constantly looking from old geologic map to topographic base map to aerial photographs, to the landscape in front of you, back to the topographic map, and so on. Although anyone who has done extensive field work becomes accustomed to this procedure, it is inherently inefficient. In contrast, the ability to stack multiple, georeferenced data sets on a computer screen, including options to make layers transparent, avoids the field map shuffle, and allows the fieldworker to concentrate on the task at hand: understanding the local geologic relationships. Moreover, when the data are acquired as first-generation digital maps, many compilation errors can be directly avoided (e.g., map compilation blunders and conflicts discussed by Campbell et al., 2005).

The availability of multiple, georeferenced data layers in a field GIS also leads to a different workflow. In particular, even before going to the field, data compilation from existing maps and photointerpretation of imagery can lead to a partially completed geologic map. Field work can then concentrate on specific problem areas, clarification of field relationships, and testing of hypotheses. In a very mature area, field work might be limited to refining details, but in less well known areas, the field work would require more extensive geologic mapping. In either case, however, the preliminary work saves and enhances the productivity of valuable field time.

The iterative nature of collecting and developing field data in a GIS is also different from paper mapping. Paper maps are always refined and modified (with pencil and an eraser) during field work, and many people compile the information nightly to a base map. In the computer mapping world, this last step, compilation, is a necessary and potentially major contributor to the efficiency of field work. At a minimum, the tedious work of daily backups of data and cataloging and renaming of data files (i.e., photos, orientation data files) is essential, but other steps at this stage can be very informative. For example, when good aerial photographs are available it is often more efficient to not worry about precise details like exact contact placements while in the field, particularly when time is an issue. Instead, roughing out the basic linework with some careful georeferencing of critical points may be all that is necessary, and in the evening the map can be cleaned up and refined, particularly projected contacts, using the aerial photography (Fig. 6). Depending on the quality of imagery and abilities of the field geologist, this procedure can usually be completed in less than an hour each evening.

This suggestion will undoubtedly appall many long-time field geology instructors, but if one has not used these systems it is difficult to appreciate how efficient this procedure can be. In recent undergraduate field geology classes at UTEP we were surprised by the dramatic improvement in the quality of student maps produced with this technique. The lead author had used this technique for some time in research environments, but the impact on a research setting is less obvious than that on students because the high skill level of research personnel primarily led to fine tuning of maps in the compilation stage. With the lower skill levels of students, however, the impact was dramatic because students quickly saw their errors on high-quality imagery when they had time to view their work without the multitasking pressures of the field day. We suspect that this improvement is due to students taking a more active role in planning and daily reflection on their work, an important metacognitive step in learning (e.g., see http://serc.carleton.edu/NAGTWorkshops/metacognition/index.html), and is consistent with Riggs et al. (2009) observations of student success when field planning was used by successful students in field classes. Nonetheless, the success of this method has not been universal, because one of our recent field classes performed poorly with this approach. In this case, the problem appears to have originated when students became accustomed to using aerial photography where rock units were clear on the photos, but when confronted with an area where photo interpretation was difficult, they experienced major problems. We do not have a clear solution to this problem, and it represents a geoscience education issue that needs to be addressed.

The process of data compilation and final map preparation is a critical step in field GIS mapping that, if ignored, can lead to less geologic insight than paper-based mapping. Although the old-fashioned processes of compilation, inking, and map coloring are tedious, for most of us, this process was an intellectually important step in data synthesis. It forces appraisal of map patterns and evaluation of accuracy, particularly when linked to analyses such as cross-section construction: that is, a metacognitive step similar to that described above. In a computer-based mapping system, the tedium of the compilation and final map preparation step can be largely eliminated. At the same time, however, the data synthesis function of this step can be retained and enhanced. Along with conventional cross-section construction, we have used two other procedures to aid this step: (1) topology building and editing, and (2) 3D visualization.

We noted here that we typically avoid polygons during geologic mapping, largely to avoid wasting field time on a process done more easily in the lab. However, there is also an intellectual advantage to delaying this step. In the GIS approach, this step represents the digital equivalent of coloring a map. Like coloring a map, this step forces map appraisal line by line through cleanup of map topology, and forces a close look at the map to aid visualization. The frequency of this step depends on personal choice. This step can be done nightly if a project is fully integrated into a GIS, or it can even be done continuously if ArcGIS is used as a field tool (e.g., Walker and Black, 2000; Black and Walker, 2001). However, it can also be delayed indefinitely, and if a group is not comfortable with GIS software, old-fashioned hand-coloring of printouts can serve the same purpose.

Finally, 3D visualization systems represent the ultimate future for field geology, but at the time of this writing there is no practical system that is useful for the field environment. In particular, true 3D displays are limited to the laboratory environment and the only 3D tools available for field work are pseudo-3D applications using perspective views; e.g., web-based systems like Google Earth, and viewers like iView3D and ArcScene. Similarly, although some software, like Move from Midland Valley Exploration software (http://www.mve.com/), allows true 3D digitizing, this software requires special licensing and is expensive for nonacademic units. Nonetheless, Midland Valley is developing this software for field applications and has significant promise. New software developments in the UK (e.g., Mathers et al., 2009) and experimentation in the U.S. (e.g., Phelps et al., 2009) offer a future for 3D mapping at a variety of scales, but remain an office tool. Thus, field geology must await future developments to fully integrate 3D into the field environment, particularly hardware such as heads-up displays, 3D displays for mobile devices, and augmented reality systems. Nonetheless, 3D visualization can be used as part of evening map compilation work, depending on the logistics of a field project. For example, we have used Google Earth to aid in data compilation in the evening with classes. In research settings we have used ArcScene and the commercial program Fledermaus (http://www.ivs3d.com) to drape shapefiles and published geologic maps onto a DEM, and used 3D viewing capabilities to help recognize mapping errors and clean up mapping (Fig. 7).

The structural geometry that can be produced by multiple generations of fold overprinting in metamorphic terranes represents one of the most difficult 3D visualization problems in all of geology. Traditionally one of the main methods for resolving geometry has been systematic mapping of the surfaces traces of different generations of structural fabrics (e.g., Hobbs et al., 1976, p. 347–375) together with symmetry analyses (stereographic projection) and cross-section construction. The field procedure is time consuming, and in conventional paper mapping often produces a map that is completely incomprehensible to anyone but the person who made the map. In contrast, field GIS provides the ability to superimpose multiple data layers, turn layers on and off, and zoom a field map through a nearly infinite scale range, all of which are mapping functions that are a remarkable improvement to anyone who has done this kind of mapping on paper. Furthermore, the recently developed digital recording compass inclinometer opens options never before considered. These devices can rapidly measure orientations of planes, or simultaneously measure the orientation of a plane and a line on the plane. We used one of these devices recently and obtained as many as 100 plane-line pairs in less than an hour. This suggests that unprecedented geometric resolution can now be done routinely. When combined with high-resolution GPS this could lead to a whole range of new capabilities in resolving complex geometries. As 3D visualization systems develop further, the capabilities of resolving complex structural geometry will only improve, and we predict a future revolution in our understanding of complex metamorphic structures as a result.

The combination of GPS with a field GIS also creates new opportunities in sedimentary geology. Sedimentary features are typically analyzed as 2D objects. Although the advent of sedimentary architectural studies and sequence stratigraphy has highlighted the 3D nature of sedimentary features, understanding of the 3D geometry is handicapped by limitations of both data collection methods and ability to visualize the systems. Today, many scientists are experimenting with ground-based LIDAR systems, laser rangefinder systems, high-precision GPS, or some combination of these technologies. However, these represent only a part of the tools needed to best resolve true 3D architecture. Mapping using a field GIS system allows for huge improvements in the development of true 3D reconstructions. Simple tracing of bedding planes becomes a 3D exercise that, in combination with a 3D imaging program, can revolutionize our understanding of sedimentary systems. Using these tools together with a GIS mapping system represents a powerful combination that is difficult to overemphasize.

Many of the lessons we learn from terrestrial work with field computing systems can have a direct bearing on how these systems could, and should, be developed for field science on the moon, Mars, and beyond. These missions will present serious challenges that go far beyond the most hostile environments encountered by field geologists. Field GIS technology can greatly enable field exploration in hostile planetary environments where the geologist will be hampered by both terrain and the need to carry a life-support system that puts severe constraints on time and metabolic activity.

Properly implemented, a field computing system not unlike the one currently in use by us can streamline and simplify the information resources needed during an extravehicular activity (EVA), or spacewalk. This can include both the operational checklists required to safely perform the EVA as well as the data-gathering tasks, e.g., geologic mapping and sample collection, to be accomplished during the EVA. In addition to the added efficiency afforded, some tasks that would otherwise be unfeasible would be made possible. For example, during the Apollo missions, the astronauts did not have the capability to map geologic contacts and were limited to verbal descriptions of geologic relationships and the collection of samples. With a field GIS system coupled to a geolocation capability analogous to GPS, future astronauts could precisely map out the geometry of geologic relationships in the field by simply walking them out, or by digitizing them from distance with a laser rangefinder. Numerical data and descriptions (translated to text via speak recognition), in addition to digital photography, could be linked to the field GIS, just as easily as they can now with ArcPad. In addition, the field GIS system would allow the full use of available remotely sensed data as a base map for both scientific decision making and for navigation.

These enhanced capabilities will also encourage complete documentation and curation of field data and samples, crucial tasks for activities in locations that are expensive and difficult to reach. For example, when field data are collected in a GIS, (near) real-time transmission and remote analysis and/or archival of that GIS data are possible. This can allow the support staff on Earth to vicariously explore and better engage and/or direct the astronauts during any EVA and enable better planning between EVAs. This can also allow richer sharing of information among astronauts in the field, supplementing the voice communications with real-time data and further increasing efficiency in the field in terms of time, metabolic costs, and amount of ground covered.

Although we have described some issues related to teaching with field computer systems, a number of additional issues are important to emphasize. All students have different ways of learning, and in traditional field geology classes there is little room for alternative learning techniques. That is, there is no other way to collect data than to go to the field. During field classes there is a widespread “sink or swim” attitude that places many students from urban environments or with physical limitations at a great disadvantage. Using field computer systems allows a great deal more flexibility in data collection that can benefit these students in particular. Foremost among these capabilities is the potential of 3D visualization systems to permit virtual access to any place on Earth. Through these systems there is tremendous instructional potential for both students with no direct access to geologic features near home and for physically disadvantaged students. Anyone who has taught field geology is familiar with situations where a student either arrives or becomes physically incapable of conducting day-to-day field work, and using visualization is one way to deal with this issue.

Another teaching benefit we have found is the ability to encourage collaborative learning with the use of the field GIS systems. In a sense, field geology classes have long employed some form of collaborative learning in the use of field partners, although working in pairs primarily serves as a safety factor. Nonetheless, students working in the field in pairs or in groups have long lead to assessment nightmares because it is often unclear whose work ends up in the final result. Field GIS systems do not eliminate all of these problems, but do improve our ability to assess individual performance because students can be asked to present their raw data files at any time during a field project.

More important, however, using field GIS systems can encourage true cooperative projects and team-building exercises where students can gain familiarity with working in a group research environment. For example, many field classes have long emphasized a research approach to field problems and used groups of students to develop regional geologic maps where student groups were responsible for all steps from data production to data compilation. Although this approach is possible with a traditional paper mapping approach, it is far easier to implement with a field GIS system. With field GIS, student maps can more easily be merged to produce an aggregated data set that covers a large area. Students can discuss and revise the maps as they compile the data, and peer pressure can force improved performance when the group is relying on input from everyone in the group. Thus, use of computerized systems can encourage a research quality approach in field classes.

A second advantage of using these systems for teaching is the accelerated learning of several key field skills. One clear example we have seen is, by incorporating GPS positioning for station descriptions, students more quickly adapt to the field techniques of station description and orientation data collection without the classic question of “where am I?”: unfortunately, it is not clear that this step improves performance on other mapping skills, because the traditional “where am I” question also serves to improve map reading skills that are essential for things like projecting contacts. Moreover, we have recognized cases where some students experience significant problems with synthesis exercises, and we suspect the small screen size of handheld computers may be a culprit (e.g., see discussion by Clegg et al., 2006). In the future we plan to experiment with techniques to force continued data synthesis, but we are uncertain of the ideal approach. We suggest that field classes should experiment with different techniques that can aid accelerated learning of field techniques, but should recognize the variety of learning techniques among the students. We suspect that as 3D visualization becomes more widely available, the 3D visualization system, together with GPS, will make a powerful accelerated learning tool. Thus, we suggest that collectively these are important research issues for geoscience educators.

Our experiences with field GIS mapping systems indicate that they are a significant improvement over the traditional paper mapping techniques that have dominated geology for more than two centuries. In particular, instrumentation and techniques now exist to collect large amounts of data rapidly and with high precision in the field. More importantly, those data can be merged and viewed with a variety of other geospatial information, both in and out of the field setting. This makes the field mapping process much more efficient and increases the reliability and repeatability of collected data. The ability to combine data sets and create 3D visualizations of mapped structures increases the interpretive abilities of the mapper, both in and out of the field.

There are some trade-offs that arise when using computers in mapping. In particular, the user must know something about the software and hardware as well as implement new procedures to prevent the loss of data in the field. We have found, however, that we can teach undergraduates, even those with little computer background, the necessary skills in a short amount of time. We note, though, that in any field effort, one or more people must be relatively skilled at all aspects of the software and hardware to avoid catastrophic results. Becoming proficient in using these systems requires a different learning procedure than paper mapping. Everyone is familiar with paper and pencil since childhood, but not everyone is comfortable with using these high-tech devices. In teaching students the systems accelerate learning in some areas, but can produce obstacles in other areas. For experienced field workers the steep learning curve of adapting to the systems will initially seem an obstacle, but it is well worth the effort once you have learned the system.

The time has come to abandon paper-based mapping, and we hope that within a decade we will look back on geologic mapping using a Brunton compass and paper maps as a quaint artifact of the past, reminiscent of the plane table and alidade for mapping, the blow-pipe for mineral analysis, or other archaic technologies.

Hardware suitable for field situations depends heavily on the use planned for the systems, and for the physical environment of the field work. We recognize three key issues for selecting hardware: (1) ruggedization; (2) display; and (3) weight.

Although it is tempting to assume that all field work requires so-called ruggedized devices, from our experience these devices are generally a waste of money. In more than 10 yr of working with these devices we have physically broken only two devices and one of these was a rugged device, which, ironically, cost more to repair than a new nonrugged device. Electronics failure independent of accident, however, is more common; e.g., in our experience, ∼10% of handhelds undergo a hardware failure within 2 yr. Fortunately, the consequences of field hardware failures can be minimized by using interchangeable flash memory devices. That is, we keep all data files on secure digital (SD) or compact flash cards, which can be removed in the event of a hardware failure. Note, however, that these cards also fail periodically, and thus backup to other media is also critical to ensure data integrity. We have found that flash card failures can be minimized if files are completely rewritten daily to avoid repeated rewrite cycles on the same sector of the card. There are several methods to accomplish this, but the easiest method is to move each day's work into new folders, particularly if nightly edits are performed.

There remains a complete range of display types available for field devices, but currently the principal distinctions in usable outdoor displays is transmissive versus transflective displays. Conventional LCD displays on laptops use a transmissive display, and use a backlight to make the screen viewable. In an outdoor environment, a transmissive display can produce a reasonable display, but usually requires a very bright backlight, a situation that produces a trade-off between display quality and battery life since the display produces a large power drain. We have found these types of displays acceptable if the main work environment allows access to shade or the work is in cloudy areas. In direct sunlight, none of these types of displays produces a legible display.

In contrast, transflective displays work best in direct sunlight, and in the shade or on cloudy days, require use of a backlight for clear visibility. As the name implies, these displays have a reflective LCD panel and a subtle issue with these screens is the screen surface. Many devices come with a nonreflective coating, which improves display dramatically by minimizing glare, yet these devices often contain a dilemma; for practical field use, a screen protector is required to avoid destroying surface coatings with the pen interface, yet most screen protectors lack nonreflective coatings. There is currently no solution to this problem other than to avoid devices that rely heavily on screen coatings for glare suppression; although rare, some screen protectors have some glare suppression, although usually at the expense of visibility in transmitted light (low light conditions). Transflective displays are common on handheld devices, but these types of displays are very rare on tablet PCs or laptops. Our recommendation, from more than one bad experience, is never believe manufacturers advertisements of “outdoor display” without seeing the display in real outdoor conditions.

A commonly misunderstood issue with displays that is not apparent to most people until they have used a device is the trade-off between touch-sensitive screens versus electromagnetic (EM) digitizers. EM digitizers are standard on most tablet PCs and have an advantage in that the screen tracks the pen hovering over the tablet surface. This feature is extremely useful for certain drawing operations, because linework and mouse emulation operations are relatively intuitive to most people. Nonetheless, EM digitizers are expensive and are virtually unknown on handheld devices. Instead, these devices typically use a pressure-sensitive touch screen system. In touch screens, screen calibration is critical, as well as sensitivity. For example, there are few things more annoying than an excessively sensitive touch screen because something as simple as laying the palm of your hand on the screen can make the pen jump to your palm. Fortunately, most devices can be adjusted for these issues, and modern devices rarely have this problem. However, readers should use care with some touch screens now appearing on many smartphones, that are heat activated and will not work with a stylus; these devices are useless for field mapping applications where high precision is needed. Touch screens are also used on some windows PCs and these systems also have a hidden pitfall related to mouse clicks. With a pen interface, a single tap is typically used to simulate a mouse click and double tap a double click, but there is no equivalent to a right-click. EM digitizers typically contain a special button to accommodate this issue, but for touch screens this is usually dealt with by a special button on the device, a situation that can lead to awkward hand positions for some operations.

We indicated briefly that weight is a large factor for anyone carrying these devices while doing field work on foot. What constitutes an acceptable weight depends on the person, but we have generally found that any device >2 kg will generally get left behind by field workers. Similarly, form factor of the device is an issue, but depends greatly on the trade-off between screen size and portability. That is, it is doubtful many people would carry a 30 in (76 cm) tablet in the field, but a notebook-size tablet would be acceptable to many; others would prefer a device that could be carried in a vest or hip pouch.

In any case, the key issue for anyone is that it is very important to test any device planned for field operations. All devices ultimately require a compromise, and the ideal device for a given user will depend strongly on the applications and environments where the devices will be used. We generally prefer nonruggedized, smaller form-factor devices (UMPCs and handhelds) with transflective displays for field work, but others clearly prefer alternatives.

Although we are advocates of the ArcPad software system, there are several issues that need to be recognized by anyone undertaking using these systems. In this paper we include two sets of generic shapefiles: (1) a generic bedrock mapping project that assumes work predominantly in stratified rocks lacking significant ductile structure; and (2) a generic metamorphic structure mapping project where multiple generations of ductile structure are expected. This pair of projects is not meant to encompass the entire range of projects possible, but serves to represent how projects are organized and set up in the ESRI system. It also contains script files (ArcPad layer definition files, i.e., files with “.apl” extension) that show various examples of symbol plotting, line style variation based on attribute, and labeling. We recommend using these projects initially as a training exercise to get used to using the software, but after using the systems it is virtually certain that users will need to customize the projects to their needs. It is possible to develop a project entirely in ArcPad, but the function of the system will be limited. To fully customize the system, you will need two additional pieces of software: (1) ArcGIS (an Arcview license is sufficient) and (2) ArcPad Studio. We have wasted days of effort learning the range of software bugs and quirks in the software that are required to build a reasonable project. From that experience, we emphasize several key concepts here for people first attempting to build their own project. It is particularly important to follow a specific workflow in setting up or modifying an ArcPad project. In particular, the sequence of starting the project in ArcGIS and completing it in ArcPad Studio is critical; the reverse procedure (starting in ArcPad and ArcPad Studio) produces unpredictable outcomes. This workflow recommendation is not in any ESRI documentation that we have seen, and the ArcPad to ArcGIS sequence was not even anticipated by ESRI based on correspondences we had with the company during some of our work. Thus, we advise following this sequence.

1. Unless you are building your project entirely in ArcPad, begin building your project in ArcGIS. If you are building the project from scratch, you should first create a geodatabase and develop all of your line and point objects within a single feature class, and export the project from the geodatabase after the steps described below. Geotadabases and shapefiles are created in the ArcCatalog program. Usually, a personal geodatabase is the best option. New feature classes are created in the geodatabase, and given common projections. When creating a new feature class, be sure to check the Z-values box to record elevations. This will be critical if you plan to do any 3D work. Then the desired fields can be added. For an easier time, import the fields from the shapefiles provided with this report and modify or add to them.

Shapefiles are generally easier to use, however, because they are the native format for ArcPad. If you plan to use the shapefiles provided here as templates, take those files and begin by reprojecting them to the coordinate system you plan to use. ArcPad cannot project files on the fly, like ArcGIS, and so all files must be in the same coordinates. Thus, some initial planning can save time. Project builders must decide if it is easier to reproject all files into a universal reference frame like WGS84 (i.e., World Geodetic System), or is it easier to reproject later and work in an odd reference frame like NAD27 (i.e., North American Datum)? Map projection is an issue because geographic coordinates may be desirable, but produce serious map distortions at high latitude. A cautionary note: when reprojecting files, be careful with file names. ArcGIS defaults to a renaming of the files, but this is generally highly undesirable because of naming issues in the development of the ArcPad layer definition files (.apl files). Thus, it is best to put the reprojected files into a different folder and either rename back to the defaults during reprojection, or rename them in ArcCatalog after they have been reprojected. If you are not modifying the basic data structure or symbology of one of our generic projects (e.g., you have only added attributes within a given shapefile, or have added attributes that have no effect on symbology), then you can skip to step 5 (following), otherwise follow steps 2–4.

2. Keep your files by themselves in a folder to prevent confusion and errors when converting to ArcPad. After all of the line and point files are in the same projection, start ArcMap and add these files to the map. Once the files are in ArcMap, you should begin by setting up the linework for the map, and the line styles you build in ArcMap will be exported to ArcPad. Typically the linework will be drawn either generically by layer (e.g., all faults are red, heavy lines) or based on some attribute (e.g., solid line for exposed contacts, dashed line for float contact). Note that if you are building the project as a blank project, and plan to draw linework based on an attribute, you must begin by generating one line for each attribute you plan to use for different line styles and filling the attribute field with each attribute. In our examples, the field “contactquality” is filled by the attributes exposed, exposed_projected, approx_float, and so forth, and different symbology is attached to each line. This step needs to be repeated for every line object in the map; e.g., in our generic mapping shapefiles, this includes depositional contacts, faults, unconformities, fold axial traces, and intrusive contacts. Regardless, the key is to develop the linework that best fits individual need. A cautionary note: linetypes can be changed in the field in ArcPad, but results can be unpredictable; thus, we recommend avoiding those field changes unless absolutely necessary.

3. After developing a set of line definitions in ArcMap, work on symbology of point files. For simple point-based files like stations, this operation is simply choosing a symbol, but for orientation symbols this procedure is complex. Indeed, it is sufficiently complex that we highly recommend starting with our “orientation” shapefile before attempting to build your own variant. If you do choose to build a variant from scratch, the following are the key steps.

A. Choose an appropriate symbol based on attribute (chosen in the symbology tab of the layer properties) by right-clicking the selected layer, followed by choosing “unique values” in the categories field.

B. Use the pull-down menu under the “value” field in the categories window, then click the “add all values” button. As with linework, if the project is blank, you will need to have one point with each attribute you intend to sort on as “initial” data to undertake this step.

C. At this stage, change the symbology to your choices (e.g., a standard bedding strike and dip symbol versus foliation), and when all symbology has been chosen, complete the operation by going to the “advanced” button in the lower-right corner of the symbology tab window. In the pull-down menu, choose “rotation” and a pop-up dialog box appears. In the dialog box, choose the “geographic” button, and in the pull-down menu, choose the attribute field that corresponds to the azimuth field for rotation of the symbol: typically strike for planar features recorded with a right-hand rule.

D. Go to the labels tab and select the field for dip measurements as a label field.

E. A cautionary note: for those accustomed to dip direction and dip measurements or strike and dip measurement without the right-hand rule convention, there is as yet no workaround for recording data this way. Similarly, some default symbols will not work with this method; e.g., fold axis symbols that are preloaded in ArcGIS are 90° off. Note that if you are planning to export the project to a handheld device, the handheld device must have the custom ESRI fonts installed for the symbology to plot properly. The easiest method is to use a PC, navigate to the font folder in the Windows directory, and find all of the ESRI fonts. Copy these fonts to the clipboard, and paste them into the font folder in the Windows directory of the Windows mobile device (typically this will be done through the Active-Sync application from Microsoft).

F. When all symbology is set, the data need to be exported to ArcPad. This process seems straightforward, but there are bugs in the export software with versions as recent as ArcPad 7.1 that produce unpredictable results. A known procedure that works is first, from the ArcMap window, right click on each shapefile for which you have developed symbology, and scroll down to “save as layer file”; this will create a dialog with a file with the same name and a .lyr extension, or a layer definition file. Save each layer definition in the same files as the shapefiles. Second, open a new ArcMap window and add all of the layer definition files you just created. The result should look identical to your other ArcMap window: if it doesn't, fix the parts that did not export properly, or fix the links, and repeat. When this first export is complete, minimize or close the original ArcMap file. Third, add all of the remaining data you wish to use in your ArcPad project to the newly opened map. This typically will include mostly rasters such as aerial photographs, digital raster graphics (DRGs), and shaded reliefs from DEMs, but may also include other vector files. Make sure all of these files are in the same projection before proceeding. If ArcMap is projecting them on the fly, reproject them to the map reference frame, add the reprojected map, and remove the file that is not in the same projection. A cautionary note: ArcMap does not tell you what projection it is using when using on the fly projection, and you can be easily fooled if you do not check. The program defaults to the projection of the first projection it recognizes when files are added, even if the first file is later removed! Thus, to avoid problems, if any files are in a different projection, it is best to exit ArcMap, restart the program, and remake a base map with a layer definition known to contain the correct projection. Fourth, use the ArcPad Data Manager to export the map features to make an ArcPad project. This tool does not automatically appear in ArcGIS and is added from the Tools menu of ArcMap under “customize.” If you have ArcPad 7.1, do not use the generic ArcPad tools under the customize tab in ArcPad 7.1 as this tool is a legacy of earlier ArcPad versions and is unreliable in ArcPad 7.1, although it is the only tool in earlier versions.

4. If you are using the files provided here as templates, they should work in ArcPad 7 or 8. However, you may want to change the look of the forms we have built. If so, or if you are building your own project, you will now need to open the .apl file that was exported from ArcMap in ArcPad Studio, and build custom forms. This is accomplished by pulling down the forms menu, then click on “edit form” in the popup menu. The interface is a graphical interface for building a custom form and is well explained in the documentation. Cautionary note 1: Although ArcPad Studio is relatively intuitive for building custom forms, the program does not always generate a reliable script. The program frequently generates ghost boxes that do not show up in the “test form” field of the program, but do appear when the script is run in ArcPad. The best way to find these ghost fields is to look at the raw script files, searching for items like a combo box or edit box with no attributes named in the script. This is most easily done by comparing an anomalous script to a working script. Cautionary note 2: ArcPad Studio has a bug that has yet to be fixed as of version 7.1. In combo boxes or list boxes, the program offers two fields for filling attributes in the pick list. This implies that one of the fields is a label and the other is the actual text that will fill the field in the attribute table. In fact, only one of these fields is actually written to the data table. Thus, it is important to make both fields the same, even though it is tempting to make more easily understood labels in the forms. In addition, combo boxes or list boxes can also call a .dbf table containing the attributes for that field. This feature is highly desirable for fields that are likely to change routinely; e.g., we use a field for “geologist” in our station table to identify the person who collected the data, and it is easier to make this change in a .dbf table than constantly revising the .apl file. Unfortunately, this requires some care. Specifically, it is very important to remember to always copy this .dbf table when generating a new project from an old one.

Moreover, we have had unpredictable problems with .dbf table links being broken or corrupted, producing variable results. Thus, until some of these problems are fixed, we tend to avoid using .dbf tables for attributes, except in cases where the process is highly repetitive; e.g., several shapefiles using the same set of attributes.

In a field project involving computers we suggest use of a checklists and carrying specialized equipment for troubleshooting. This type of procedure is probably familiar to most geophysicists, but is alien to most geologists. The lists here are only an example, and would generally need specialization to specific applications.

12 V battery (size dependent on project needs; minimum of 2–3 Ah/user)

Electrical multimeter (DC volt, ohm, continuity minimum; DC amps useful)

Solar panel (20–40 W typical for small group)

Note: to calculate power requirements, recall Joule's law: P = IV. A solar panel normally outputs 18 V, but must be regulated to 12 V for battery charging. Thus, for a 40 W panel its full-sun output will be at 2–3 A. With 4 users, using 2-3 Ah/day, this illustrates that ∼4 h of full sun will be needed to maintain a fully charged battery. This arithmetic can be adjusted for any field area, but it is critical to build in at least 2–3 days of spare power for bad weather, or other eventualities.

Wire cutters

Needle-nose pliers

Insulated wire, ∼30 m, ∼#18 usually sufficient, 2 color-coded single-strand wire is best

Cigarette lighter accessories (highly desirable, both for car charging systems and solar systems for quick connections; remember, however, that the center terminal is always + on these systems)

Electrical tape

Screw drivers (+ and -)

Wire nuts

Miscellaneous electrical connectors and/or terminal blocks(optional)

For each device being used (repeat checklist for each device):

Device 1

Software loaded and operational

Project and data loaded

GPS operation tested (this may require a simple test, or a more elaborate test with wireless devices like Bluetooth GPS units)

Memory card installed and data paths set to write to memory card

110 V power available

Chargers for all computers packed

12 V inverter needed for any equipment (if this equipment is needed, you may need a separate check list for cigarette lighter accessories and other items)

Power strips sufficient for charging all devices

12 V system with stand-alone battery and solar charging:

All wiring and connection system in place and tested?

110 V inverter(s) tested and operational?

Spare fuses?

Power needs consistent with equipment on hand (e.g., inverters, battery capacity)

Tool kit packed

Battery tested for voltage and power (this can be done at most auto supply stores, or you can buy your own tester. Necessary if you are using an old battery)

Solar panel tested

12 V system using auto charging system

This paper would not have been possible without the generous support of a series of research and equipment grants that allowed us to test various types of equipment. These include our first tests of equipment supported by National Science Foundation (NSF) grant EAR-9706233 to Pavlis and Serpa and the Louisiana Board of Regents (BOR) Support fund (1998); a Keck Foundation grant to the University of New Orleans, which supported our first major equipment purchase; a second Louisiana BOR Support grant (2003) supporting equipment update; and a University of Texas (UT) STARS grant to UT El Paso that supported purchase of our present generation of equipment. Research grants that used this equipment and helped support the effort include NSF grants EAR-9706233, EAR-9725035, EAR-9910899, EAR-229939, EAR-0409009, EAR-0735402, and EAR-0711105. We thank Midland Valley Ltd. for access to Move software through academic discounts and for assistance in using the software. Development of our present system would not have been possible without input from Boyan Brodaric, Evan Thoms, Doug Walker, and George Brimhall, as well as collaborative researchers in the St. Elias Erosion and tectonic Project (STEEP) and students working on various research projects listed here. We thank David Mogk for helpful comments on improving the manuscript.