|
The SEDRIS Data Representation Model
APPENDIX A - Classes Grid Overlap |
|---|
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 five of the following conditions hold:
When such an ambiguity occurs, the <Grid Overlap> instance for A and the <Grid Overlap> instance for B shall indicate how the data provider intended the consumer to calculate the cell values at each overlapping cell corresponding to the applicable <Table Property Description> instances.
Resolution only occurs within an overlay group. An overlay group is a set of <Property Grid> instances that are identified by the overlay_group fields of their respective <Grid Overlap> components as requiring common processing of ambiguity. Within an overlay group, the priority fields of their respective <Grid Overlap> components determine the sequence in which the <Property Grid> instance cell data is processed. Priorities within an overlay group need not be consecutive, but they shall be unique. The operation field specifies how the cell data interact with each other.
Each overlay group shall have exactly one <Grid Overlap> instance with priority = 0. The operation field value for priority = 0 shall be SE_GROVLOP_BASE.
To resolve an ambiguity, identify the corresponding overlay group and process as follows:
STEP 1:
Start with priority = 0. 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 higher priority field value. 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.
A low resolution <Property Grid> instance A covers a large area, and contains smaller (but higher resolution) grids B, C, and D. The scheme specified for the <Grid Overlap> components of A, B, C, and D is:
| <Property Grid> | overlay_group | priority | operation |
| A | 10 | 0 | SE_GROVLOP_BASE |
| B | 10 | 1 | SE_GROVLOP_REPLACE |
| A | 20 | 0 | SE_GROVLOP_BASE |
| C | 20 | 1 | SE_GROVLOP_REPLACE |
| D | 20 | 2 | SE_GROVLOP_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:
B should not intersect either C or D as this scheme will not provide ambiguity resolution.
A seamount is modelled as a <Property Grid> instance M of elevation offsets above the underlying bathymetry in <Property Grid> instances A and B, where A and B overlap. The scheme specified by the <Grid Overlap> components of A, B, M is:
| <Property Grid> | overlay_group | priority | operation |
| A | 1 | 0 | SE_GROVLOP_BASE |
| B | 1 | 1 | SE_GROVLOP_MEAN |
| M | 1 | 999 | SE_GROVLOP_ADD |
| B | 2 | 0 | SE_GROVLOP_BASE |
| M | 2 | 999 | SE_GROVLOP_ADD |
For overlay_group 1, the following is specified:
For overlay_group 2, in intersection B & M and outside of A, add M offsets to B bathymetry values.
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.
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.
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 cannot be resolved using a single group.
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.
The overlay_group field specifies the overlay group within which the resolution process is to occur.
The priority field specifies a priority that is meaningful within the specified overlay_group.
The operation field specifies the operation to be performed on the data during the resolution process.
|