The SEDRIS Data Representation Model
APPENDIX A - Classes
Grid Overlap

Class Name: Grid Overlap

Superclass - <SEDRIS Abstract Base>

Subclasses

This DRM class is concrete and has no subclasses.

Definition

An instance of this DRM class specifies how the data provider intended the consumer to resolve data ambiguity at a location falling within a grid cell for two or more <Property Grid> instances, such that the ambiguity cannot be resolved by other means.

An ambiguity occurs at a location L lying within two <Property Grid> instances A and B if all four of the following conditions hold:

  1. A and B are not disjoint due to any higher-level organizing structure in the transmittal, such as membership under different branches of an <Alternate Hierarchy Related Geometry> instance, or disjoint <Time Constraints Data> instances.

  2. A and B have matching <Classification Data> components.

  3. At least one <Table Property Description> component of A has a meaning matching a <Table Property Description> component of B.

  4. Both A and B actually have data for those matching <Table Property Description> components at L.

When such an ambiguity occurs, <Grid Overlap> instance(s) indicate how the data provider intended the consumer to calculate the intended value of the <Table Property Description> instances at each such location.

When <Grid Overlap> instances are required and are present, resolution only occurs within an overlay group. The resolution process is performed on data from cells of the <Property Grid> instances that contain a given location. To resolve the ambiguity, choose the first overlay group that includes all relevant grids and process as follows:

STEP 1:

Start with priority = 0. Each overlay group shall have exactly one <Grid Overlap> instance with priority = 0. The <Property Grid> instance for this <Grid Overlap> instance shall overlap the other <Property Grid> instances in the given overlay group. The operation field value for priority = 0 shall be SE_GRD_OVRLP_OP_BASE.

Extract cell data from the <Property Grid> instance that has this <Grid Overlap> instance as a component; this becomes the current data.

STEP 2:

Find the next lowest priority field value. Priorities within an overlay group need not be consecutive, but they shall be unique. Extract the cell data from the <Property Grid> instance that has this <Grid Overlap> instance as a component. Operate on this and the current data according to the operation field of the <Grid Overlap> instance. The result of applying the operations specified by the operation field becomes the current data for the next step.

STEP 3:

Look for next higher priority. If found, go to step 2. Otherwise use the current data.

Primary Page in DRM Diagram:

Secondary Pages in DRM Diagram:

This class appears on only one page of the DRM class diagram.

Example

  1. Low resolution grid A covers a large area, and contains smaller (but higher resolution) grids B, C, and D. The scheme specified for the <Grid Overlap> instances is:

    <Property Grid> overlay_group priority operation
    A 10 0 SE_GRD_OVRLP_OP_BASE
    B 10 1 SE_GRD_OVRLP_OP_REPLACE
    A 20 0 SE_GRD_OVRLP_OP_BASE
    C 20 1 SE_GRD_OVRLP_OP_REPLACE
    D 20 2 SE_GRD_OVRLP_OP_REPLACE

    In the intersection of A & B where the overlay_group is 10, B data overrides A.

    For overlay_group 20, the following is specified:

    1. In intersection A & C, C data overrides A.
    2. In intersection A & D, D data overrides A.
    3. In intersection A & C & D, D data overrides others.

    B should not intersect either C or D as this scheme will not provide ambiguity resolution.

  2. A seamount is modelled as a grid M of elevation offsets above the underlying bathymetry in grids A and B. The scheme specified by the <Grid Overlap> instances is:

    <Property Grid> overlay_group priority operation
    A 1 0 SE_GRD_OVRLP_OP_BASE
    B 1 1 SE_GRD_OVRLP_OP_MEAN
    M 1 999 SE_GRD_OVRLP_OP_ADD
    B 2 0 SE_GRD_OVRLP_OP_BASE
    M 2 999 SE_GRD_OVRLP_OP_ADD

    For overlay_group 1, the following is specified:

    1. In intersection A & M and outside of B, add M offsets to A bathymetry values.
    2. In intersection B & M and outside of A, add M offsets to B bathymetry values.
    3. In intersection A & B, average A and B bathymetry values.
    4. In intersection A & B & M, first average A and B bathymetry values, and then add offsets from M to the average.

    For overlay_group 2, in intersection B & M and outside of A, add M offsets to B bathymetry values.

FAQs

Are there real datasets that require this capability?

There are numerous numerical models in the atmosphere and ocean community that start by computing a coarse grid over a large area, then use this grid as boundary and initial conditions for calculating a more finely-sampled grid over a smaller area. In many cases, the process is repeated several times, producing a "nest" of grids that all cover the same area. It is also possible to implement variable-resolution grids in the DRM by constructing a base grid covering a large region at a coarse sample spacing suitable for describing "ambient" conditions, and then to inset finer grids at locations with detailed features of interest.

When are <Grid Overlap> instances required, and when are they optional?

A <Grid Overlap> instance is required whenever multiple <Property Grid> instances contain values for equivalent <Table Property Description> instances at the same location within the simulated environment.

If their absence will not cause ambiguity in the transmittal, <Grid Overlap> instances are not needed. If the <Property Grid> instances are explicitly disjoint due to some higher organizing structure, such as mutually exclusive branches of an <Aggregate Geometry> instance, there is no ambiguity and a <Grid Overlap> instance is not required. If <Property Grid> instances covering the same location have no equivalent <Table Property Description> instances, they do not create ambiguity and do not need a <Grid Overlap> instance.

Can a <Property Grid> instance have more than one <Grid Overlap> instance?

Yes. A base <Property Grid> instance could have disjoint overlaps with several different "insets". Although it is usually possible to choose priority levels within a single group to resolve the ambiguities, use of multiple groups may make the situation clearer and easier for the consumer. There are also less common situations of multiple overlaps that can't be resolved using a single group.

What happens when cells of overlapping grids are not spatially aligned with each other?

The operation rules described in the definition apply at a single point location, so alignment of cells is not strictly required. However, it is likely that combining values from misaligned cells will not produce a sensible value. As basic guidance, preparers of transmittals should avoid this situation when possible, since it is confusing to consumers. Grids should be resampled before preparing the transmittal so as to achieve alignment whenever possible.

Constraints

Component of (two-way)

Inherited Field Elements

This class has no inherited field elements.

Field Elements

SE_Short_Integer_Positive overlay_group; (notes)
SE_Short_Integer_Unsigned priority; (notes)
SE_Grid_Overlap_Operator operation; (notes)

Notes

Fields Notes

overlay_group

The overlay_group field specifies the overlay group within which the resolution process is to occur.

priority

The priority field specifies a priority that is meaningful within the specified overlay_group.

operation

The operation field specifies the operation to be performed on the data during the resolution process.

Prev: Geometry Volume. Next: HAEC 3D Location. Up:Index.

Last updated: August 23, 2005 Copyright © 2005 SEDRIS™