Context Navigation

Changes between Version 6 and Version 7 of WKTRaster/SeamlessArchitecture

Timestamp:: Jul 18, 2011, 1:34:13 PM (13 years ago)
Author:: bnordgren
Comment:: —

Legend:

: Unmodified
: Added
: Removed
: Modified

WKTRaster/SeamlessArchitecture

-              v6
+              v7
 To handle raster and vector data seamlessly, it is first necessary to declare the types of information potentially handled by spatial operations. It is then necessary to define how each type of object may be used to communicate that information. The two categories of information addressed by this architecture are:
 # Purely spatial information
 # Spatial information with associated numeric value
+. Purely spatial information
+. Spatial information with associated numeric value
 The fundamental premise of this architecture is that there is a legitimate distinction between these types of information, but that ''both'' types of information may be conveyed using either raster or vector constructs. Operations may specify that they handle one or both types of information, and they are not required to handle the different information types evenhandedly. However, operations they should accept or produce ''all representations'' of the information they claim to handle (i.e. raster or vector.)
 …
 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:
 * Spatial information
 ** Does "Input 1" contain (or intersect) the output cell?
 ** Does "Input 2" contain (or intersect) the output cell?
 ** Is the output cell included in the result?
 * Value information
 ** Is "Input 1" Spatial Only or Spatial Value?
 *** If Spatial Value and "Input 1" contains the output cell, what is the value?
 ** Is "Input 2" Spatial Only or Spatial Value?
 *** If Spatial Value and "Input 2" contains the output cell, what is the value?
 ** Given spatial information, and potentially value information, for "Input 1" and "Input 2", what is the value to store in the result cell?
+ * Spatial information
+  * Does "Input 1" contain (or intersect) the output cell?
+  * Does "Input 2" contain (or intersect) the output cell?
+  * Is the output cell included in the result?
+ * Value information
+  * Is "Input 1" Spatial Only or Spatial Value?
+    * If Spatial Value and "Input 1" contains the output cell, what is the value?
+  * Is "Input 2" Spatial Only or Spatial Value?
+    * If Spatial Value and "Input 2" contains the output cell, what is the value?
+  * Given spatial information, and potentially value information, for "Input 1" and "Input 2", what is the value to store in the result cell?
 These determinations can be factored out of the main iteration engine as "extension points". Potential extension points may be defined as follows:
 * Input
 ** Does input contain a point?
 ** Is input spatial only or Spatial Value?
 ** What is the value of input at the specified point?
 * Spatial operation (is the output cell included in the result?)
 * Value computation (what is the value to store in the result?)
+ * Input
+  * Does input contain a point?
+  * Is input spatial only or Spatial Value?
+  * What is the value of input at the specified point?
+ * Spatial operation (is the output cell included in the result?)
+ * Value computation (what is the value to store in the result?)
 A very generic core utility could be provided with the definition of:
 # Input extension points defined for <code>geometry</code>, <code>geomval</code>, and <code>raster</code> data types.
 # Spatial operation extension points defined for common operations: difference, intersection, symmetric difference, and union.
 # Value computation extension points defined for: mask value, copy value from input 1 (preferred) or input 2 (if necessary), expression evaluation.
+. Input extension points defined for <code>geometry</code>, <code>geomval</code>, and <code>raster</code> data types.
+. Spatial operation extension points defined for common operations: difference, intersection, symmetric difference, and union.
+. Value computation extension points defined for: mask value, copy value from input 1 (preferred) or input 2 (if necessary), expression evaluation.
 Such a core utility 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.
 …
 == See also ==
 * [http://www.cef-cfr.ca/uploads/Membres/WKTRasterSpecifications1.0.pdf Original WKT Raster presentation] (now Postgis Raster)
 * [http://trac.osgeo.org/postgis/wiki/WKTRaster Postgis Raster Home Page]
 * [http://docs.codehaus.org/download/attachments/31212/ISO19123 Primer.pdf ISO 19123 Primer]
+ * [http://www.cef-cfr.ca/uploads/Membres/WKTRasterSpecifications1.0.pdf Original WKT Raster presentation] (now Postgis Raster)
+ * [http://trac.osgeo.org/postgis/wiki/WKTRaster Postgis Raster Home Page]
+ * [http://docs.codehaus.org/download/attachments/31212/ISO19123 Primer.pdf ISO 19123 Primer]