Modifying the
GDADS
database design (D16)
See "Overview of GDADS Data Management" in Installing GDADS (D02) for an overview of GDADS data management, and Section "GDADS database (D03)" for an introduction to GDADS database.
Several of GDADS' database tables are specifically for internal use by GDADS, and should not be modified. The user can, however, customise the survey metadata table to meet individual requirements. Such customisation would typically be some minor changes, but it is possible to radically modify the metadata table. As noted in Section
"Database Creation" in GDADS database (D03), any editing of the database design must be done using the database's native design software, and cannot be done through GDADS. Subject to the several configuration requirements documented here, GDADS can work with any design of metadata table.
GDADS needs to know some of the details about the metadata table. These details are made available to GDADS either through the Properties.txt configuration
file, or through one of the 'special' tables of the database. One of those details, for example, is 'how to read and write the database file'—see "Configuration—Database Connection" in Installing GDADS (D02) regarding the configuration of GDADS so that it can find a 'database driver', and Section "ODBC Database Driver" in Installing GDADS (D02) for a description of setting up an ODBC (database) driver on Windows 2000.
The following documentation of the design requirements uses table names and field names from the sample database shipped with GDADS.
Metadata Table Name
GDADS needs to know the name of the table containing survey metadata. This must be defined in Properties.txt, for example:
GDADS.Properties.PrimaryTableName = SURVEYINFO
Primary Key Field of the Metadata Table
GDADS needs to know the name of the primary key of this metadata table. This is defined in one of the special GDADS tables of the database: table GDADS_FIELDINFO.
In the illustration below, the fieldname surveyname is flagged as the primary key ('isprimarykey' = 1).
Library|Help|Top |Back|
Data Types
In presenting survey details to the user, and allowing the input or editing of survey details, GDADS needs to render the metadata table onto the screen. By default, a field will be rendered as a simple edit box, suitable for display or input of text or a number. GDADS can, however, render special types of edit fields. Fields with these special requirements must be defined in the GDADS_FIELDINFO table. Three types of entries can be defined:
CheckBox
This is suitable for a simple yes or no or true or false field, and is rendered by GDADS
as a standard 'check box' object in the GUI.
Choice
This is used where the input must be one from a short list of listed alternatives. In the GUI this will be rendered as a simple 'drop-down list box'.
TextField
Controlling the Table Display in
GDADS
GDADS automatically renders the fields of the metadata database as a list of edit boxes, annotated with the field name (in one or more columns, as required). The order of this display can be specified in the Properties.txt file, for example:
GDADS.properties.order.SURVEYINFO = SURVEYNAME,
GROUND_CLEARANCE, SURVEYTITLE, SAMPLING_INTERVAL, YEAR, LINE_SPACING, CONTRACTOR, TIE_SPACING, CONFIDENTIAL, LINE_DIRECTION, MAGNETICS, TIE_DIRECTION, RADIOMETRICS, MAG_SENSOR_TYPE, EM, FULL256, GRAVITY, DOMAIN
Confidentiality
A commonly used field in the metadatabase would be one which flagged the
confidentiality status of each dataset. The current version of GDADS (August, 2001) does not check any confidentiality status of datasets. In the present implementation, it is expected that GDADS operates in a Front-Office and Back-Office environment, where the Front-Office computer uses a copy of the data, from which all confidential datasets and database records are excluded.
The onus is on the GDADS data administrator to ensure that only open file data (non-confidential) are copied to the Front-Office computer, and that the database contains only records for open file datasets.
Working with a copy of the data has the added advantage of data security, ensuring that customer-users cannot gain access to master copies of datasets.
Since GDADS currently does not make any direct usage of a confidentiality flag, this current implementation of GDADS does not need to know the name of the
confidentiality field, so it is not required that it be specified in the Properties.txt
Library|Help|Top |Back|
Commercial Requirements A
GDADS does need to know what types of data are available for sale. The convention used within GDADS is analogous to a 'shop', having various products for sale, each of which may have various flavours.
Products
• Are major data categories, such as magnetic data, radiometric data • Must each be defined in the database, with a Boolean data type
• Since these have a 'special' data type, these fields must also be recorded in the GDADS_FIELDINFO table, with their data type recorded as 'CheckBox' • Must be specified in the Properties.txt configuration file. For example, by
specifying the following three fields (magnetics, radiometrics and em), GDADS is able to query the database, and offer data for sale if any of these fields are
'checked'. Note that these field names must be written exactly as defined in the database (case sensitive). Optionally, a related entry can be specified in
Properties.txt, which are corresponding 'labels' that can be used in the
GDADS interface, and in the title portion of hardcopy maps.
GDADS.properties.buydata.products = magnetics,radiometrics,em GDADS.properties.buydata.products.labels =
Magnetics,Radiometrics,EM
• Must also be the names of subdirectories under the main survey dataset directory in the GDADS on-line data storage area of the disk.
Flavours
GDADS uses flavours as a further breakdown of 'products for sale'. These are not specified in the database, but they are entries in the Properties.txt configuration
file, and they also must have corresponding subdirectories in the on-line datastore (if, indeed, those data are for sale for a given survey).
GDADS.properties.buydata.flavours = Grids,LineData
Commercial Requirements B
In terms of 'quantity for sale', GDADS can only compute an area. Thus it knows (from the survey boundary polygon) the total area of grid data for sale, or, for a particular map sheet, GDADS can calculate the area of the intersection of a given survey with the specified map sheet. It has been noted elsewhere that a specific Datum and Projection must be defined for a GDADS database (specified in the configuration file,
Properties.txt), and that all polygons used to define survey boundaries (and map
sheet boundaries) must be generated in terms of that specified Datum and Projection. The specific Projection defines a unit of distance.
In order to compute survey data distance (for example, line kilometres or line miles),
GDADS needs to know the factor for computing survey distance from the survey area.
GDADS uses the survey line spacing as this factor, and it knows this factor (for each survey) as follows:
• The Properties.txt file specifies a database fieldname in which line spacing
should be stored
GDADS.properties.linespacingFieldName = line_spacing
• This field must be in the database's SurveyInfo table, and must be used to store (for each survey) the line spacing. The line spacing must be expressed in terms of the same unit of distance which is implied by the Projection.
• Although not database-related, Note that pricing definitions in the configuration file must also be expressed in terms related to this same unit of distance, but a factor of 1000 is used. Thus if distance is metres, then prices are expressed as per line kilometre and per square kilometre
Note: Although this Appendix is about database design, there is considerable detail included here about the related parts of the configuration file—Properties.txt—
and also aspects of the directory structure and file naming conventions which are implied by the database and configuration file definitions.
magnetics is a field in the database—
