DATA HANDLING SYSTEMS FOR KARST AREA MANAGEMENT

ADRIAN DAVEY

Abstract

Planning and management of karst areas requires efficient but uncomplicated manipulation of a substantial amount of sites data and reference material. Experience with flexible and locally-based data handling systems suitable for area management is discussed.

Introduction

Efficient and flexible organisation of site data is essential to defensible planning and managment of karst area. The ASF Australian Karst Index (Matthews 1985) is one system for managing sites and reference information about caves. This paper examines other smaller-scale project oriented information systems which the author has used with personal computers to manage data in real planning situations for karst areas. The three case studies briefly discussed are:

Some issues in development of appropriate safeguards, maintenance, updating and transfer of data discussed.

Some General Principles

The purpose of gathering and organising data should be to develop a capability for better planning and managment. This is sometimes overlooked, expecially by purveyors of expensive and complicated computerised systems which are mystified beyond the understanding of mere planning and management professionals. Nevertheless, I think it is a reasonable assumption these days that an appropriate computer-based system will almost always be the most effective way of handling sites and area data.

A database simply consists of one or more related fields, each consisting of separate records which contain certain information about that item. Key parts of the record (fields) can be indexed in various ways and the data queried, edited or listed in any nominated logical sequence. Similarly, data - breaking it into relatively small component parts. There is a need for free text descriptions as well. Compare the 'Description' part of Davey & White 1986 site listings with the corresponding reconstruction from disaggregate data from the Australian Karst Index (Matthews 1985). Examples of coded disaggregate data items include:

Examples of free-text data items, allowing a much more free-form and potentially lengthy content, include:

Data structure typical of a databse system relevant to cave areas (in this case all of Victoria) is illustrated in the Appendix.

In my experience, the essential requirements of a data handling system which is likely to serve the interests of managers are:

The good news is that all of these requirements can be met these days for a compact capital investment of no more than five to ten thousand dollars. The equipment is relatively easy to come by, the software less so. But some proprietary software (e.g. for literature references) is already available to handle parts of the task. In any case, it is not especially difficult, with a little perseverance, for any interested user to acquire sufficient computer literacy on the job to be able to undertake their own programming. All of the systems I have successfully used have been developed this way. The greatest effort (and, if available, professional advice) should go into data structure, and into thinking about the end use of the organised data.

For the record, the reference and site systems described here are written as a suite of applications programs in dBASE III, which is a common proprietary database package. Listings are formatted and printed used PC-Write, which is a common word processing package, having the capability of reading a standard ASCII text file. It all runs on a relatively standard personal computer running under the MS-DOS operating system - in this case an IBM-compatible Olivetti M24, with 10 megabyte hard disk and 640 kilobyte memory. It uses 13cm floppy disks or the telephone lines for storage or data exchange. The hard disk is essential for any serious database use, but (especially for small areas) need be no bigger than this. I have had databases for several thousand literature references, several thousand caves, fifty cave areas, and hundreds of recreation sites, plus various other programs, text reports and general correspondence, all on the one hard disk at once, and all virtually with split-second access.

General System Characteristics

All of the sites and bibliography systems I have used share some common characteristics:

Bibliography System

Organising the literature relevant to any cave area can quickly get out of hand if a conscientious attempt is made to be aware of all aspects of geology, biology, visitor use and so forth. A bibliography system should provide for any reference to be keyed in only once. Thereafter, the only changes which need be made are in the JOB and SUBJECT codes, and in a special annotation applicable to any particular job. More importantly, it is possible to browse through lists of all items of certain subject. For example, I now have a single bibliographic database of about three thousand references, containing, among other things, citations of items relevant to:

Quite a few items are shared among these different lists. Finding an item and displaying it on screen takes under a second. If there is a long annotation, or if there are different jobs, the lower half scrolls up or down as required to the other annotations.

Areas & Sites Systems

The information relevant to individual areas and caves is much more complicated than for literature references.

As a result, the structure and program system for the two areas for which I have experience (Nullarbor Plain W.A. & S.A., and Victoria) are quite different, though similar in logic. In the Victorian case (Davey & White 1986), there were four separate databases:

The general structure of the sites and area databases is illustrated in the Appendix.

Any site can be found and displayed on the screen in under a second. There are at least three separate screens for each record:

  1. First screen: basic site data - number, name, location, tenure, land data reference and physical description;
    1a: If the description is longer than the space on the screen, the description can be scrolled up and down, the rest of the first display staying the same;
  2. Second screen: significance, use, hazards, opportunities, classification etc; and
  3. Third screen: relevant extract from Matthews (1985).

The entire database can be printed (as in White & Davey 1986) or selectively listed into various checklists.

Comments

The main issues about using such a system are:

Acknowledgements

This paper is based on work undertaken by myself and Susan White while we were consultants to the Caves Classification Committee. The co-operation and advice of the Committee, and of the Department of Conservation, Forests and Lands through which it operates, are much appreciated.

References

DAVEY, Adrian (1984) Resource Management Status of Karst Features in the Eucla Basin, S.A. Report to Reserves Advisory Committee, Adelaide. Applied Natural Resource Management, Canberra (unpubl.)

DAVEY, Adrian G, HELMAN, Peter M and CHURCHILL, Susan C (1986) Karst Features in the Gambier Embayment of SE South Australia and SW Victoria: a Bibliography. Report to Australian Heritage Commission. Applied Natural Resource Management, Canberra (unpubl.)

DAVEY, Adrian G and WHITE Susan (1986) Preliminary Management Classification & Catalogue of Victorian Caves and Karst. Report to Victorian Caves Classification Committee, Dept. Conservation, Forests & Lands. Applied Natural Resource Management, Canberra (unpubl.)

MATTHEWS, Peter G (ed.) (1985) Australian Karst Index 1985. Aust. Speleol. Fedn, Broadway

Appendix: Structure of the Database Used in the Victorian Study (Davey & White 1986)

[Each point corresponds with one or more separate fields in one or other of the several related databases.]

Areas

For the various cave areas around the state, the database provides a summary of: