Class Name: Property Grid

Superclass - <Data Table>

Subclasses

Definition

A <Data Table> that has at least one (1) but not more than three (3) spatial axes, which always appear before any other <Axes> 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' <Axes> 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 <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.

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:

• 6

Secondary Pages in DRM Diagram:

Example

1. A DTED <Property Grid> associated to <Areal Features> representing DTED accuracy areas supplemental to the grid.
2. Consider a <Property Grid> 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>, attaching it to the hierarchy with a <Property Grid Hook Point>, as usual, with the following structure.

      <Property Grid>
             <>
              |
              |- <Classification Data>
              |  tag = ECC_TERRAIN
              |
              |
              |- instances of <Axis> with spatial EAs as meanings
              |
              |- <Table Property Description>
                 EAC_SURFACE_ELEVATION
   

   The spatial <Axes> define the extents and the spacing of the <Property Grid>. The data provider has the option of providing < Property Characteristic> components for the <Table Property Description> 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 <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>.

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>? 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?

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

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 provides 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

• <<Index Codes within Tables>>
• <<Axis Type Restrictions>>
• <<Non Crossing Associations>>

Associated with (two-way)

• zero or more <Feature> instances

Composed of (two-way)(inherited)

• one <Classification Data> instance (notes)
• zero or more {ordered} <Image Mapping Function> instances

Composed of (two-way)

• one or more {ordered} <Axis> instances
• zero or more {ordered} <Data Table> instances
• zero or more <Grid Overlap> instances
• one or more {ordered} <Table Property Description> instances

Composed of (two-way metadata)(inherited)

• zero or one <Access> instance
• zero or more <Browse Media> instances
• zero or one <Citation> instance
• zero or more <Cross Reference> instances
• zero or one <Data Quality> instance
• zero or one <Description> instance
• zero or one <Keywords> instance
• zero or one <Point Of Contact> instance
• zero or one <Time Constraints Data> instance

Component of (two-way)(inherited)

• zero or one <Data Table Library> instance
• zero or more <Property Grid> instances

Component of (two-way)

• zero or more <Property Grid Hook Point> instances

Inherited Field Elements

Field Elements

Notes

Composed of Notes

Classification_Data

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

Fields Notes

spatial_axes_count

 indicates how many axes of the <Property Grid> are
 spatial axes.

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> instance is attached to the Grid.  The
 default location_index is [0,0,0].  The indices shall specify a valid
 cell within the Grid (the indices shall be within the appropriate
 bounds of the Grid).  Only the first spatial_axes_count of 3 are
 significant.

srf_parameters

 Specifies the spatial reference frame within which the <Property Grid>
 instance is defined, rather than attempting to depend on the
 spatial reference frame of the context in which the instance appears.

 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.

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 <Axis>
 information, the <Grid Overlap> information (if any), the
 <Table Property Descriptions>, possibly including
 <Property Characteristics> (to define minimum and maximum values),
 and so on. This <Property Grid> provides everything a populated
 <Property Grid> would provide *except* for cell values.

 The default value for this field is SE_TRUE.