2002 DFDC Workshop, Nottingham – abstracts

Capturing digital data in the field – Ganfield: data integrity from field to final product

Guy Buller, Geological Survey of Canada


We aim to develop a field data collection tool that will emulate present information gathering procedures that will be run on a pocket PC. This tool will use ArcPad as the mapping portion of data gathering while other information will be captured using ArcPad application but will be stored in a separate distinct database. By having the two different storage techniques of data there is little or no manipulation of the original data upon returning from the field. By removing the burden of having to input field data into a computer system the scientist is able to concentrate on the big picture rather than dealing with data input problems. The storage of information in a data structure also allows the geologist to easily query all the field information to aid in determining trends or common traits in the study area. The information gathered in the field is the starting point for the development of understanding and by facilitating the access to data the time lag to publishing results is reduced. It is also hoped that the field information would be able to seamlessly link to geochemical information that would be derived after the testing of field samples later in the year. Linking the field observations to the geochemical analysis would allow a researcher to view both the geologists actual field measurements and observations and relate them to the geochemical evidence. This connected information would give much more information to an individual measurement than just the numbers being determined from a lab.


The following point form sequence items are further explained in the development plan below.

  1. Determine what information needs to be gathered by geologists in the field.
  2. Enhance map capture pages for the ArcPad application that are intuitive to the user.
  3. Enhance the field information database that takes in all the varying information that geologist would capture (i.e. make it generic).
  4. Continue development of pages in the ArcPad application that will send information to the separate database.
  5. Lab test and evaluate
  6. Redesign as per need
  7. Field test
  8. Refine as per need
  9. Release


The following is a guide to the development of the application following the procedure outlined above. The first four items may occur concurrently while the last three are subject to the final outcome of the previous item. Each item is explained below.

  1. The initial stages of the development there is the need to find out what the exploration geologist needs. The development team needs to keep in mind that much of the techniques that the geologist uses have been passed down from others and may have been in use for a long period of time. By building an understanding of what the user expects or wants out of a collection device will help the development process ensure that in the end the geologist will actually use the device. There is a caveat however, that too much information can cause a bottleneck and slow development through too many differing ideas. By entering into discussions with a few scientists there is an ability to develop a straw man concept of development. This concept allows the end-users to get a sense of where the development is going and they are able to make suggestions as to what is needed. This also makes them involved in the project, which enhances the chances of use later on. It is fairly obvious that this phase of the development is an on going activity through the whole development phase.
  2. The development of the map capture pages will be the easiest portion of the development phase as much of the work has already been completed in previous activities. The only thing to take place is the refinement of the code and the reworking of the forms to fit with the latest release of the development application. By using the latest version of ArcPad the team is able to use the latest object model refinements and thus make the final development more robust. Importantly the map page is the jumping-off point for the data collection process and must be set up so that the user can easily understand what the next action is to be done after completing the mapping portion of the application.
  3. In terms of a separate database that is to be developed some problems are foreseen. These stem mostly from the diversity of mapping and sample collecting techniques from scientist to scientist. Furthermore, the differences between specific focus groups' needs must be considered to allow for a broad range of usability of such a data system. This 'global' requirement implies that the data structure needs to be modular in design so as to be able to 'plug in' specific table sets that allow the easily assimilation of the greatest variety of data. To make this happen a common lexicon or generalised terms need to be used so that all users will be able to understand or translate common concepts to their particular need. Though the database itself does not need to be accessed by the end user, it has to be intuitive enough that non-database orientated users will not be automatically turned off by its complexity. This need for non-complexity becomes a problem as more and more diverse information is gathered. To further complicate the situation, the new data structure must be able to link to the existing enterprise level data structures that are already in place for the various focus groups. Thus the development and design in this phase will require an increase in the amount of discussion with the geoscientists to be able to meet their needs.
  4. For an application to work well, there should not be any need to jump through hoops to achieve a result. The best solution considered right now is to use a single application rather than multiple applications. This means that the main application to be used will be ArcPad, which will connect to the separate database. The connection to the database will be via ADOCE using the scripting portion of ArcPad. As the development of the scripts utilises VBScript, common to Active Server Pages on the web, there is no need to become an expert in a new language before results are obtainable. In concert with the scripting language, all the forms are built using XML which is easily understandable as it is a close cousin to HTML.
  5. The two phase lab testing and evaluation of the Ganfeld system will require the use of the tool in the field like conditions and 'show and tell' meetings with geoscientists The simulated field testing will build on the experience gained in the preliminary tests last year, where the collection of data was very successful even with a limited application design. This first phase of evaluation will focus purely on the functionality of the system and will have to be monitored closely so that refinements to functionality can be made. In the second phase of testing it is expected that there will be the discovery or addition of new end user requirements. Again, by involving the end user during the development of the product there is greater chance that the end user will adopt the system in their fieldwork.
  6. Redesign of the application will come about as to the needs of the end user. These redesigns may take place during the testing phase but should only be considered as tweaking the system rather than a redesign phase. Should the need to change pages and functionality of the application take place then this would be a redesign phase. It would be in the best interest of the team to make sure that the changes are documented so that they are reproducible at a later time.
  7. Field testing or field trials will take place in real time situations of actual field gathering. This will require that a paper backup (field note book) will be maintained at the same time to ensure against a catastrophic data loss. It is thought that the field trials will be where the greatest variability of mapping techniques or sampling technique will take place. During this phase, specific notes on required functionality change will have to be taken and passed back to the development team prior to final release.
  8. Final redesign will take placed based on information gathered from the field trials
  9. Release is where the application is in a usable format where a geologist can rely on the application more than the traditional note book and where the input of information is as rapid as writing in the note book.


Presently the first three development phases are taking place. The development has been an advancement from the early stages of last year's application design, which was developed in the course of a few days and was a bare bones application having a number of faults. Interaction with geologists continues and provides greater clarity as to the needs of the geologists. Development of the interface is continuing with some success for the non-map related data gathering. Plans are in the works for running a testing phase during the summer field season.