Changes between Version 15 and Version 16 of WKTRaster/SeamlessArchitecture


Ignore:
Timestamp:
Aug 3, 2011, 9:05:53 AM (8 years ago)
Author:
bnordgren
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WKTRaster/SeamlessArchitecture

    v15 v16  
    166166== Result Grid Iteration Engine ==
    167167
    168 One tool with the potential to greatly aid the implementation of any spatial operation which returns a raster is a generic engine which iterates over the result grid. Such a tool will only aid those variants which return a raster (either a mask or a value-containing raster). This tool is strictly an evaluation engine, which iterates over a provided grid to determine which cells are included in (or excluded from) the result, and which produces a value for every cell in the grid.
     168=== Requirements ===
     169
     170One tool with the potential to greatly aid the implementation of any spatial operation which returns a raster is a generic engine which iterates over the result grid. Such a tool will only aid those variants which return a raster (either a mask or a value-containing raster). This tool is strictly an evaluation engine, which iterates over a provided grid to determine which cells are included in (or excluded from) the result, and which produces a value for every cell in the grid.
    169171
    170172Ideally, the iteration engine itself should not care about the information type of the inputs. For each output raster cell, a two input engine needs to determine:
     
    190192 * Value computation (what is the value to store in the result?)
    191193
     194=== Spatial collection design ===
     195
    192196Examination of the above requirements suggests a single interface could represent both a "Spatial Only" and a "Spatial Value" information type, and could also represent both inputs as well as the output. The main functions of this interface would be to provide access to two methods: one which determines whether a point is included in the collection of geometric objects; and another which returns a value associated with a point. The following UML diagram provides a design which fits these requirements:
    193197
    194198[[Image(spatialcollection.png)]]
    195199
    196 Using this design, the raster iteration engine would be called with different arguments in order to handle different combinations of input arguments, spatial operations, and value computations. Each extension point represents a well-encapsulated, reusable module which can be combined in many ways with other extension points. There is only one grid iteration engine (for the two input case), and it contains only the basic iteration logic; as the logic for other necessary pieces has been factored out to separate modules.
     200The `SpatialCollection` interface represents either an ''intelligent'' collection of spatial objects or a ''very limited profile'' of a coverage. It does not actually provide access to the individual members of the collection, which may have different data types. Instead, it provides a consistent means to ''evaluate'' the collection at a specified point as well as a means to determine whether a location is inside or outside of the collection. This fulfills the basic requirements outlined in the previous section.
     201
     202The diagram illustrates the fact that the two methods defined on the interface could be encapsulated in separate objects, showing that `SpatialCollection` is associated with the interfaces `Evaluator` and `Includes`. This arrangement provides the flexibility to handle dramatically different data types (e.g., raster vs. vector) and also acknowledges that the same collection could possibly be interpreted in many different ways.
     203
     204The raster data type provides an additional means of addressing the data. In addition to the real world position, data may also be addressed by the coordinates on the grid defined by the raster. As shown in the diagram, this adds two methods to the main interface, as well as a second version of the `Evaluator` and `Includes` interfaces which support this new method of assess.
     205
     206It is possible to extend this concept with a ''virtual'' collection which represents the result of an operation on two or more input collections. This is shown in the following UML diagram.
     207
     208[[Image(twoelementcollections.png)]]
     209
     210Two new interfaces are defined to accomodate this notion of a collection which is derived somehow from two other collections. `TwoInputCollection` adds a reference to each of the inputs to the `SpatialCollection` interface. Likewise, `TwoInputRasterCollection` adds these references to the `RasterSpatialCollection` interface. The specifics of ''how'' the resultant collection is derived from the inputs is determined by the implementation of the `Evaluator` and `Includes` interfaces.
     211
     212This arrangement allows complete control over both the spatial result and the value result of an operation. It also allows the result to be defined in terms of two inputs, both represented as `SpatialCollection` types; allowing for seamless treatment of both raster and vector types.
     213
     214One constraint which must be observed throughout, is that the choice of implementations for `Evaluator` and `Includes` must be consistent with the type of data actually represented by the set. For instance, the `Includes` implementation for a raster is different than the `Includes` implementation for a vector. Likewise, an `Includes` implementation for a two input collection may be a spatial operation on the two inputs.
     215
     216=== Single collection implementations ===
     217
     218Shown below are a preliminary set of implementations for `Evaluator` and `Includes` for the case of a single raster or a single collection.
     219
     220[[Image(singlecollection.png)]]
     221
     222=== Two input collection implementations ===
     223
     224Shown below are a preliminary set of implementations for `Evaluator` and `Includes` for the case of two-input collections.
     225
     226[[Image(twoelementimplementation.png)]]
     227
     228=== Summary ===
     229
     230Using this design, the raster iteration engine would evaluate a `TwoInputCollection` on a regular grid, returning the resultant raster. The logic to compute the actual grid values is encapsulated in the `TwoInputCollection`. The design exposes four interfaces which serve as extension points. Each extension point represents a well-encapsulated, reusable module which can be combined in many ways with other extension points. There is only one grid iteration engine (for the two input case), and it contains only the basic iteration logic; as the logic for other necessary pieces has been factored out to separate modules.
    197231
    198232== See also ==