ADRIAN DAVEY

Planning and management of karst areas requiresefficient but uncomplicated manipulation of a substantial amount of sites data and refernce 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 (Mathews 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 & Victroia - 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 managmenet catalouge of Victroia's caves (Davey & White 1986)

Some issues in development of apropriate 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 proffessionals. 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 cosists of one or more related fields, each consisting of seperate 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 (Mathews 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, 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 13 cm 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 that 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  (N.B.:  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;

1.a 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, Susin 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  do-line,  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.