CERA: Description of Modules

Module DATA_ORGANIZATION

Overview

In module DATA_ORGANIZATION information is stored on the form, in which time information and spatial information are represented in the data set, i.e., how is the data distributed in the four dimensional space-time.
The information can be given as weekly data on a three dimensional simple grid. In this case, data points are equally spaced in all four dimensions. On the other hand, measurements on an ascending balloon will result in irregular changes of at least the space coordinates. In between these two extremes any combination of regular and irregular distributed positions can be relevant for describing the data. Additionally, one has to allow for or projections, i.e. when the data has no extension along a certain dimension, e.g. surface data or data valid at one certain moment of time only.
For the storage in module DATA_ORGANIZATION the four dimensions x, y, z, and t have to be divided into gridlike and pointlike ones. The coordinate values of pointlike dimensions normally are only valid for one certain data point each, while values of gridlike dimensions are related to many points, that differ in at least one of the other coordinate values.
The structure of gridlike dimensions is described in tables SCALE and TIME. This structure is defined by a set of positions on each axis, that make up the grid. They are given in tables POSITION and (for the time dimension) MOMENT. The positions can be equidistant, irregular, or in case of a projection just a single point; so can be the dimensions, what is described by the table DIM_TYPE for each dimension.
For pointlike dimensions the coordinate values of each point (having a number of coordinates equal to the number of pointlike dimensions to describe) are stored in tables POINT and (for the time dimension) MOMENT, being combined in the POINT_SET. Remaining gridlike dimensions can be described as before.
The following examples are to clarify this:

Examples

Simple Grid

For a simple grid in space-time the three ?_scale_id variables in SPACE and the time_id in DATA_ORG point to the axis' descriptions in tables SCALE and TIME. There the number of points along each axis is defined as well as the type of the grid.
In case of irregularly gridded points along a certain dimension, the positions on the axis are given in POSITION or MOMENT.
For regular grids, only the first and last point has to be entered into POSITION/MOMENT. Their difference divided by the number of points yields the grid's spacing.

Balloon

Aperiodic measurements on, e.g., a flying balloon lead to a set of points in space-time, that is described in POINT_SET. For every point the space coordinates x,y,z (table POINT) as well as the time of measurement (table MOMENT) are given.
The sequence_no in POINT_CONNECT is necessary if the points are not ordered by time or if all measurement are taken at one time at different points (projection along time axis). However, the field sequence_no should be filled in anyway.

Ocean Stations

Imagine you have for a couple of not moving ocean measurement stations the water temperature given at surface, at 2m, 5m, and 10m depths. As the stations are spread over the area, you describe their x,y (LON, LAT) position in POINT, where the altitude and its unit_id are set to 0 (zero). The point set is pointed to by the point_set_id in SPACE, while here x_scale_id and y_scale_id are set to 0 (zero). z_scale_id points to SCALE where the irregular depth grid is described, consisting of the four positions 0, -2, -5, -10, given in POSITION. If, e.g., all stations give data every day, the equidistant grid is given in TIME.
Describing one moving station is very similar. Just, that time_id in DATA_ORG is set to 0 (zero) and moment_id in POINT_CONNECT points to the moment, a certain measurement at the point (defined in POINT) has been taken.

SubModule PATCHED_DIMENSIONS

One dimension of a grid always can be described by giving all the gridline coordinates in the Position/Moment table. However, there can be cases, where this description is very inefficient, e.g., when the axis is compound of various parts. Each of these few parts may be efficiently described as linear/equidistant but the overall axis structure can not. A dimension is called patched, when it consists of various sections, that can be described more efficiently by one Scale/Time entry each (instead of describing the whole axis by one Scale/Time record).
In this case, the Dim_type ("patched") and the number of points should be set appropriately in table Scale/Time for the primary scale/time_id. First and last grid points may be appended by table Scale_/Time_connect to allow for visualisation using a mean stepwidth. However, the sections of the axis are described separately. Their scale_/time_id is fixed to the primary scale/time_id of the axis by the tables in the SubModule PATCHED_DIMENSIONS. The specifier (tables Scale_/Time_patches) can be used, e.g., to order the sections.

Module DATA_ACCESS

Overview

Information for automatted data access is provided by the module DATA_ACCESS. As the forms of storage can vary widely (e.g., data base, file system, tape library), DATA_ACCESS allows to define the structure of the locally used forms of storage in table ACCESS_STRUCTURE. Here the usage of the four variables storage_name in STORAGE is explained, where storage1_id to storage4_id point to.
For automatted data access it is often advisable to know, in what order the single data points are stored with respect to the five dimensions time, space, and topic (if more than one parameter is stored). To achieve this, in table REC_STRUCTURE dim1_type gives the type of the fastest varying variable, dim2_type of the second fastest and so on. The corresponding dim?_id points to the related record in one of the tables SCALE, TIME, POINT_SET or PARA_ORDER. Here PARA_ORDER is a locally defined table where the order of the topics can be stored, if necessary. If not all dimensions are used, their dim?_type and dim?_id values are set to 0 (zero).
The following examples are to clarify this:

Examples

PIK File System

Among others, a simple application of module DATA_ACCESS is run at PIK: only host name, directory, and file name are stored, using tables DATA_ACCESS, ACCESS_STRUCTURE, and STORAGE. The structure is described in ACCESS_STRUCTURE, while the character strings are in STORAGE. DATA_ACCESS bundles both and keeps it, together with the date of their last modification.

DKRZ Blob Data

At DKRZ, binary large objects (blobs) are stored in a DBMS. The storage fields contain information on the data base and the name of a locally defined data base table, giving more meta data on the specified blob.

Module MODEL_INPUT

Overview

Model output from climate and ecologic calculations depends on the model, the boundary conditions and many parameters. To describe this at least partly in CERA, the CERA Module MODEL_INPUT has been designed. Besides the model and the model type, parameters can be stored with their values and units. However, boundary conditions have to be described verbally in a string field.

Go to top of document.

Pages are optimized for NETSCAPE. For comments and suggestions contact CERA Admin.

Last change: Thu Mar 29 10:28:43 NFT 2001