Data Tables Technical Guide
Section 4 - PUTTING IT ALL TOGETHER

4.1 Overview
.

This section presents several examples that use the DRM classes discussed

.
4.2 <Property Table> Examples
.
4.2.1 <Property Table>: Backscatter Table Example
.

Consider the following 2-dimensional table of electromagnetic backscatter properties for some material. One axis, representing angle of incidence, is a regularly-spaced numeric axis, starting at 15 degrees and incrementing by 15 degrees for a total of 6 tick marks. The other axis specifies 5 electromagnetic bands.

15 30 45 60 75 90
RF 300 290 240 207 198 170
microwave 160 230 180 167 158 130
infrared 165 152 78 22 8 1.5
visible 179 122 45 11 6 1
ultraviolet 200 90 40 9 4 0.1

The ECC for this data set is ECC_ELECTROMAGNETIC_MATERIAL_PROPERTY_SET, while the EACs for the backscatter data and the two axes are EAC_SURFACE_BACKSCATTER, EAC_INCIDENCE_ELEV_ANGLE_LOCAL, and EAC_EM_BAND.

Mapping this to the DRM, we have a <Property Table> with a <Classification Data> identifying it as a ECC_ELECTROMAGNETIC_MATERIAL_PROPERTY_SET, together with two <Axis> components and a <Table Property Description> component.

Since EAC_EM_BAND is an enumerated EA, the corresponding axis is represented as an <Enumeration Axis>, wherein the field values are 

axis_type          = { SE_ELEM_CODE_TYP_ATTRIBUTE, { EAC_EM_BAND }
value_unit         = EUC_UNITLESS
value_scale        = ESC_UNI
axis_value_count   = 5
axis_value_array[] = { EEC_EMBAND_RADIO_FREQUENCY,
                       EEC_EMBAND_MICROWAVE,
                       EEC_EMBAND_INFRARED,
                       EEC_EMBAND_VISIBLE,
                       EEC_EMBAND_ULTRAVIOLET
                     }

On the other hand, EAC_INCIDENCE_ELEV_ANGLE_LOCAL is a numeric EA and has regular tick mark spacing for the axis in this example, so it is represented as a <Regular Axis>, wherein the field values are 

axis_type          = { SE_ELEM_CODE_TYP_ATTRIBUTE,
                       { EAC_INCIDENCE_ELEV_ANGLE_LOCAL }
value_unit         = EUC_DEGREE_ARC
value_scale        = ESC_UNI
axis_value_count   = 6
interpolation_type = SE_INTERPOLATION_TYP_LINEAR
first_value        = { SE_PDV_INTEGER, 15 }
spacing            = { SE_PDV_INTEGER, 15 }
spacing_type       = SE_SPACING_TYP_ARITHMETIC
axis_alignment     = SE_AXIS_ALNMNT_NONE

Since interpolation makes sense for the EAC_INCIDENCE_ELEV_ANGLE_LOCAL axis, linear interpolation is selected as an example. Note that the <Axis> is not aligned, because it is not a spatial axis.

Now for the actual backscatter data itself, which is modelled via a <Table Property Description> with the following fields, completing the definition of the structure of the cells in the <Property Table>. 

meaning     = { SE_ELEM_CODE_TYP_ATTRIBUTE,
                { EAC_SURFACE_BACKSCATTER },
value_unit  = EUC_DB
value_scale = ESC_UNI
value_type  = SE_PDV_FLOAT

Suppose that we have the following additional information about the backscatter values.

  • Minimum value: 0.0 dB
  • Maximum value: 400.0 dB
  • Tolerance: 0.1 dB
  • Significant digits: 4

This information can be represented by adding four <Property Characteristic> components to the <Table Property Description> component, wherein the field values of each <Property Characteristic> correspond to one of the rows in the following table.

meaning characteristic_value
EMC_MINIMUM_VALUE SE_PDV_FLOAT 0.0
EMC_MAXIMUM_VALUE SE_PDV_FLOAT 400.0
EMC_TOLERANCE SE_PDV_FLOAT 0.1
EMC_SIGNIFICANT_DIGITS SE_PDV_SHORT_INTEGER 4

Note that the actual backscatter values do not appear explicitly in the DRM representation; instead, they are placed in the <Data Table> by the various SE_PutDataTable() functions of the SEDRIS API, and can then be retrieved via the various SE_GetDataTable() functions.

.
4.2.2 <Property Table>: Emissivity Table Example
.

Consider the following emissivity table corresponding to the same material as that being modelled in the previous example.

15 30 45 60 75 90
RF .32 .97 .38 207 .98 .70
microwave .24 .93 .48 167 .58 .30
infrared .56 .59 .78 22 .8 .5
visible .73 .58 .45 .51 .6 .1
ultraviolet .51 .43 .47 .19 .14 0.1

Since the axes of this table are identical to those in the previous example, and since the data herein describes further EM properties of the same material, we can easily represent the two tables as a single <Property Table> rather than representing each separately, just by adding a second <Table Property Description> for the emissivity property (and subsequently using the API to add the corresponding element to each cell) to the existing <Property Table>, thus giving it a two "element" signature. NOTE: This can be done while creating the <Property Table> instance initially, but cannot currently be done in update mode; that is, in update mode the signature of a <Data Table> for which the cell data has already been created cannot be modified.

The difference between this <Property Table> and that in the preceding example is that a second <Table Property Description> with the field values shown below would be added before the cell data was created. 

meaning     = { SE_ELEM_CODE_TYP_ATTRIBUTE, { EAC_EMISSIVITY },
value_unit  = EUC_UNITLESS
value_scale = ESC_UNI
value_type  = SE_PDV_FLOAT

.
4.3 <Property Grid> Example
.

.
4.4 Nested <Property Grid> Example
.

In this section, we will consider a grid of ocean volume properties. The properties of interest are:

One would expect a simple 3-dimensional <Property Grid> (with longitude, latitude, and depth <Axis> components, for example) to be an adequate tool for this problem, and indeed it works well for shallow volumes in deep ocean areas and deep volumes over flat bottom areas. However, cases in which the volume intersects an irregular ocean bottom - that is, in which part of the volume lies outside the scope of the problem, since it isn't water - present a difficulty.

Although one possible solution is to provide a <Property Characteristic> for EMC_NOT_APPLICABLE, this approach has its own problems, since the properties of interest in this example vary rapidly near the surface but slowly in the depths. For reasonable data resolution, this kind of data requires an <Irregular Axis> that has small intervals between tick marks near the surface, but large intervals between tick marks near the bottom. If such an axis is used, rather coarse chunks will be excluded near the ocean bottom. A further consideration is that computational models that use this kind of data are sensitive to boundary conditions such as the values at the bottom surface.

A solution to this problem is to use a 2-dimensional (latitude, longitude) <Property Grid> to model the ocean surface. Each grid cell has a reference to a 1-dimensional depth grid, which ends at a bottom depth appropriate for its (latitude, longitude) location. This gives us a collection of depth grids "nested" in the surface grid.

Return to:Top of this Page, Table of Contents

Last updated: May 15, 2003 Copyright © 2003 SEDRIS™