Class Name: Property Grid

Superclass - Data Table

Definition

A subclass of the Data Table abstract class. An N-dimensional collection of cells that has at least one (1) but not more than three (3) spatial axes.

Primary Page in DRM Diagram:

Example

  1. A DTED Property Grid may be associated to Areal Features representing DTED accuracy areas supplemental to the grid.
  2. Consider a Property Grid of Ocean Volume Temperature data. Ocean Volume temperature "features", such as warm/cold currents, fronts, eddies, etc. are associated to specific cells of the Property Grid.
  3. Consider a transmittal provided by a data producer whose format uses polygons rather than grids to represent terrain, where the polygons define a 'default' post spacing. To provide this 'default' post spacing in the transmittal, the data provider would provide an 'empty' Property Grid, attaching it to the hierarchy with a Property Grid Hook Point, as usual. The spatial Axes would define the extents and the spacing of the Property Grid. The data_table_type of the Property Grid would be EDCS_CC_TERRAIN. Minimum and maximum elevation values could be provided with Property Characteristics components on the Property Values of the grid.

FAQs

Since a Property Grid is a sub-class of Data Table, and the Data Table Library is composed of Data Tables, doesn't that mean that a Property Grid can be a component of a Data Table Library?
Yes.

Why does a Property Grid have its own spatial reference frame, independent of the Environment Root?
The "griddedness" of spatial positions is dependent on the properties of the spatial reference frame. Coordinate conversions and transformations are not, in general, linear, so that a set of points that form a regular array of positions in one spatial reference frame may not be regular in another spatial reference frame. Therefore, in order to preserve "griddedness", a Property Grid specifies a spatial reference frame in which the data positions form a grid.

What are 'spatial' axes?
A spatial axis is an Axis object that describes sampling along one of the components of the spatial reference frame of the Property Grid; hence it is directly useful for locating the sample values in space. To qualify as spatial, the Axis must match the spatial reference frame exactly, using using a consistent specification (e.g., the same ORM/ERM, direction vector and (possibly scaled) physical units.

What are examples of spatial axes?
In the Geodetic spatial reference frame, Latitude, Longitude, and Height above the reference surface (e.g., vertical datum) define spatial axes. In SEDRIS, depth below datum is also accepted as a spatial axis because it is related to height by a simple sign reversal. In an AUTM spatial reference frame, Northing, Easting, and Height define spatial axes -- but latitude and longitude are not, because they are not components of the AUTM spatial reference frame.

What are examples of non-spatial axes?
Of course, any Axis that has no spatial meaning is non-spatial, for example, month, material index, density. There are also Axes that seem to have spatial meaning but are not 'spatial' to SEDRIS, for example, atmospheric pressure height, height above or below terrain surface, azimuth. These are non-spatial to SEDRIS because they require either additional information (e.g. the location of the terrain surface) or a parametric formula (e.g. the standard atmosphere model) to convert their values into a Location in the SEDRIS spatial reference frame of the Property Grid.

Which Axes of a Property Grid can be 'spatial'?
The 'spatial' Axes of a Property Grid must always be the first members of the ordered set of Axis components. The spatial_axes_count field indicates how many of the Axes are 'spatial'. Note: because the Axis ordering also determines the 'scanning' order when data is retrieved from a Data Table, placing the spatial axes first imposes some limitations on the way data can be scanned, and may require reordering either by the preparer or the consumer to achieve a scanning that is more 'natural' to them.

Are there other ordering rules for spatial Axes?
No. If a producer has a choice, it is a good idea to order spatial Axes in the same way as the spatial reference frame components, as this is likely to reduce confusion in the consumer, but this ordering is not mandatory and consumer code must be prepared to accept other orderings.

Why is a Property Grid allowed to associate directly with a Feature? Couldn't the same functionality be achieved by associating the Feature with a Property Grid Hook Point?
No. A Property Grid Hook Point may aggregate several Property Grids, making the main connection between a Feature and a Property Grid ambiguous.

What if a cell in a Property Grid is related to several Features simultaneously?
Data Table of related Feature IDs ( EDCS_AC_FEATURE_IDENTIFICATION_NUMBER). Such component Data Tables of related Features must be of data_table_type EDCS_CC_RELATED_FEATURES_TABLE.

What's the point of having an 'empty' Property Grid, i.e., with data_present == SE_FALSE?
Because it gives you an 'outline' or 'template' of the Property Grid information. It gives you the size, orientation, spacing, etc. of the Property Grid - just without any cell values.

This makes it possible, for instance, for a consumer who requires Property Grids rather than Polygons for terrain to derive the Property Grid representation from the Polygon representation (see example 3).

Constraints

Associated with (two-way)

Composed of (one-way)(inherited)

Composed of (one-way)

Composed of (one-way metadata)(inherited)

Component of (one-way)(inherited)

Component of (two-way)(inherited)

Component of (two-way)

Inherited Field Elements

EDCS_CC_ID data_table_type; (notes)

Field Elements

SE_PINT16 spatial_axes_count; (notes)
SE_INT16 location_index[]; (notes)
SE_SRF_PARAMETERS srf_params;
SE_BOOLEAN data_present; (notes)

Notes

Fields Notes

data_table_type

 identifies the type of the table
 (e.g.: elevation grid (EDCS_CC_TERRAIN_ELEVATION),
        bathymetry (EDCS_CC_OCEAN_FLOOR_BATHYMETRY),
        underwater sound speed
        (EDCS_CC_OCEAN_WATER_CHARACTERISTICS_SOUND_SPEED), etc.)

spatial_axes_count

 indicates how many axes of the <Property Grid> are
 spatial axes.  These are the first n_spatial_axes axes of the Grid.
 Spatial axes must precede all non-spatial axes by convention.

location_index

 up to three grid indices that identify the Grid cell that contains
 the same location as the location defined by the component
 <Location 3D> that is attached to the Hook Point of the Grid.
 The identified cell is the attachment cell of the Grid - it
 is where the Location 3D object is attached to the Grid.  The
 default location_index is [0,0,0].  The indices must specify a valid
 cell within the Grid (the indices must be within the appropriate
 bounds of the Grid).  Only the first n_spatial_axes of 3 are
 significant.

data_present

 If SE_TRUE, then the <Property Grid> contains cell values that can be
 extracted via the Level 0 Read API calls SE_GetDataTable(),
 SE_GetPackedDataTable(), and SE_GetElementOfDataTable().

 If SE_FALSE, then the <Property Grid> does not contain any cell values.
 Calls to the Level 0 Read API to retrieve cell values will fail for this
 Property Grid.  This Property Grid exists to provide the <Axes>
 information, the <Grid Overlaps> information (if any), the <Table
 Property Descriptions>, possibly including <Property Characteristics> (to
 define minimum and maximum values), etc.  This <Property Grid> provides
 everything a populated Property Grid would provide *except* for cell
 values.

 The default value for this field is SE_TRUE.

Prev: Property Description. Next: Property Grid Hook Point. Up:Index.