WDB User's Manual

Abstract

WDB is a database system designed to store MHO (Meteorological, Hydrological and Oceanographic) data in a PostgreSQL database management server. The purpose of the WDB system is to improve the quality and effectiveness of IT systems for MHO production by providing a complete, flexible, and effective data storage solution for real-time and archive data.

This is the User's Manual for WDB version WDB_VERSION

Table of Contents

1. IntroductionWhat is WDB?A brief history of WDBFurther InformationReporting Bugs2. Getting StartedWDB OverviewInstallationChecking the ConfigurationUpgradingLoading Data into WDBLoading GRIB filesAccessing Data in WDBWDB Call Interface3. InstallationQuick StartRequirementsSupported PlatformsInstallation ProcedureConfigurationBuildInstallingTestingUninstallationCleaning4. System AdministrationUser ManagementData DescriptionIntroductionData ProviderPlace DefinitionValue ParameterLevel ParameterData Cleaning5. Reference Pageswdb — WDB administration utility. It is a part of the WDB system.wdbConfiguration — Get information related to wdb database settingswdb.conf — Information about wdb database configuration

List of Figures

2.1. Overview of the WDB Architecture

Table of Contents

What is WDB?A brief history of WDBFurther InformationReporting Bugs

WDB is a storage system for meteorological, hydrological, and oceanographic data, including physical and chemical data, but excluding biological/environmental data. It is primarily designed to store field data (meteorological forecasts and analysis, oceanographic wave and circulation models) as well as observations and point forecasts. The purpose of the WDB system is to improve the quality and effectiveness of IT systems for MHO production by providing a flexible and effective data storage solution for real-time and archive data

WDB is an open-source system built on the PostgreSQL object-relational database management system. Key features of the system are that it:

• supports high availability production
• can handle most types of meteorological, hydrological, and oceanographic data
• is flexible enough to be extended with new data types and data formats
• is easy (and cheap) to maintain and operate
• provides a simple and consistent interface to all the different kinds of data

As WDB is released under GPL, it may be used, modified, and distributed by anyone free of charge for any purpose, be it private, commercial or academic.

The WDB system was initially developed by Meteorologisk institutt, Norway (met.no) from 2006-2008. WDB is a descendant of the ROAD system, a real-time operational database system developed at Sveriges Meteorologiska och Hydrologiska Institut (SMHI).

This section will contain a brief overview of the ideas and history of the ROAD/WDB system.

In addition to the manuals, there are (or will be) other resources available on WDB:

• Web siteThe WDB web site, http://wdb.met.no contains information about the latest release and lots of other information to make your work (or play) with WDB more productive.
• FAQsThe FAQ list contains continually updated answers to frequently asked questions.
• READMEEvery WDB package contains a README file.

When you find a bug in WDB, we want to hear about it.

This section of the manual will discuss the bug reporting policy followed by WDB. Since there is as yet no public access to our Bugzilla http://wdb.bugs.met.no/, the best solution at the moment is to contact us on the appropriate mailing list (usually wdb-users@list.sourceforge.net).

Table of Contents

WDB OverviewInstallationChecking the ConfigurationUpgradingLoading Data into WDBLoading GRIB filesAccessing Data in WDBWDB Call Interface

In this section, we will briefly describe the basic architecture of the WDB system. Understanding the architecture of WDB will help make the following sections somewhat clearer.

At its core, the WDB system consists of a database management server (built on the PostgreSQL DBMS), a number of utilities for maintenance and data loading, and a function interface for data extraction. We refer to the data loading utilities as loading programs and the data extraction interface as the WDB Call Interface (WCI). Figure�2.1, “Overview of the WDB Architecture” illustrates the relation of the different components of WDB.

Figure�2.1.�Overview of the WDB Architecture

We refer to the WDB data model together with the WDB Call Interface as the WDB core. This comprises the data storage components of the database along with the interface to read and write data. The WDB Call Interface (WCI) is essentially a database module that provides the application developer or user with a function-based interface that can be used to extract data from WDB. This function interface is accessible through SQL, which means that any programming language capable of querying a PostgreSQL database can access data through WCI; at least in theory. Users of a WDB database never access the tables or views of the database directly; all access goes through WCI functionality.

The loading programs are utilized to extract data from the data sources (typically files or some network service) and load them into the database. In principle, each type of data: GRIB, FELT (an internal data format used at met.no), BUFR, etc., will have its own loading programs. The options and interfaces to the various loading programs are designed to be as similar to each other as possible, however.

The maintenance utilities are used for a variety of tasks related to the administration of the database, such as data cleaning (removing data that is no longer required), creating and deleting users, and checking on the status of the system.

Before you can use WDB, you need to install it. If you are not sure whether WDB is available on your site, or whether you can use it for your needs, you can install it yourself. WDB can be installed by any unprivileged user; superuser (root) access is not required (though some database privileges are required). If you are installing WDB yourself from a source package, then refer to Section Chapter�3, //Installation// for the detailed installation instructions, and return to this guide when the installation is complete.

If your site administrator has not set WDB up in a default way, you may have a little work to do checking and setting up your environment variables. If WDB has been installed correctly, you should have access to the wdbConfiguration utility. This can be used to verify the configuration of your system.

			%> wdbConfiguration
			database =      mywdb
			host =          localhost
			port =          5432
			user =          myuser

This tells you what the default connection information of your WDB database is assumed to be. If these are incorrect, you can change your settings by editing the wdb.conf.ex file installed in the WDB data directory (usually /usr/local/share/wdb and saving it to $(HOME)/.wdb

If you are unsure as to whether the connection information is correct, run:

			%> wdb

wdb runs the administrative interface to a WDB database. Like all WDB utilities, it will attempt to connect to the database using the connection information stored in your wdb.conf file, unless alternative connection parameters are given on the command line. If the wdb utility is unable to connect to the database, something is wrong with your connection options. Check whether your database server is running. If the database server is down, then obviously you can not connect to it. Otherwise, you may need to consult your site administrator (or if that is you) the PostgreSQL documentation to make sure that your database environment is set up correctly.

It is possible to upgrade WDB without deleting the data currently residing in the database using the upgrade scripts. Currently, the system may only be upgradeable in direct progression; i.e., from one version to the immediately following version (this is the only scenario tested by WDB's test framework). So version 1.1.3 will upgrade 1.1.2 but there is no guarantee that 1.1.3 will upgrade from 1.1.1 unless the latter is first upgraded to 1.1.2.

Note that there is never any guarantee for upgrades from one major upgrade to the next. For these upgrade, a full install is assumed.

It is strongly recommended to ensure that you have a recent backup of your database before upgrading the system. Although the upgrade will rollback correctly in most situations, there is always a risk that things may go wrong.

To upgrade from a source package, you can run the following commands from your build directory:

			%> ./configure
			%> make
			%> make upgrade

WDB can also be upgraded using the upgrade functionality from Debian packages.

Data is loaded into WDB using one of the loading programs. Most of the loading programs have a file interface; in addition, several of them can be set up as persistent loading processes.

Each of the loading programs has its own manual page; consult the Loading Programs User Manual for details. In addition, all executable WDB components have the –help option implemented to provide extensive information about the options available to the program. In this section, we will just briefly go over the broad details.

The gribLoad utility is used to load GRIB files into the database. It takes as input the name of the file(s) as well as a number of options, decodes the GRIB file using the cross-reference metadata for GRIB in WDB, and stores the fields from the GRIB file in WDB. The GRIB loading program is invoked by typing gribLoad and the filename from the command line.

			%> gribLoad myfile.grib

This loads the GRIB file myfile.grib into the WDB database using the default parameters for the gribLoad utility. If the database configuration is not the default, you will want to specify the correct configuration using the available options. For example:

			%> gribLoad -d mywdb -u myuser -p 5433 myfile.grib

This loads the GRIB file into the database “mywdb” on port “5433”, with the database user “myuser”. For the full list of options available with the gribLoad utility, use the –help option or check the GribLoad documentation.

Note that the gribLoad utility works together with wildcards. For example, you could use the command:

			%> gribLoad *.grib

This would load every file in the current directory with the “grib” suffix into the database one after the other. Note, though, that if you have a system with multiple processors and good enough disks, you will be able to achieve significantly better loading performance by loading several files in parallel.

To access data in WDB, one needs to go through the WDB Call Interface (WCI). WCI is a data-retrieval API implemented using SQL functions.

To use the WCI, the user connects to the database through any SQL interface and then retrieves data using the WCI functions. This means that, in theory, data can be retrieved through the WCI from any programming language or program that supports SQL queries to a PostgreSQL database server. For the example below, we will assume a connection to PostgreSQL through a psql client interface.

To retrieve data from WCI through SQL, you need to understand three (two) functions:

wci.begin

The wci.begin function call “opens” up the connection to the WCI. In practice, it sets up a number of internal variables in the database and checks that your user has permission to read and/or write from WCI. The wci.begin call must be called before any other WCI functions are called.

						mywdb=# select wci.begin('myuser');

wci.read

The wci.read call is the key function call in the WCI used to retrieve data from the database. In WDB, data is classified by a number of dimensions; the dataprovider (the source that provided the data), the location of the data (and what geographical interpolation to use), the reference time (time of reference for the data), the valid time (the time for which the data is valid), the value parameter (the “MHO parameter” that identifies the data values in the database, the level for which the data is valid (height, depth, etc.) and finally the version of the data (data can exist in multiple versions). Each of these dimensions can be passed as a parameter to the wci.read function. In addition, the wci.read function also takes as a parameter the type of data to be returned.

mywdb=# select *
	from wci.read ( ARRAY['hirlam norway'], -- Data Provider
		'POLYGON((10 60,11 60,11 61,10 61,10 60))', -- Location
		'1980-01-01 12:00:00',  -- Reference time
		'inside 1980-01-02 00:00:00 TO 1980-01-03 00:00:00', -- Valid time
		ARRAY['air temperature'], -- Value Parameter
		'2 height', -- Level
		ARRAY[-1], -- Data version
		NULL::returnFloat   -- Return type
	);

Specifying a NULL for a dimension, corresponds to asking for all data of that kind. For example:

mywdb=# select *
	from wci.read ( ARRAY['hirlam norway'], -- Data Provider
		'POLYGON((10 60,11 60,11 61,10 61,10 60))', -- Location
		'1980-01-01 12:00:00',  -- Reference time
		'inside 1980-01-02 00:00:00 TO 1980-01-03 00:00:00', -- Valid time
		NULL, -- All parameters
		NULL, -- Any level
		NULL, -- All data versions
		NULL::returnFloat -- Return type
	);

This query would return all data for the location, reference time, and valid time specified, irrespective of what value parameter, level, or data version the data is recorded with. If you're retrieving data and know that there is only one or very few values possible for a given dimension (e.g., retrieving data with only one data version value in the database), it will usually be more efficient to set the dimension in the wci.read dimension to NULL rather than specifying the value explicitly.

The wci.read call permits great flexibility in the specification of queries, allowing the user to extract individual records in the database or thousands of records. Data can also be extracted as points (as above), or entire fields of data.

wci.end

The wci.end call “closes” down the connection to the WCI, and resets any internal variables that may have been changed by the WCI. It is, strictly speaking, not necessary to call wci.end if you subsequently close down the database connection (as this will drop all the settings anyway), but not doing so can lead to problems if you subsequently continue working on the same connection.

						mywdb=# select wci.end( );

For a more thorough description of the functionality in the WDB Call Interface, consult the WCI User Manual.

Table of Contents

Quick StartRequirementsSupported PlatformsInstallation ProcedureConfigurationBuildInstallingTestingUninstallationCleaning

The quick way to install the WDB system is simply to do the following (this requires that your system has all of the prerequisites for the WDB system installed and operational).

Retrieve version WDB_VERSION of the WDB source from the download section of the WDB website (http://wdb.met.no). Unpack the source package to a suitable directory, and from this directory run:

			%> ./configure
			%> make
			%> make install

The rest of this chapter discusses the details of installing WDB.

In general, WDB should be possible to run on any modern, Unix-compatible platform that is capable of running PostgreSQL. However, it has only tested on platforms as described in Section the section called “Supported Platforms”.

The following software packages are required for building WDB:

GNU make

GNU make or another, compatible, make program is required. WDB is developed and tested using GNU make version 3.80. There is no reason why it should not work with earlier versions, but obviously there are no guarantees.

C++ Compiler

You need an ISO/ANSI C++ compiler. We recommend a recent version of GCC, but WDB should compile with most variants of compilers.

GNU tar

GNU tar or similar archiving software able to handle tar.gz files is required to unpack the source distribution in the first place, in addition to either gzip or bzip2.

GNU sed

GNU sed version 4.1.5 or later is used for performing text transformations on the WDB system files. If you need to get a GNU package, you can find it at your local GNU mirror site (see http://www.gnu.org/order/ftp.html for a list) or at ftp://ftp.gnu.org/gnu/.

GNU readline

GNU readline version 5.x or later is used for handling of command line inputs in the WDB administration tools. If you need to get a GNU package, you can find it at your local GNU mirror site (see http://www.gnu.org/order/ftp.html for a list) or at ftp://ftp.gnu.org/gnu/.

PostgreSQL

You must have access to a PostgreSQL 8.1.x (or later version) server, to be able to install a WDB server. WDB utilizes the pg_config utility to retrieve information about your installed version of PostgreSQL, so take care to ensure the right version of pg_config is in your path if you have multiple versions of the database server installed. If you need to download PostgreSQL, see http://www.postgresql.org

PostGIS

PostGIS 1.1.x or later is used for the geographical objects stored in WDB. The WDB installation scripts utilize pg_config to determine the location of the PostGIS scripts, so care should be taken that PostGIS is installed correctly (i.e., in the SHAREDIR of PostgreSQL; this installation is however not consistent across all versions of PostgreSQL and PostGIS). If you need to download PostGIS, see http://www.postgis.org

Boost

Boost libraries version 1.33.1 or later are required to compile a number of the programs in WDB. Boost can be downloaded from http://www.boost.org

Log4Cpp

Log for C++ (Log4Cpp) 1.0.x or later is utilized for the logging functionality in WDB. It can be downloaded from http://log4cpp.sourceforge.net/

The following software packages are optional. It is possible to compile WDB without these packages, but certain options will then be disabled, as explained below.

CppUnit

CppUnit version 1.x.x or later is used for the unit tests of WDB and some of the installation and performance test programs. WDB can be compiled, installed and run without these programs, but the tests will be unavailable without this package. CppUnit can be downloaded from http://www.boost.org.

You may wish to verify that you have sufficient disk space. The compiled source for WDB requires approximately 120 MB and an empty PostgreSQL installation with WDB can rapidly take up to 200 MB of disk space (more if installation tests are run).

Currently, WDB is only extensively tested on Ubuntu Hardy and developed on the same environment. It has previously been run on Debian Etch and Fedora Core 5, and there should be no reason why it should not be able to run on any Linux OS with the prerequisite libraries installed.

You can examine the systems against which WDB is currently being tested (and thus supports) by checking the WDB buildbot.

The first step of the installation procedure is to retrieve and unpack the source files for WDB. Once this has been done, you can configure the package.

First, you will need to configure the source tree for your system and select your build options.This is done by running the configure script. For a default installation simply enter:

			./configure

This script will run a number of tests to guess values for various system dependent variables, detect quirks of your operating system, and finally will create several files in the build tree to record what it found. (You can also run configure in a directory outside the source tree if you want to keep the build directory separate). Once the script has completed running, it will print out the settings for your system.

The default configuration will build the WDB database and administration utilities, as well as the GribLoad loading program. All files will be installed under /usr/local by default.

You can customize the build and installation process by supplying one or more of the following command line options to configure:

–prefix=PREFIX

Install all files under the directory PREFIX instead of /usr/local. The actual files will be installed into various subdirectories; no files will ever be installed directly into the PREFIX directory.

If you have special needs, you can also customize the individual subdirectories with the following options. However, if you leave these with their defaults, the installation will be relocatable, meaning you can move the directory after installation. The man and doc locations are not affected by this.

To install WDB in a local directory (as you must, if you do not have root access), you could use:

%> ./configure --prefix=/home/myuser/local

–exec-prefix=EXEC-PREFIX

You can install architecture-dependent files under a different prefix, EXEC-PREFIX, than what PREFIX was set to. This can be useful to share architecture-independent files between hosts. If you omit this, then EXEC-PREFIX is set equal to PREFIX and both architecture-dependent and independent files will be installed under the same tree, which is probably what you want.

–bindir=DIRECTORY

This specifies the directory for executable programs. The default is EXEC-PREFIX/bin, which normally means /usr/local/bin.

–datadir=DIRECTORY

This specifies the directory for read-only data files used by the installed programs. The default is PREFIX/share.

–sysconfdir=DIRECTORY

This specifies the directory for various configuration files, PREFIX/etc by default.

–libdir=DIRECTORY

This specifies the location to install libraries and dynamically loadable modules. The default is EXEC-PREFIX/lib.

–includedir=DIRECTORY

This specifies the directory for installing C and C++ header files. The default is PREFIX/include.

–mandir=DIRECTORY

The man pages that come with WDB will be installed under this directory, in their respective manx subdirectories. The default is PREFIX/man.

If configure is having difficulty finding a particular library or supporting component, you can assist it by asking it to search a particular path.

–with-pgsql=DIRECTORY

This specifies the directory into which PostgreSQL is installed (by default, WDB searches your PATH environment variable). WDB is searching for the pg_config application and will search DIRECTORY/bin when this option is specified. pg_config provides detailed information about your installed version of PostgreSQL. If you have multiple installations of PostgreSQL, make sure that the pg_config used by WDB is for the intended version of PostgreSQL.

–with-postgis=DIRECTORY

This specifies the directory into which Postgis installs its SQL setup files (lwpostgis.sql and spatial_ref_sys.sql). By default, this should be the location used for architecture-independent support files by PostgreSQL, given by “pg_config –sharedir”. Unfortunately, not all versions of Postgis handle the installation of these files in a standard manner. To ensure that WDB is able to locate those files, set the directory to be searched with this option.

–with-gribapi=DIRECTORY

This specifies the directory into which the ECMWF GRIB API has been installed. If set, WDB will add DIRECTORY/include and DIRECTORY/lib to its search space when searching for the header and library files for the GRIB API.

–with-boost=DIRECTORY

This specifies the directory into which Boost has been installed. If set, WDB will add DIRECTORY/include and DIRECTORY/lib to its search space when searching for the header and library files of Boost.

–with-boost-date-time=LIBNAME

WDB uses the date-time library of Boost. By setting this option, you can instruct the linker to utilize a specific version of the library; e.g.

							--with-boost-date-time=boost_date_time-gcc-mt-d-1_33_1

–with-boost-regex=LIBNAME

WDB uses the regex library of Boost. By setting this option, you can instruct the linker to utilize a specific version of the library; e.g.

							--with-boost-regex=boost_regex-gcc-mt-d-1_33_1

–with-proj=DIRECTORY

This specifies the directory into which Proj has been installed. If set, WDB will add DIRECTORY/include and DIRECTORY/lib to its search space when searching for the header and library files of Proj.

–with-cppunit-prefix=DIRECTORY

This specifies the directory into which the cppunit-config application has been installed (by default, WDB searches your PATH environment variable). CppUnit is an optional module; it is only required for the compilation of the test framework.

–with-cppunit-exec-prefix=DIRECTORY

This specifies the directory into which the cppunit-config application has been installed (by default, WDB searches your PATH environment variable). CppUnit is an optional module; it is only required for the compilation of the test framework.

–with-docbook=DIRECTORY

This specifies the directory into which the docbook processor used by WDB, xmlto, is installed (by default, WDB searches your PATH environment variable). If DIRECTORY is set, configure will in addition search through DIRECTORY/bin.

–with-kvalobsLoad

This option specifies whether the kvalObsLoad daemon should be compiled and installed. This requires that the compiler have access to the kvalObs libraries. By default, kvalObsLoad is not compiled.

If you prefer a C++ compiler different from the one configure picks, you can set the environment variable CXX to the program of your choice. By default, configure will pick gcc if available, else the platform's default (usually cc). Similarly, you can override the default compiler flags if needed with the CXXFLAGS variable.

You can specify environment variables on the configure command line, for example:

%> ./configure CXX=/opt/bin/gcc CXXFLAGS='-O2 -Wno-deprecated'

The following are the significant variables that can be set in this manner:

CC

The C compiler

CXX

The C++ compiler

CPPFLAGS

Options to pass to the C/C++ compiler

LDFLAGS

Options to pass to the linker

PKG_CONFIG

The path to the pkg_config utility.

To build WDB, run:

%> make

A cup of coffee around now might be appropriate, depending on your hardware.

In general, you should not try to install new files over an old installation; instead, uninstall the old system (taking a backup of the database, as needed, beforehand), and install the new version. Or follow the instructions for upgrading provided in Section Section the section called “Upgrading”.

To install WDB, verify that your database server is running, and then enter:

				%> make install

This will install files into the directories that were specified during configuration. Ensure that you have appropriate permissions to write into that area (if this is /usr/local, you will normally have to do this step as root). Alternatively, you could create the target directories in advance and arrange for appropriate permissions to be granted.

You can use make install-strip instead of make install to strip the executable files and libraries as they are installed. This will save some space. If you built with debugging support, stripping will effectively remove the debugging support, so it should only be done if debugging is no longer needed. install-strip tries to do a reasonable job saving space, but it does not have perfect knowledge of how to strip every unneeded byte from an executable file, so if you want to save all the disk space you possibly can, you will have to do manual work.

Note that installation, in particular the loading of the database with metadata, can take a few minutes.

If you want to test the newly built system that you just installed, you can run the regression test suite. This involves two parts: the unit tests (which can be run prior to the installatuion) and the installation tests. The test suite can be used to verify that WDB runs on your system the way the developers expected it to. Type:

				%> make check installcheck

To undo the installation, simply type

				%> make uninstall

Note, however that this will not remove directories created by the installation.

After the installation, you can make room on your drives by removing the built files from your source tree by typing:

				%> make clean

This will preserve the files made by the configure program, so you will still be able to run make later on. To clean out everything, use:

				%> make distclean

If you perform a build and discover that your configure options were wrong, you changed some option that WDB utilizes (e.g., upgraded software), or you need to build for several platforms using the same source tree, it can be a good idea to use distclean before reconfiguring and building.

Table of Contents

User ManagementData DescriptionIntroductionData ProviderPlace DefinitionValue ParameterLevel ParameterData Cleaning

In the following sections, we describe the system administration functionality that is available with WDB.

The generic administration utility of the WDB system is the wdb utility.

		%> wdb

This will bring up the wdb command line interface. From this interface, the user can type 'help' to get a list of the available commands. The wdb utility can be used to carry out a number of the most common administrative tasks.

The wdb utility can also be invoked directly from the command line. Thus:

		%> wdb help

This will print out a list of the available commands and exit the utility.

User management in WDB is implemented on top of the user authentication in PostgreSQL. By default, PostgreSQL is usually set up to accept local connections using the 'trust' method. This means that any local user can connect to the database as any PostgreSQL user, including the database superuser. To change this and switch on client authentication, have the database administrator consult the PostgreSQL Administrator's Guide, chapter “Client Authentication”.

Currently, the WDB system does not support use of password authentication in its various utilities.

WDB users can belong to one or more of three different groups: wdb_admin, wdb_read, and wdb_write.

wdb_admin

This is the administrator/superuser group for WDB. The WDB user must belong to this group in order to perform administrative acions in the database.

wdb_read

This is the default user group for WDB users. It allows the user to read data from the database through WCI functions.

wdb_write

This is the user group that one must belong to in order to be able to load data into the database using the WCI functions or the loading programs. The WDB user that runs the loading programs must belong to the wdb_write group.

Observe that the PostgreSQL superuser for the database always has full access to all of these groups.

The wdb utility can be utilized to create, drop, or modify WDB users.

			%> wdb createuser mywdbuser

This will create a user, 'mywdbuser', with the default user settings (wdb_read). The administrator can also specify precisely the settings that they would like to assign. The following command will create a user 'mywdbuser', with the wdb_write group (the 'noread' command is used to remove the 'wdb_read' group that would otherwise be assigned by default.

			%> wdb createuser mywdbuser write noread

To drop a user, replace the command as appropriate:

			%> wdb dropuser mywdbuser

It is also possible to change a users attributes after they have been created. To do so, use the 'changeuser' command as follows.

			%> wdb changeuser mywdbuser write read

This gives 'mywdbuser' the wdb_read and wdb_write roles. If the user previously had the wdb_admin role, it would have been removed.

The community at which WDB is directed (meteorology, hydrology, oceanography) has, literally, hundreds of different metadata standards. Consequently, the internal data description language (i.e., metadata) of WDB, is built on a generic template to ensure maximum flexibility.

The following section will describe the data description language of WDB in detail, as well as discuss how to modify it and keep it up to date.

At its core, the description of data in WDB reflects a dimensional model, where the value of the data are the facts, while the various parameters: data provider, location, reference time, valid time, value parameter, level parameter and level measure, confidence code/quality, storage time, etc. reflect the dimensions of the model.

Of these many dimensions, four require some maintenance of the metadata in the database.

The Data Provider of a data value, represents the source closest to the creation of the data that we can identify from the database. In order to load data into the database, the data source should be represented in the metadata of the database.

Data Provider metadata must currently be maintained in the database manually. See the relevant loading program system design notes for details.

The Place Definition of a data value describes the location for which that data value is valid. This is usually either a point or a grid (for data matrices).

Data Provider metadata must currently be maintained in the database manually. See the relevant loading program system design notes for details.

The Value Parameter represents the meteorological, hydrological, or oceanographic parameter that describes the data value.

The Level Parameter describes the level value associated with the data value.

WDB contains a data cleaning utility which can be used to clean out old data. This section will contain a description of the cleaning program, as well as how it is used.

The current version of the data cleaning utility, however, is not suitable for production usage. It is therefore not recommended to make use of it.

Table of Contents

wdb — WDB administration utility. It is a part of the WDB system.wdbConfiguration — Get information related to wdb database settingswdb.conf — Information about wdb database configuration

wdb — WDB administration utility. It is a part of the WDB system.

“wdb” [OPTION] [COMMAND]

wdb is a terminal based tool for monitoring and controlling the WDB system.

If invoked without any arguments, the utility will attempt to connect to the database program with the default arguments available.

–help

Produces the help message and then exits.

–version

Produce version information and then exits.

–logfile FILENAME.LOG

Set output logfile. The default is to print to stdout

–loglevel LEVEL

Sets the logging level, from 1 (most) to 5 (least)

-d DBNAME, –database=DBNAME

Specify the database name to connect to (e.g., wdb).

-h DBHOST, –host=DBHOST

Specify the database host to connect to (e.g., somehost.met.no).

-u DBUSER, –user=DBUSER

Specify the WDB user to connect as. The database user must have access to the wdb_grib role (this is will usually be the case if the gribLoad process is being run by the creator of the database).

-p DBPORT, –port=DBPORT

Specify the database port to connect to (e.g., 5432).

wdbConfiguration — Get information related to wdb database settings

“wdbConfiguration” [OPTION]

The purpose of wdbConfiguration is to provide information about the wdb database setup. The information provided should be enough to connect to the database, appart from authentication and authorization.

If invoked without any arguments, the program will list database host, port, along with the user name any wdb-related applications will use unless told otherwise. It is also possible to request the output of a single of these parameters. This is done by using one of the following commands:

“–database”

Get database name

“–host”

Get the database host

“–user”

Get default database user name

“–port”

Get the database port number to connect to

In addition, it is also possible to specify an output format. If none is given, the output format will match the format of the wdb.conf files.

“–psqlArgs”

Get arguments to connect to the database using psql (You may e.g say psql `wdbConfiguration –psqlArgs`)

“–pqxxArgs”

Get the connection parameter to connect to the database using libpqxx

Other options are:

“–conf”

Read additional configuration from the given file. The information in the provided file will take precedence over other configuration sources (eg. “/etc/wdb.conf”).

“–help”

Display a help message, wiht a summary of command line options.

“–version”

Display version information, then exit

wdb.conf — Information about wdb database configuration

The wdb.conf file contains database configuration for wdb. This includes the database's host, port and name. Also, the file may contain a default username for connections.

The file contains one or more “key = value” statements, separated by newlines. Comments may be inserted using a #. Allowed keys in wdb.conf are:

database

Database name. Defaults to 'wdb'.

host

Database host, either as a network address, or as a local folder. If unspecified, wdb connection will be created using unix filesystem sockets, using postgresql's default socket directory. If a folder in the file system is specified, that folder will be used instead.

port

What port to connect to. Default value is postgresql's default port (5432).

user

Database user name defaults to environment variable $USER

A global configuration file is normally placed in “PREFIX/etc/wdb.conf”. It is also possible to place a local configuration file in “$HOME/.wdb/wdb.conf”. All key mentioned here will override keys mentioned in the global file, but other values in the global file will remain unchanged.

I addition to this, every wdb application has an options for overriding the configuration, including to read another config file.

An example wdb.conf file can be found at “ WDB_DATADIR/wdb/wdb.conf.ex”.