|
The SEDRIS Data Representation Model
APPENDIX A - Classes Property Grid |
|---|
An instance of this DRM class is 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.
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.
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.
A DTED <Property Grid> associated to <Areal Features> representing DTED accuracy areas supplemental to the grid.
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>.
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.
Yes.
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>.
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.
No. A <Property Grid Hook Point> may aggregate several <Property Grids>, making the main connection between a <Feature> and a <Property Grid> ambiguous.
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.
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 Grid> rather than <Polygon> instances for terrain to derive the <Property Grid> representation from the <Polygon> representation (see example 3).
| SE_Short_Integer_Positive | spatial_axes_count; | (notes) |
|---|---|---|
| SE_Short_Integer | location_index[]; | (notes) |
| SRM_SRF_Parameters | srf_parameters; | (notes) |
| SE_Boolean | data_present; | (notes) |
This indicates the kind of information represented by the <Data Table>, such as terrain elevation or water characteristics.
This indicates how many axes of the given <Property Grid> instance are spatial axes.
This specifies up to three grid indices that identify the grid cell that contains the location corresponding to that specified by the component <Location 3D> that is attached to the <Property Grid Hook Point> of the given <Property Grid> instance. The identified cell is the attachment cell of the <Property Grid> - it is where the <Location 3D> instance is attached to the <Property Grid>. The default location_index is [0,0,0]. The indices shall specify a valid cell within the <Property Grid> (the indices shall be within the appropriate bounds of the <Property Grid>). Only the first spatial_axes_count entries of location_index are significant.
This specifies the spatial reference frame within which the given <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.
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> could provide.
|