|
1Dept. of Geology and Geophysics University of New Orleans New Orleans LA 70148 Telephone: (504) 280-6325 Fax: (504) 280-7396 e-mail: tpavlis@uno.edu |
2California Division of Mines and Geology 801 K St. MS 12-31 Sacramento, CA 95814 e-mail: jlittle@consrv.ca.gov |
Perhaps most important in this context is that new field studies will need to be thought out carefully from the outset, not only in terms of their scientific objective, but also the plan for data management and data release in forms that will be widely available. Presently, software lags far behind hardware in potential applications to geologic problems, and until that software void is filled the community will probably resist the inevitable conversion to these technologies. In essence, the geoscience community needs its own "killer ap" to convince the general geoscience community to switch over to these new technologies. Presently there is no software that approaches this "killer ap" potential, and the burden is on the geoscience community to move beyond the present status quo.
At the University of New Orleans we began experimenting with the software and hardware for handheld devices 4 years ago, and have variable degrees of success in implementation. We have largely avoided the use of conventional wintel PC based system because of both cost (our intent was to use the devices in field classes) and limitations of battery life+weight+durability of these devices. This paper outlines some of our successes and failures in this context. We use as our primary example a study in eastern California where we used this technology throughout the research project and have developed a database that includes all the basic field observations during the study. We have also used the systems in other settings, including in the very wet and cold environments of the southern Alaskan coastal ranges, and with groups of students in field classes working in the California desert.
The study area encompasses parts of Death Valley National Park as well as the China Lake Naval Air Weapons Station (NAWS), each of which presented distinct logistical challenges. For the park, our work was located in a newly declared California desert wilderness area. As a result of wilderness restrictions, all access to this area was restricted to what could be carried by pack horse or on our own backs. This restriction placed extreme limitations on field gear because we needed equipment that could use either lightweight disposable batteries or that could be charged with a small solar panel. In the case of the NAWS reservation, the logistics were completely different. Our initial work involved daily commutes of ~40 miles on slow, dirt roads and frequent hourly restrictions brought on by military exercises. In this case field efficiency was the primary consideration and any system that required extra time in the field was considered a liability. Some of our work from NAWS involved "car camp" setups at the boundary between NAWS and Death Valley National Park, and hiking to areas in the park from these camps. These camps had no serious weight restrictions for supplies, but weight restrictions on devices were a major consideration because these areas required some very long (>10km) hikes across alluvial fans to get to the areas of interest.
These logistical considerations were a primary factor in our decision to use a data collection system based on handheld devices rather than conventional wintel PC based systems. At that time the smallest laptop computers were >2kg, color screens were virtually invisible in the bright sunlight of the California desert, and battery life was generally <2hrs. As discussed below, some of these restrictions have now been resolved with wintel systems, but the weight/battery life issue is still a real consideration in choice of systems where long hikes are involved in daily field work.
These limitations led us to choose a field system based on the GSC FieldLog package (http://www.gis.nrcan.gc.ca/) for data compilation and a commercial package for the Apple Newton handheld called Fieldworker. Use of FieldLog also required a laptop for data compilation, and a second commercial program, AutoCAD (http://www.autodesk.com/, to serve as the map drawing tool and database engine behind FieldLog. Total investment for the system was ~$500-1000/handheld device, $500 for handheld software, $2000 for a laptop (not a real expenditure in this case, however, as this was not a new purchase), $400-$1000 AutoCAD software (academic pricing; commercial prices are significantly higher), $600-900/digital camera and ~$500 for incidentals (batteries, solar panel, cables, gps, etc.). Our initial funding was insufficient to purchase all of this equipment and thus, the entire field crew was not outfitted with the devices until we were nearly two years into the project. The cost for this system remains similar today, although with the demise of the Apple Newton, the fieldworker software has been ported to WinCE devices and these are the devices we presently use.
Our biggest ignorance-related mistake was a failure to develop a logical data structure for the project prior to beginning the field work. As a result our first field season of notes required extensive editing and reformatting for eventual incorporation into the database. After attending a two day GSC shortcourse on the FieldLog software, however, this problem was largely eliminated, although new problems ultimately appeared. As the project progressed we became relatively comfortable with use of the handheld devices for routine recording of structural data and notes. Nonetheless, most of us never adapted to several data recording features that should typically be developed in a full geologic GIS. Specifically, the data structure recommended by the GSC includes a series of long pick lists for developing GIS tables on the fly for point data such as rock types (which includes tables on textural features, sedimentary structures, etc), mineralogical variations (e.g. phenocryst types in volcanic units), and photographs. Although these data would have been extremely useful in later interpretation phases of the study, we quickly abandoned routine recording in these data tables in the field because it required too large of an investment in our most valuable field commodity: time to carefully look at the rocks. Our conclusion was that these data could easily be added at a later date from the field notes, and thus, the lab was the more efficient place for doing this data entry.
Digital photographs and logging these photos into a database poses a special problem. In the early generations of cameras and handhelds that we initially used there was no control on file names for the photos until the photos were downloaded to a laptop. Thus, file names of field photos could not be logged until the end of the day after downloading -- a very tedious task at the end of the day. Later devices eliminated this problem through PCMCIA flash card readers. These devices allow photos to be transferred to a handheld, or at least change file names on the photos to something that could be logged into the database. Nonetheless, even this process caused loss of valuable field time, and as a result we typically did not link field photographs into the database until the later, data compilation phases in the lab.
By the second year of the project we had a relatively streamlined data collection system and daily additions to the database were routine. Nonetheless, our map compilation and map production lagged far behind our field note-based database. That is, all of our maps were paper field sheets until well into the second year of the project. The problem was, like earlier problems of database management, brought on primarily by ignorance. That is, the first author was an AutoCAD neophyte and because map management techniques had neither been taught at the GSC shortcourse nor had yet been incorporated into the FieldLog manual, this task was avoided until we learned how to deal with these issues. Ultimately through hours of time with AutoCAD manuals and numerous communications to GSC personnel, we managed to incorporate a georeferenced topographic base into our project and were able to plot all of our station data (including structural symbols) onto the base map. In addition to the basic learning time of adapting to the AutoCAD drawing tools, we probably wasted as much as 3-4 person days in troubleshooting various problems that arose during georeferencing and datum conversions. This wasted time was partially the result of our simultaneously learning of the AutoCAD and FieldLog interfaces, but also resulted from quirks in the FieldLog extensions that are not well documented and are difficult to diagnose for a FieldLog/AutoCAD neophyte.
After overcoming these hurdles, map compilation in AutoCAD/FieldLog went relatively smoothly. The effort was time consuming, but in the end we believe this map compilation step is important step in developing an accurate geologic map that would be lost in a full-fledged digital acquisition system. Specifically, with several individuals contributing to the map there were the inevitable discrepancies at boundaries between the mapping by different individuals. Moreover, as we compiled the map line by line, we recognized errors that were unrelated to this classic "map boundary fault" problem; e.g. dangling contacts, contacts that clearly disobeyed v'ing rules for known dip, etc. Thus, compilation led to a series of field checking days to correct map discrepancy; an important step in insuring map accuracy.
Based on this experience, we believe that serious consideration should be given to how these kind of problems will be resolved as we ultimately move toward full on the fly digital mapping. Had we simply merged three independently compiled maps, it is clear that some of the discrepancies in our mapping would not have been recognized. That is, we probably would have been able to resolve the map boundary "faults" but it would have been difficult to diagnose our more subtle mapping errors. Thus, a case can be made that a standard map compilation step, like the one required by FieldLog, may be a preferred method to insure map accuracy. We believe this is an important topic that needs discussion by the broader geoscience community.
Following completion of the map compilation phase, we used the data export capabilities in FieldLog to generate a series of files in ArcInfo export format ("e00" files) from the AutoCAD linework, and these files were transferred to the GIS lab at the California Division of Mines and Geology.
When written to Arc export format, each data set is reduced to an ASCII text file that lists all the attributes, tolerances, and X Y coordinates of each vital point on the map. This file is then read by ArcInfo and converted into a spatial database called a coverage. A peculiar problem resulted when these files were read to the Unix-based systems at the CDMG. The normal filename extension for these files is .e00, but the Wingate files had an extension of .E00. ArcInfo did not recognize the .E00 extension as a valid format because of case sensitivity in Unix; an easily resolved, but initially confusing problem in the export file.
The second hurdle was a bit more challenging. When attempting to import the line data from the Wingate Wash project, the process repeatedly failed, giving a "segment violation" error message. By reviewing the .e00 file in a text editor, it became apparent that FieldLog had stored and exported line records containing over 500 vertices or shaping points. Since Arc only stores lines in chunks of only 500 or less points, importing the FieldLog data was impossible without modification. These modifications meant opening the .e00 file in a text editor and manually splitting the records for long lines into two or more records, and then editing the rest of the .e00 file to match the new line records. An .e00 file is generally a long and monotonous list of x,y coordinates, elimination of this step would save a great deal of time and eyestrain. After this edit step, the line coverage imported without difficulty. See figure 1 for an overview of this process.
|
Figure 1. Flowchart outlining the process used to import the line data into ArcInfo. |
The structural data, stored as a point coverage, was much easier to work with than the line coverage. The initial import process went smoothly and the data was displayed on the screen within minutes of receiving the file. The only modification made to this file was the positioning of the dip annotation for bedding symbols. The dip numbers were positioned directly over the center of the symbols, making the data hard to read. Each dip number has a different offset relative to its associated point, based on the strike or rotation of the symbol. In light of this, an AML (a script using arc macro language) was written to perform this task automatically, thus saving the writer hours of tedious labor.
Once the files were imported into ArcInfo the data was edited for line errors and laid over a vectorized topographic base map. The process of labeling the polygons, which adds areal information to the database, is being done manually by referring to a hand labeled map of the area. While it is common to import polygon information to and from ArcInfo using .e00 format, the given data did not include anything beyond points and lines. If this is truly a limitation of the FieldLog system, this, combined with the long line issue discussed above, make exporting FieldLog data to ArcInfo an unfortunately cumbersome process. It is possible that we may have been able to save some time in this step by using fills (hatch commands) in AutoCAD to develop polygon objects. Nonetheless, because the manual does not specify this as a option we decided it was potentially a time consuming task that might not lead to the desired result. An ESRI extension of AutoCAD (ArcCAD) would have served this function as well, and we experimented with this program. However, given the uncertainties of this program, we opted to not use it in developing the output geologic map objects.
One feature that we tried to develop fully in the map themes of the GIS was a distinction between linework layers into the four basic types of geologic contacts and the standard 3-part division of geologic contacts based on accuracy. That is, the linework themes were organized into depositional contact, intrusive contact, fault, and unconformity themes, with different layers for bedrock contacts vs approximate (dashed) vs inferred (dotted) contacts. We believe this approach is a critical one that should be routinely used as more maps become true GIS systems because distinction of these fundamental attributes is a key factor that would allow GIS applications to produce a more easily understood geologic map.
Finally, we note that when the full GIS is completed, ALL of the basic field data as well as lab data (geochemical and geochronological data) collected during this study will be incorporated as point, line and polygon themes that can be readily manipulated. Perhaps most important in this context is that nearly all of our photographs will be incorporated into the database. Thus, in the final product, the user of the map will be able to query the database and get various field photographs from different points within the study area.
In the Alaskan field studies, the first author was the primary user of the field system. He worked with two different research groups during 3 field seasons using this equipment, but no coworkers opted to use the system. This initially was largely a problem of insufficient equipment, but later, when equipment was available, coworkers resisted using the equipment for two reasons. First, we had not allotted specific time for training on the equipment. From previous experience we knew that at least two days of working with the software was needed before most workers were efficient at using the system. Given the cost of our logistics -- primarily helicopter-based field support -- we all agreed that it was unwise to use these systems where the benefit was low relative to the cost of the field effort. Second, all coworkers on these projects were veteran field geologists who had well established field techniques. Thus, unlike students, there was a tendency to resist use of the systems in favor of well-established techniques.
In these Alaskan projects most of our work was not standard geologic mapping. Rather, much of our effort was in collecting outcrop based point-data; e.g. fault kinematic data, sampling, metamorphic fabric measurements, etc. Some conventional mapping was done, however, and FieldLog ultimately proved very useful for map construction. Where point data were used, the database capabilities, particularly the spatial query feature of FieldLog, proved very useful for structural analyses; e.g. outlining structural domains for plotting on stereographic projections. In the case of the undergraduate field class it is not clear that our experience is a good representation of using these systems as a field tool because: 1) the first author was still learning the system at the time the class was actually taught; hence, he made many mistakes in teaching with the system; and 2) we had a serious equipment problem with new Fujitsu pencentra handhelds -- a bad serial port prevented using GPS systems to log position into the database. Note, this problem has yet to be resolved as of this writing and poses serious questions on the use of Fujitsu devices (see below). The combination of these two problems produced extreme frustration among the students with use of the system because they largely failed to recognize the time-saving features of the applications. Nonetheless, the students adapted very quickly to using the system in the field. Specifically, by the second day of field work they had no problems with routinely using the systems.
Although the system achieved its basic goals, we believe that we are still far from a "killer ap" for geologic mapping and field GIS systems. The learning curve for adapting to the field system is sufficiently steep that most geologists would probably not take the time to develop the expertise to independently put together a project like the Wingate Wash database. In a large organization, where a dedicated staff member might become proficient in the more subtle features of the program, some of these problems would be less apparent. That is, routine data entry and data manipulation in the software is easily learned in a few days, particularly by younger workers like the geology field class who had no difficulty adapting to the system. However, what those students did not necessarily recognize was that many hours were spent "behind the scenes" in preparing the databases and maps that were needed for the field work. Thus, someone has to devote the time for these efforts, and that time investment is significant. Admittedly, once the basic setups are learned, these steps can be done more efficiently, but until a member of an organization obtains those skills, the system can be very frustrating to use. In academia this responsibility will invariably fall on the shoulders of a faculty member, and it is doubtful most faculty would devote as much effort as the first author did in this study.
In addition to the setup times for a project, the FieldLog system also ultimately requires export to a standard format such as ArcInfo or MapInfo for release in a form that would be more widely available to the public. These steps require yet another layer of expertise, at some level, to take the geologist's product and convert it into a form for widespread distribution. This was, in fact, the intent of the software as developed by the GSC; i.e. to insulate the geologist from the nuts and bolts of GIS systems and allow the geologist to focus on the geologic problems at hand. Although true in theory, in practice the system may not actually achieve that goal. This is particularly true in small organizations or an academic environment where there is no staff member, other than the geologist, to handle the data conversions and final GIS preparation.
Indeed, the use of the AutoCAD/FieldLog system also requires significant training with a moderately steep learning curve which, although less steep than software like ArcInfo, is probably comparable to programs like ArcView. Admittedly, once the user becomes comfortable with the drawing tools of AutoCAD it is a much richer drawing environment than the rather limited drawing tools of ArcView. Nonetheless, it is debatable that this drawing environment is worth the effort required in personnel and data conversions that result from use of the AutoCAD environment. We will probably continue to use this system for one to two years because we have already invested in the hardware, software, and training needed to use the system. Nonetheless, the software is developing rapidly and it may be necessary to move to a different system more quickly.
Specifically, two new products may offer a software solution that will combine the best features of the GSC system -- highly portable handheld devices with long battery life and a simple user interface for the field component -- with the full-features of a GIS system like ArcInfo. These are:
We have not yet used either of these products, however, and cannot yet give an appraisal of their ease of use.
Although some of these data may be useful for the field observer, the primary value of collecting these data is for use by other researchers who may, in later years, be interested in a field area and would like access to as much information about the area as they can possibly obtain. As data collection systems become more sophisticated, it may ultimately be possible for a continuous video stream to be recorded during all field operations; a data set that could be extremely valuable, but also difficult to manipulate. Other tools now available include laser ranging devices, which allow detailed mapping of cliff faces without having to climb to the sites, and high-precision differential GPS systems that can log real time positions to cm levels of precision. Both of these devices may ultimately force geologists to modify many traditional field procedures in the interest of increased accuracy afforded by these devices. That is, in cases where logistics allow easy access, it might be preferable to walk all contacts while recording positions, or survey in contacts, rather than the traditional field method of making point observations and drawing map contacts because the high-tech methods allow a much higher level of accuracy to the field data.
First, in the choice of any field computer, be it a handheld device or a wintel PC, the choice of display is critical for success of field operations. Until recently color displays were essentially unreadable in the field and the only practical field displays were monochrome. This has changed in the last two years with develop of transflective displays. Nonetheless, these displays also have important problems. Specifically, in many of these systems the display is very good in bright sunlight -- although admittedly colors are often odd, but is murky and hard to read in normal lighting. Thus, in some cases (e.g. the Fujitsu Pencentra 130) the device is excellent in the field, but has little value for other applications indoors. In other cases (e.g. the Fujitsu Stylistic LT) the advertised transflective screen is useless because the manufacture used a shiny screen coat that reflects sunlight and glare makes the transflective feature marginal for most conditions.
Second, digitizer options can greatly affect the functionality of pen interfaces. Since most handhelds, and most wintel systems worth using in the field, use a pen interface, the nature of this interface is very important in ways that are not obvious at the outset. There are two general classes of digitizer: EM digitizers and touch-screen systems. Of the two, the touch screen systems are most widely available and are universal on handhelds. However, they have serious limitations, particularly where they serve as a replacement for a mouse as a pointing device. Specifically, they suffer from two problems: 1) if the digitizer is excessively sensitive, an accidental contact of a hand on the screen can make the cursor "jump" across the screen -- not desirable if you are trying to carefully draw a line; and 2) the cursor cannot track the pen on a touchscreen and thus, the "pen down" command in a drawing mode can produce unwanted problems, particularly if the digitizer is inaccurate. In our experience it is the second problem that is most frustrating. That is, when using a touchscreen for drawing, you do not generally know exactly where the line will start until the pen first contacts the screen, and if this position is wrong -- either by an inaccurate digitizer or the user holding the device at an odd angle -- the lines will be mislocated, requiring annoying editing at a later time. In sketch modes this can produce whole lines that are mislocated, or in point-click digitizing modes (straight line segments connecting digitizing points) this can lead to erratic digitizing errors. Some newer wintel system get around this problem by allowing a separate button to operate as a "mouse click" so that the cursor can be moved to the right position, then the "click" activates the point. However, this procedure undoubtedly takes some time to adjust to. EM digitizers do not suffer from this problem because the system tracks the cursor when it is in close proximity to the screen. Unfortunately, EM digitizers are expensive and have largely been replaced because of cost-consciousness of most users, particularly in the handheld market.
Third, the form-factor of a handheld or wintel PC is also an important decision. In PC's the choice of laptop vs pen tablet is a personal choice that should not be made lightly. Laptops/clamshell systems are best for typing, but are hard to use in a drawing mode; i.e. the keyboard gets in the way of hands and it is very easy to accidentally strike a key. On the other hand, pen tablets require an external keyboard or reliance on handwriting software (still less than perfect); an awkward arrangement that requires getting used to.
Finally, we have also experimented with several generations of digital cameras. These devices have evolved so quickly it is difficult to make useful appraisals, but any user should recognize the importance of rapid data transfer, and file naming problems inherent in these devices. Thus, for field systems the user should always purchase a PCMCIA flash card reader to allow routine data transfers and file naming needed to keep track of field photographs. This option is inexpensive for Smartmedia cards and Compact flash, but to our knowledge is still not available for Sony's proprietary "memory stick" devices.