Changes between Version 15 and Version 16 of WKTRaster/SeamlessArchitecture

Timestamp:

Aug 3, 2011, 9:05:53 AM (13 years ago)

Author:

bnordgren

Comment:

—

WKTRaster/SeamlessArchitecture

@@ -166 +166 @@
 == Result Grid Iteration Engine ==
 
-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.
+=== Requirements ===
+
+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. 
 
 Ideally, 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:
@@ -190 +192 @@
  * Value computation (what is the value to store in the result?)
 
+=== Spatial collection design ===
+
 Examination 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:
 
 [[Image(spatialcollection.png)]]
 
-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.
+The `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.
+
+The 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. 
+
+The 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.
+
+It 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.
+
+[[Image(twoelementcollections.png)]]
+
+Two 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. 
+
+This 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. 
+
+One 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.
+
+=== Single collection implementations ===
+
+Shown below are a preliminary set of implementations for `Evaluator` and `Includes` for the case of a single raster or a single collection.
+
+[[Image(singlecollection.png)]]
+
+=== Two input collection implementations ===
+
+Shown below are a preliminary set of implementations for `Evaluator` and `Includes` for the case of two-input collections.
+
+[[Image(twoelementimplementation.png)]]
+
+=== Summary ===
+
+Using 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.
 
 == See also ==