The SEDRIS Data Representation Model
APPENDIX A - Classes
Property Grid

Class Name: Property Grid

Superclass - <Data Table>

Subclasses

This DRM class is concrete and has no subclasses.

Definition

An instance of this DRM class is a <Data Table> instance that has at least one (1) but not more than three (3) spatial axes, which always appear before any other <Axis> instances in its ordered <Axis> list.

A spatial axis is an <Axis> instance 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> shall match the spatial reference frame exactly, using using a consistent specification (e.g., the same ORM, direction vector and (possibly scaled) units.

  1. The "spatial" <Axis> instances of a <Property Grid> shall always be the first members of the ordered set of <Axis> components. The spatial_axes_count field indicates how many of the <Axis> instances 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.

  2. There are no other ordering rules for spatial <Axis> instances. If a producer has a choice, it is a good idea to order spatial <Axis> components in the same way as the spatial reference frame components, but as mentioned in point 1), this is not always possible, so consumers cannot make assumptions about the ordering apart from those stated above.

Primary Page in DRM Diagram:

Secondary Pages in DRM Diagram:

Example

  1. A DTED <Property Grid> associated to <Areal Feature> instances representing DTED accuracy areas supplemental to the grid.

  2. Consider a <Property Grid> instance classified as ECC_WATER_BODY_TEMPERATURE_PROPERTY_SET for an ocean volume. Ocean temperature "features", such as warm / cold currents, fronts, and eddies, 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> instance, attaching it to the hierarchy with a <Property Grid Hook Point> instance, as usual, with the following structure.

    Property Grid, Example 3

    The spatial <Axis> instances define the extents and the spacing of the <Property Grid> instance. The data provider has the option of providing <Property Characteristic> components for the <Table Property Description> instance to supply the minimum and maximum elevation values.

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.

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 <Axis> instances 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 (such as the location of the terrain surface) or a parametric formula (such as the standard atmosphere model) to convert their values into a <Location> instance in the SEDRIS spatial reference frame of the given <Property Grid> instance.

Why is a <Property Table> permitted to aggregate other <Data Tables>?

This mechanism allows a <Property Grid> cell data element to specify an index into the set of ordered <Data Table> components, so that any component <Data Table> can be "re-used" by many data cells. See <<Index Codes within Tables>> for further details.

Why is a <Property Grid> allowed to associate directly with a <Feature Representation>? Couldn't the same functionality be achieved by associating the <Feature Representation> with a <Property Grid Hook Point>?

No. A <Property Grid Hook Point> may aggregate several <Property Grids>, making the main connection between a <Feature Representation> and a <Property Grid> ambiguous.

What if a cell in a <Property Grid> is related to several <Feature Representations> simultaneously?

This is easily handled by having the cell index to a component (nested) <Data Table> of related <Feature Representation> IDs ( EAC_NUMERIC_OBJECT_IDENTIFIER). Such component <Data Tables> of related <Feature Representations> shall be classified as ECC_RELATED_OBJECT_SET.

What is the point of having an "empty" <Property Grid>, that is, with data_present == SE_FALSE?

Because it provides an "outline" or "template" of the <Property Grid> information. It provides the size, orientation, spacing, and so on of the <Property Grid> instance - just without any cell values.

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

Constraints

Associated to (one-way)

Associated by (one-way)

Composed of (two-way) (inherited)

Composed of (two-way)

Composed of (two-way metadata) (inherited)

Component of (two-way) (inherited)

Component of (two-way)

Inherited Field Elements

This class has no inherited field elements.

Field Elements

SE_Short_Integer_Positive spatial_axes_count; (notes)
SE_Short_Integer location_index[]; (notes)
SE_SRF_Info srf_info; (notes)
SE_Boolean data_present; (notes)

Notes

Associated to Notes


Feature_Representation

 An association between a <Property Grid> instance and a
 <Feature Representation> instance indicates that the
 environmental object(s) represented by the
 <Feature Representation> instance and the <Property Grid> instance
 (or some specific cell data within that <Property Grid> instance)
 have the semantic relationship indicated by the
 <Base Association Data> instance on the association relationship.
 Each associated <Property Grid> instance will indicate whether the
 entire <Property Grid> instance or only some specific cell data
 within it is participating in the relationship in question.

Associated from Notes


Feature_Representation

 An association between a <Property Grid> instance and a
 <Feature Representation> instance indicates that the
 environmental object(s) represented by the
 <Feature Representation> instance and the <Property Grid> instance
 (or some specific cell data within that <Property Grid> instance)
 have the semantic relationship indicated by the
 <Base Association Data> instance on the association relationship.
 Each associated <Property Grid> instance will indicate whether the
 entire <Property Grid> instance or only some specific cell data
 within it is participating in the relationship in question.

Composed of Notes


Classification_Data

 This indicates the kind of information represented by the
 <Data Table>, such as terrain elevation or
 water characteristics.

Fields Notes


spatial_axes_count

 The spatial_axes_count field specifies how many axes of the
 given <Property Grid> instance are spatial axes.

location_index

 This specifies up to three grid indices that identify the grid cell
 that contains the location corresponding to that specified by the
 <Location 3D> component of the <Property Grid Hook Point> aggregate
 of the given <Property Grid> instance.

 The identified cell is the attachment cell of the given <Property Grid>
 instance; it is where the <Location 3D> instance is attached to the
 <Property Grid> instance.

 The location_index shall specify a valid cell within the given
 <Property Grid> instance; that is, the indices shall be within
 the appropriate bounds of the <Property Grid> instance.  Only
 the first spatial_axes_count entries of location_index are
 significant.

srf_info

 This specifies the SRF within which the given <Property Grid>
 instance is defined, rather than attempting to depend on the
 SRF of the context in which the instance appears.

 The "griddedness" of spatial positions is dependent on the properties
 of the SRF. Coordinate conversions and transformations are not,
 in general, linear, so that a set of points that form a regular
 array of positions in one SRF may not be regular in
 another SRF.  Therefore, in order to preserve
 "griddedness", a <Property Grid> specifies a SRF in
 which the data positions form a grid.

data_present

 If data_present = SE_TRUE (the default), the given <Property Grid>
 instance contains cell values that can be extracted via the
 appropriate Level 0 API calls.

 Otherwise, if data_present = SE_FALSE, the given <Property Grid>
 instance does not contain any cell values, although it may provide
 everything else that a populated <Property Grid> instance could
 provide.

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

Last updated: July 16, 2004 Copyright © 2004 SEDRIS