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:

• resource bibliographies for the Nullarbor Plain (WA & SA - Davey 1986) and Gambier Embayment (SA & Victoria - Davey & others 1986) karst regions, and a draft bibliography of cave management in Australia & New Zealand (Davey 1987, this volume);
• a karst sites database for the Nullarbor Plain region, SA & WA (Davey 1984 & unpublished); and
• a preliminary classified management catalogue of Victoria's caves (Davey & White 1986)

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:

• site reference numbers
• names
• grid reference, map names etc;
• land tenure type; and
• site type.

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

• physical descriptions
• cadastral land descriptions;
• biophysical attributes;
• relevant references; and
• statements of significance.

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:

• It needs to be de-mystified: the system should be fairly straightforward, well documented, uncomplicated and flexible. It should not rely much (or preferably at all) on professional programmers. While it should be as idiot-proof as possible, it should not insult the intelligence of its users. It should make it quick and easy to complete any task. Any computer system which is difficult for its operators to use is doomed.
• It needs to be decentralised: the database and access to it must be available locally. Ideally, full responsibility for the database should be out where the action is - in the field. If head office needs access to the data, their access should be secondary - using date-stamped copies of the data file or else accessing the same file via telephone line communications. Each end should then keep a checkfile of any alteration made on the two copies of the database.
• All functions need to be accessible to the user: the system needs to be capable of providing on-screen access to any site or reference, and to print any record, any select checklist, or any full report. Loading and accessing the system needs to be of minimal effort. No programming should be required.
• Error trapping is essential: as the saying goes, "garbage in, garbage out". The software needs to be custom-designed to avoid acceptance of most errors, and to force the operator to look and check entry or editing screens before the main file is updated. In addition to minimising opportunities for literal errors, without offensive gimmicks, the system needs to alert the operator to the fact that they have correctly keyed in some nonsensical code or item! Minimising entry and editing errors, and providing for cross-checking and error-search routines, is an important aspect of software design. For error tracing, the system should ideally stamp every change or addition made to the database with the date, and with the operator/s identification.

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:

• Only recognised operators can access the system. This ensures your data is not corrupted (unintentionally or otherwise) by an untrained or curious person.
• All work in any session is fully menu-driven, with the screen giving the operator a limited number of clear choices. All data keying and manipulation around the file is as simple as possible. No programming instructions are needed. (On the other hand, for any user familiar with the software, special searches and other unusual combinations can be dealt with as an interactive programming matter - in other words, by stepping outside the menu system.)
• No database additions or changes are actually made to the master file until after the entire set have been double-checked. This helps ensure that hitting the wrong key does not corrupt your data. The option of escaping without modifying previous data is always there.
• The programs include a number of choices for:
  • adding new data
  • finding and reviewing existing data:
    • by nominated attribute (e.g. name, number, certain item containing certain information, etc)
    • in nominated order (alphabetical, numerical, combination of name and then date, etc)
    • to exclude certain kinds of items, but otherwise to look at all items which satisfy certain criteria
    • editing data
    • file maintenance (e.g. checking for errors which may have crept in, reindexing, checking file for damage after a power failure)
    • input/output of data from/to another computer file, tape or floppy disk, or by telephone
    • printing checklists or master files from the data.
• All data items can be identified with JOB and/or SUBJECT codes. Thereafter, screen editing sessions or generation of lists can be confined to certain jobs and/or subjects.

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:

• the Nullarbor Plain karst area, W.A. & S.A. (printed as Davey 1986);
• the karst of the limestone ranges of the west Kimberley region, W.A.;
• the Gambier embayment karst in SE S.A. & SW Victoria (printed as Davey & others 1986); and
• cave area management in Australia & New Zealand (Davey, this volume).

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 primary sites database, containing reference number, name, location data and much else, but mainly in small fields of only a number or a few words;
• a database of text fields containing the relatively open-ended free-form physical description; these are related back to the main database by the common reference number;
• a database containing text fields consisting of the relevant excerpt from the Australian karst index (Matthews 1985), again related back to the main file by the common reference number (NB: under the access agreement with ASF, this was only available for six months, and is now deleted from the system; in any case, with the final appearance of Matthews 1985 in print, it is now unnecessary); and
• a separate file of area data.

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:

• Getting the structure right in the first place:

  Only good advice and experience can overcome this hurdle efficiently. As a general guide, the more the structure permits a complete and intelligent appraisal to be made of the site, the more useful the system is likely to be.

• Security: preventing inappropriate access to sensitive sites data:

  The first decision is one of policy - who is entitled to know about and access certain data? There is certainly a case for some data about such things as Aboriginal sites and other vulnerable features to be kept confidential. It is also common for cave location grid references to be regarded as confidential. With normal care, security should not be a major problem. The technology is there to secure the data file. The main problem will be the users.

• Allocating maintenance responsibility, and ensuring succession as individuals move on to other jobs:

  In my judgment, this is the most important issue. Someone has to be responsible for maintaining any file, and for seeing that it is updated. They do not necessarily have to do the work, but they must understand enough of the system to be able to brief new operators and to provide for succession when there is inevitable turnover of key personnel.

  A further problem here is just how often and at what level in an organisation the actual data updating is handled. I have a prejudice for it to be done out at the grass roots, in the field. The centralised data systems which may be used to draw parallels through data from many areas can readily use second-hand data. The main problem is in making sure that the data structures and standards of preparation in the several places are all compatible. They may in effect be using the same system to maintain separate (i.e. local area) parts of the same (e.g. state) database.

• Keeping track of updates:

  This is much the same as the previous point. There needs to be careful documentation of who did what to the data, when. No data management system will work unless someone is carefully managing it and keeping records of its use.

• Maintaining compatibility with other related systems:

  Especially if a local emphasis is recognised as the most appropriate way of generating primary data, there will be a need to transfer all or part of the database into other regional, state, national or international systems on occasion. The more the database system uses standard and widely available operating systems, software and data structures the better. However, it is probably not practical to provide for much beyond present compatibility. There may come a point where it is in the interests of all Australian cave area managers for them to agree on a standard data structure, which they may then regard in agreed parts as optional, with add-on structures in agreed areas to suit particular problems.

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:

• the areas name & ASF area code;
• the karst of pseudokarst type for that area;
• identification of various named sub-areas which are included;
• a brief description of the area;
• a quoted excerpt of the description provided by Matthews 1985 for that area;
• a summary of the general geological context - lithology and relationship of surrounding units;
• list of the most relevant topographic maps which provide coverage of the area;
• a description of where the area is located, in the sense of just what area is included;
• physiographic context (e.g. whether the caves are along the coast, at river level, on a ridge, etc);
• summary of the land tenures which apply to caves in the area (e.g. private/state forest/national park, etc);
• summary of any mining, exploration or extractive tenements which may affect caves;
• land use summary (e.g. grazing, dairies, sawmills, residences, recreation, tourism, forestry, national parks, etc);
• management policy (e.g. the area is managed for production forestry, or as a protected catchment, or as a visual buffer, or as a nature conservation area, or as an intensive recreation area, etc);
• general significance of the area - just how important are some of its features;
• the level of significance of its features;
• use opportunities (e.g. recreation, new show caves, education, etc);
• hazards summary (e.g. quarries, rubbish tip, etc.); recommended objectives for caves management in the area; and
• specific area prescription - matters which deserve to be changed as a matter of priority. Sites For each individual site, the database records similar and additional information:
• reference number;
• name;
• list of other numbered sites to which it relates (e.g. as a second entrance of a cave);
• feature type (e.g. as a cave, as a secondary entrance, as a doline, as a spring, etc);
• karst or pseudokarst type;
• AMG grid zone and co-ordinate values to the nearest whole kilometre;
• best available topographic map coverage;
• cadastral location (e.g. within allotment X or within reserve Y);
• Parish name;
• land tenure (e.g. private, road reserve, cave reserve, state forest, national park, etc.);
• access permission from: (e.g. CFL, landowner, lessee, VSA, etc);
• land use and management (as for areas);
• land cover (e.g. cleared, forest, etc);
• topographic context (e.g. in doline, or on hillside, or in river cliff etc);
• rock type: the specific stratigraphic unit if relevant; exploration/quarry/mining tenements;
• physical modifications (e.g. gate, excavations, lights);
• a description of the physical features and local context of the site;
• biospeleological summary, especially with respect to bats and known invertebrates;
• surveys - reference to known sketches or survey plans of the cave;
• references - list of published and unpublished documentary items;
• quoted excerpt about the site from Matthews 1985 (if included there);
• assessment of current visitor use levels, if known;
• hazards to the site;
• grounds of significance;
• level of significance of the site;
• opportunities (e.g. run as an adventure cave);
• recommended classification;
• recommended objectives; and
• recommended prescriptions.