1.2 The Data Structures for Core Groundwater Data in Australia Project

The need for consistency in groundwater data structures in Australia was initially recognised by the National Groundwater Committee (NGC), which consists of representatives from the States and Territories, the Commonwealth, BRS and CSIRO and deals with national groundwater issues. A project proposal attracted funding from the National Landcare Program (NLP) as well as contributions by the agencies represented by the NGC. The NLP funding recognises those organisations such as Landcare groups and catchment management committees that are both users and collectors of groundwater data.

A working group under the aegis of the NGC has been established for the duration of the project. Contact details of the representatives on this working group are provided in Appendix A.

The objective of the project is to:
Define a set of data structures and standards for core groundwater data used in Australia.

Core data includes both bore source data such as water level measurements which tend to be stored in relational database management systems (RDBMS) and spatial mapping such as water level contours and aquifer yield maps which may be stored in geographical information systems (GIS) or computer aided drafting systems (CAD). The project entails:

• reviewing existing groundwater data structures, relevant existing data standards, user and custodian requirements and international experience;
• deciding what constitutes core groundwater data;
• defining draft national standards for the storage and transfer of core groundwater data;
• disseminating the draft data standards for comment, via contributing agencies, professional bodies (eg. International Association of Hydrogeologists), NLP and other key client groups; and
• seeking endorsement of the standards by relevant jurisdictions through the NGC.

Definition of national standards for the storage of core groundwater data involves a spectrum of data management issues. In terms of bore information, a database structure made up of tables containing data columns needs to be constructed. Each object within the database (table, column, constraint) needs to be explicitly defined (ie. standard terminology) and described within a data dictionary. The domain or the allowable input for each data column also has to be outlined. In many columns, this will require definition of codes to be stored. In terms of GIS datasets, standards for how the data is stored, such as the attribute structure and coding, the coordinate system and projection details need to be developed. General issues include data transfer formats and metadata descriptions.