This information could be represented in the SEDRIS Data Representation Model as an aggregate of <Points> each with a set of <Property Value> components providing the attributed data for the given location. However, considerable storage economy can be gained by exploiting the regular grid structure of the grid locations. For example, if a grid consists of two-dimensional rectangular cells, then the locations of all these cells can be specified by:

1. the location of the center of one reference cell;
2. the row and column directions (orientations);
3. the row and column indices of the reference cell;
4. the number of rows and columns;
5. the length and width of the cells.

The most fundamental of these assumptions is the notion of specifying a location. In a simulation and modeling context, locations are specified as coordinates relative to a chosen spatial reference frame (SRF). The spatial reference frame is a given in many simulation systems; however, the inter-operability objectives of SEDRIS require SEDRIS to support several spatial reference frames. A SEDRIS transmittal explicitly specifies the spatial reference frame within in which locations are defined as part of the transmittal. One objective of the API is to make the transmittal appear independent of the SRF choice (an SRF-free representation). A SEDRIS user can select his preferred SRF, and the SEDRIS API will provide transmittal data relative to the user's SRF. This SRF transparency is possible for individual locations because there are invertible coordinate transformations between any pair of allowed SEDRIS SRFs (for further details, see Part 4, Volume 11: Spatial Reference Model). This SRF transparency breaks down for gridded locations because, in general, the coordinate transformations do not preserve coordinate length. For example, a grid of locations specified by Geodetic latitude and longitude will not be a grid when the locations are mapped onto a coordinate system which preserves distance, and vice versa. (e.g.: One degree of longitude does not have a fixed length in metres). This is an important issue for most METOC databases, which are gridded in latitude/longitude coordinates. In other words, the "griddedness" of a set of locations is not generally preserved after a spatial reference frame transformation. Since "griddedness" is coordinate system dependent, the information in the simple model (1)-(5) above must be supplemented by the identification of the underlying coordinate system:

6. grid spatial reference frame specification.

1. the location of the center of one reference cell;
2. the row and column directions (orientations);

5. the length and width of the cells.

7. signature

8. signature item special characteristics.

Modified items (1')-(8) provide information that is useful or necessary for the representation of a two dimensional uniform grid of data in a SEDRIS Data Representation Model. This model can be generalized in several ways. The grid is called uniform because, as indicated in (5'), each cell is the same size. One generalization is to allow geometric uniformity; that is uniform on a logarithmic scale.

Another generalization is to define a non-uniform grid as one for which the row or column cell-length depends on the row or column index. In other words, an R row by C column grid of locations can be specified by C positions on the row direction axis and R positions on the column directions axis. While this requires more storage information than (5'), we still have the efficiency of axis locations specifying grid locations.

Another generalization of a property grid is to dimensions other than two. For example, air temperature, humidity, etc. can be specified in a three-dimensional volume grid, with elevation as the third dimension. Similarly, measurement in one dimension such as atmospheric soundings measured in altitude only at a specific latitude / longitude.

These generalities can be achieved by defining an <Axis> class in the SEDRIS DRM that contains the characteristics of each axis including (4) and (5'). Thus we have replaced:
(4) the number of row and columns;
(5') the length and width of the cells in grid coordinate system units;
with
(9) an ordered list of axes.

Property tables are (multi-dimensional) arrays of property data. They can be thought of as labeled tabulated data. If we now drop the implicit requirement of spatial grids and spatial axes that are in geographic units, and allow a variety of axis units (metric axes) and even allow enumeration types (nominal axes), then the relaxed requirements can encompass property table data structures. The row (and columns) of the array are either indexed by numeric values or labeled by enumeration values. The tables are not limited to three dimensions. In the next section, we define <Regular Axis>, <Irregular Axis>, and <Enumeration Axis>, and <Interval Axis> to deal with these axis generalizations. In dropping spatial requirements, a property table retains requirements (7) the signature, (8) signature item special characteristics, and (9) an ordered list of (generalized) axes.

The grid signature list allows a set of simple values to be associated with each grid location. However, some grids are vector or data table valued. For example, a 2-D surface grid might have at each grid location table of radar absorptivity indexed by wavelength and incidence angle. If each grid location table uses the same wavelength and incidence angle values then wavelength and angle can be used as two additional (non-spatial) axes to achieve additional storage efficiency. In this case, we have both spatial and non-spatial axes indexing property data which is a function of both grid location and other (non-spatial axis) parameters.

Another table valued case to consider is one in which there are many grid locations sharing a smaller number of distinct tables. In this case, we need only to index the tables and store a table index at each location.

This section has introduced some criteria and requirements for property grids and more generally, property tables. The modified criteria (1'-3, 6-9) motivate the definition of <Axis> classes for axes, <Table Property Description> class for cell signatures, and the <Data Table> class and its specializations such as <Property Grid> and <Property Table>.

As can be seen, a data table requires a signature (7,8), and an ordered list of axes (9). By adding location and spatial reference frame information (1-3,5,6) a data table specializes to a property grid. Using these concepts, the following sections will define the DRM classes used to realize these notions.