| 1 | | {{{ |
| 2 | | #!html |
| 3 | | |
| 4 | | |
| 5 | | <div class="wiki"> |
| 6 | | <h1 id="Seamless-spatial-operations-architecture">Seamless spatial operations architecture<a href="#Seamless-spatial-operations-architecture" class="wiki-anchor">¶</a></h1> |
| 7 | | |
| 8 | | <h2 id="Introduction">Introduction<a href="#Introduction" class="wiki-anchor">¶</a></h2> |
| 9 | | |
| 10 | | |
| 11 | | <p>This page presents an extensible and reusable architecture capable of delivering on the promise of seamless raster and vector spatial operations. A spatial operation is any operation where the spatial characteristics of an object affect the outcome of the operation. Usually, the result of such an operation is spatial information which must somehow be conveyed.</p> |
| 12 | | |
| 13 | | |
| 14 | | <p>A description of what "seamless" means, with some worked examples, may be found in the original <a href="http://www.cef-cfr.ca/uploads/Membres/WKTRasterSpecifications1.0.pdf" class="external">WKT Raster presentation.</a> This is not a well defined domain, so the architecture selected to actualize the original vision must be flexible and adaptable. It should be expected that seamless operations will evolve over time, as the facility is applied to practical problems.</p> |
| 15 | | |
| 16 | | |
| 17 | | <h2 id="Scope">Scope<a href="#Scope" class="wiki-anchor">¶</a></h2> |
| 18 | | |
| 19 | | |
| 20 | | <p>This architecture articulates a strategy and best practices for developing spatial operations which evenhandedly handle raster and vector data. Common traits and requirements for such operations are expressed. This architecture assumes the ability to load, store and access raster and vector data is present, and does not include such operations.</p> |
| 21 | | |
| 22 | | |
| 23 | | <p>This architecture is somewhat abstract, and while it is designed to work within the PostGIS framework (which uses the non-object-oriented language C), the fundamental concepts and structure should be applicable to any system. Implementation details are not considered here, although the structure of conforming implementations is specified.</p> |
| 24 | | |
| 25 | | |
| 26 | | <h2 id="Types-of-information">Types of information<a href="#Types-of-information" class="wiki-anchor">¶</a></h2> |
| 27 | | |
| 28 | | |
| 29 | | <p>Vector operations operate on "vector objects", which are geometries. These geometries represent purely spatial information. Depending on the type of geometry, they may represent a single point, an array of points, lines or curves, areas, or volumes. Operations on these geometries generate purely spatial information which is also represented by a geometry (e.g., the difference between two polygons is the area of the first polygon which is not overlapped by the second one; this area is represented by a resultant polygon).</p> |
| 30 | | |
| 31 | | |
| 32 | | <p>Raster operations operate on gridded data. The grid itself conveys spatial information, and the data associated with each grid cell conveys value information. Typical raster operations may operate on the spatial or the value information of a raster, or both. The result of a raster operation may also convey spatial information, value information, or both.</p> |
| 33 | | |
| 34 | | |
| 35 | | <p>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:</p> |
| 36 | | |
| 37 | | |
| 38 | | <ol> |
| 39 | | <li>Purely spatial information</li> |
| 40 | | <li>Spatial information with associated numeric value</li> |
| 41 | | |
| 42 | | </ol> |
| 43 | | |
| 44 | | |
| 45 | | <p>The fundamental premise of this architecture is that there is a legitimate distinction between these types of information, but that <em>both</em> 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 <em>all representations</em> of the information they claim to handle (i.e. raster or vector.)</p> |
| 46 | | |
| 47 | | |
| 48 | | <h2 id="A-tour-of-ISO-19123">A tour of ISO 19123<a href="#A-tour-of-ISO-19123" class="wiki-anchor">¶</a></h2> |
| 49 | | |
| 50 | | |
| 51 | | <p>The association of spatial information to numeric value is the fundamental building block of the <em>coverage</em> spatial type defined in <a href="http://docs.codehaus.org/download/attachments/31212/ISO19123+Primer.pdf" class="external">ISO 19123</a>. Individual associations, even aggregations of associations, are not themselves coverages. This architecture leverages the concepts developed in ISO 19123, in as far as they are applicable, in order to avoid reinventing the wheel. The intent is not to provide a conforming implementation, but to identify parallels. A complete coverage implementation may be able to leverage the building blocks defined by this architecture as a back end. With respect to the goals of this architectural definition, the principal benefit of leveraging the coverage toolbox is to aid the definition of a means to uniformly interact with fundamentally different data types.</p> |
| 52 | | |
| 53 | | |
| 54 | | <p>This architecture deals only with a very limited profile of the toolbox defined in ISO 19123. Specifically, geometric objects are limited to 2 coordinate dimensions (x,y or lat,lon) and 0, 1, or 2 topological dimensions (points, lines, and polygons). In addition, the data types of associated values are constrained to numeric types (integers and floating point numbers of various sizes.) These limitations define the common ground between the capabilities of image formats (which persist raster data) and the vast majority of systems capable of handling geospatial data.</p> |
| 55 | | |
| 56 | | |
| 57 | | <h3 id="Associations-the-building-blocks">Associations: the building blocks<a href="#Associations-the-building-blocks" class="wiki-anchor">¶</a></h3> |
| 58 | | |
| 59 | | |
| 60 | | <p>Each individual association is represented by a <code>CV_GeometryValuePair</code>, or one of its children. Children of <code>CV_GeometryValuePair</code> set limits on the spatial information allowed, and specific coverage types (e.g., point coverages) are composed of associations formed by one of these children (e.g., <code>CV_PointValuePair</code>). The hierarchy is given in the following figure.</p> |
| 61 | | |
| 62 | | |
| 63 | | <p><img src="http://trac.osgeo.org/postgis/raw-attachment/wiki/WKTRaster/SeamlessArchitecture/orig-gvp.png" alt="" /></p> |
| 64 | | |
| 65 | | |
| 66 | | <p>This architecture does not require a full implementation of the entire hierarchy. Only two data types are required: <code>CV_GeometryValuePair</code> and <code>CV_GridPointValuePair</code>. The names of the implementing data types are unimportant, they must simply occupy the roles in the above diagram. Rigid adherence to the UML diagram would require that a <code>CV_DomainObject</code> be explicitly represented. This architecture specification allows the direct substitution of a geometry object for the cases where a temporal component is not part of the domain. If the domain is to include temporal information, however, a domain object with both a spatial and temporal component must be defined.</p> |
| 67 | | |
| 68 | | |
| 69 | | <p>The "value" field of the <code>CV_GeometryValuePair</code> must be constrained to be a list of numeric types (each member of the list may have different types). Alternatively, a data structure type, such as "<code>struct</code>" in C, may be used, provided that all the fields are numeric. When applied to a raster, the "value" field represents the information in all the raster's bands (or a subset thereof), in order.</p> |
| 70 | | |
| 71 | | |
| 72 | | <h3 id="A-raster-is-a-CV_Grid">A raster is a CV_Grid<a href="#A-raster-is-a-CV_Grid" class="wiki-anchor">¶</a></h3> |
| 73 | | |
| 74 | | |
| 75 | | <p>A raster is more than a single association of spatial information to value information, yet less than a coverage. The raster data type is an aggregation of many individual associations which possess a gridded spatial structure. A georeferenced raster ties this gridded spatial structure to geolocations. A raster is, in short, a means of efficiently representing many values which are associated with many places. The following UML diagram shows the relevant constructs defined by ISO 19123.</p> |
| 76 | | |
| 77 | | |
| 78 | | <p><img src="http://trac.osgeo.org/postgis/raw-attachment/wiki/WKTRaster/SeamlessArchitecture/grid.png" alt="" /></p> |
| 79 | | |
| 80 | | |
| 81 | | <p>A <code>CV_Grid</code> by itself consists only of the metadata necessary to define a regular grid: number of dimensions, extent along each axis, and names for the axes. This constitutes basic header metadata only. There is no geospatial information at all. The data are also absent. All instances of <code>CV_Grid</code> may be related to certain other basic structures, as shown in the figure. However, the meaning of these structures and the extent to which they are populated with information, may vary depending on the information available.</p> |
| 82 | | |
| 83 | | |
| 84 | | <p>Children of <code>CV_Grid</code> add functionality. Children in the "Positioning" box add georeferencing information and capabilities. Children in the "Valuation" box add the raster data itself, as well as the ability to access it. Each child in the "Positioning" box represents a <em>type</em> of geolocation, adding the ability to translate back and forth between grid indices and location on the ground. This is equivilent to loading a header with geotags which specify the projection type as well as supplying all the parameters necessary to calculate position. An instance of a child in the "Valuation" box understands how to access the data, whether in memory or in a file. For the purposes of this architecture specification, a <strong>raster</strong> is the union of a member in the Positioning box with a member of the Valuation box: representing a fully georeferenced grid type with full access to the gridded data (whether that data is on disk or in memory).</p> |
| 85 | | |
| 86 | | |
| 87 | | <p>The <code>CV_GridPoint</code>, articulated in the above figure, differs from a <code>CV_DomainObject</code> only in the ability to store the grid coordinates <em>as well as the geolocation</em>. This is not considered critical. The associations with other pieces of information (such as <code>CV_Footprint</code> or <code>CV_GridCell</code>) need not be explicitly maintained so long as they can be calculated. This architecture specification does not require the explicit implementation of a separate <code>CV_GridPoint</code> type. In fact, a loose interpretation of ISO 19123 is encouraged in this case, particularly due to the fact that raster cells may be interpreted as points or as cell areas. It is explicitly considered permissible to construct an association between the polygon forming the outline of the grid cell and the cell's values (as a <code>CV_GeometryValuePair</code>), instead of using the prescribed <code>CV_GridPointValuePair</code>. If it is necessary to represent the gridded data using these individual associations, the spatial object should accurately reflect the point or area to which the values apply.</p> |
| 88 | | |
| 89 | | |
| 90 | | <p>It is rarely necessary or desirable to represent a raster as a collection of <code>CV_GeometryValuePairs</code>, however it is useful to explicitly articulate the fact that the raster is composed of these individual associations. It is also useful to explicitly acknowledge that each grid point has a footprint, and each grid cell is bounded by four grid points (again, loosely interpreting this to mean that grid points may constitute the <em>center</em> of four grid cells instead of the four corners of a single cell.) Calculating the footprint of an individual cell may be a useful utility to include in a software package. Internally representing the gridded data in this structure is generally not necessary because the spatial location is generally trivial to compute on the fly.</p> |
| 91 | | |
| 92 | | |
| 93 | | <h3 id="Top-level-coverage">Top level coverage<a href="#Top-level-coverage" class="wiki-anchor">¶</a></h3> |
| 94 | | |
| 95 | | |
| 96 | | <p>The basic top level schema for the coverage type is defined in the figure below. This builds on the tools provided previously and provides a common access mechanism which does not depend on the type of the underlying data.</p> |
| 97 | | |
| 98 | | |
| 99 | | <p><img src="http://trac.osgeo.org/postgis/raw-attachment/wiki/WKTRaster/SeamlessArchitecture/coverage.png" alt="" /></p> |
| 100 | | |
| 101 | | |
| 102 | | <p>Coverages add value over a simple collection of geometry-value pairs. They ensure that the collection of geometry-value pairs has a consistent value (e.g., values in the coverage have the same "type" everywhere). Three methods (<code>find</code>, <code>select</code>, and <code>list</code>) are shown on the Coverage type itself. Another method, an important method, is not shown on this diagram: <code>evaluate</code>.</p> |
| 103 | | |
| 104 | | |
| 105 | | <table> |
| 106 | | <tr> |
| 107 | | <td> <strong>Method</strong> </td> |
| 108 | | <td> <strong>Description</strong> </td> |
| 109 | | </tr> |
| 110 | | |
| 111 | | <tr> |
| 112 | | <td> <code>evaluate</code> </td> |
| 113 | | <td> returns a set of values for a given point. </td> |
| 114 | | </tr> |
| 115 | | <tr> |
| 116 | | <td> <code>select</code> </td> |
| 117 | | |
| 118 | | <td> returns all the geometry-value pairs which "lie within" the provided geometry </td> |
| 119 | | </tr> |
| 120 | | <tr> |
| 121 | | <td> <code>find</code> </td> |
| 122 | | <td> returns a list of geometry-value pairs, in order of distance from the provided point </td> |
| 123 | | |
| 124 | | </tr> |
| 125 | | <tr> |
| 126 | | <td> <code>list</code> </td> |
| 127 | | <td> returns a list of all the constituent geometry-value pairs which make up the coverage </td> |
| 128 | | </tr> |
| 129 | | <tr> |
| 130 | | |
| 131 | | <td> <code>evaluateInverse</code> </td> |
| 132 | | <td> returns a set of locations which match a particular set of values </td> |
| 133 | | </tr> |
| 134 | | </table> |
| 135 | | |
| 136 | | |
| 137 | | |
| 138 | | |
| 139 | | <p>These methods are the same for all coverages, regardless of type. The two main children of a <code>CV_Coverage</code> create a distinction between <em>discrete coverages</em>, which are simple aggregations of individual geometry-value pairs; and <em>continuous coverages</em>, which are capable of interpolating between geometry-value pairs. Both types of coverages are defined by geometry-value pairs.</p> |
| 140 | | |
| 141 | | |
| 142 | | <h3 id="Summary">Summary<a href="#Summary" class="wiki-anchor">¶</a></h3> |
| 143 | | |
| 144 | | |
| 145 | | <p>ISO 19123 provides tools to handle the association of a spatial object with a value. It defines a mechanism to accomplish this association which is conceptually similar regardless of the geometric objects participating in the association. It explicitly articulates how gridded information may be expressed as a set of these associations. Tools provided by ISO 19123 outline the seamless treatment of raster and vector data as two alternate expressions of the same information.</p> |
| 146 | | |
| 147 | | |
| 148 | | <h2 id="Representation">Representation<a href="#Representation" class="wiki-anchor">¶</a></h2> |
| 149 | | |
| 150 | | |
| 151 | | <p>This architecture considers "raster" and "vector" data types to be representational tools. Each representational tool is a means of conveying information. Each has different expressive capabilities. In addition, two distinct types of information have been articulated. These are: purely spatial information; and spatial information having an associated numeric value. This architecture defines a means to represent each information type using each representational tool.</p> |
| 152 | | |
| 153 | | |
| 154 | | <h3 id="Purely-spatial-information">Purely spatial information<a href="#Purely-spatial-information" class="wiki-anchor">¶</a></h3> |
| 155 | | |
| 156 | | |
| 157 | | <p>Vectors represent purely spatial information using geometry objects. These may be arbitrarily complex, and the constituent points are not necessarily aligned to any particular grid.</p> |
| 158 | | |
| 159 | | |
| 160 | | <p>Rasters represent purely spatial information using a mask. A mask is a special case of a raster where the grid cells hold true or false values. Each grid cell possesses spatial location information (e.g., for each grid cell (i, j), a real-world position can be calculated). A true value in a cell indicates that the spatial location associated with the cell is included in the spatial information conveyed by the raster. Likewise, a false value indicates that the spatial information associated with the cell is <em>not</em> included. The spatial information conveyed by the raster as a whole is the sum of its parts. More specifically, the spatial information conveyed by the overall raster is the union of the spatial information conveyed by each cell with a true value.</p> |
| 161 | | |
| 162 | | |
| 163 | | <h3 id="Spatial-information-with-associated-numeric-value">Spatial information with associated numeric value<a href="#Spatial-information-with-associated-numeric-value" class="wiki-anchor">¶</a></h3> |
| 164 | | |
| 165 | | |
| 166 | | <p>Vectors represent combined spatial and value information with a structure, record, datatype, or class which has a geometry part and a value part. In <a href="http://docs.codehaus.org/download/attachments/31212/ISO19123+Primer.pdf" class="external">ISO 19123</a> this is represented as the type <code>CV_GeometryValuePair</code>. In the postgis raster extension, there is a <code>geomval</code> type. Any data structure which enforces a one-to-one relationship between a particular geometry and a particular list of values will accomplish this end. Using such a structure, there is a clear separation: the geometry conveys the spatial information and the value conveys the value information.</p> |
| 167 | | |
| 168 | | |
| 169 | | <p>Rasters have the ability to store one or more numeric values at each cell. The number of values present at each cell is exactly equal to the number of bands present in the overall raster. Each band may have a different numeric type, and the bands are ordered. Spatial information is conveyed by "nodata" values: cells containing the "nodata" value are equivalent to cells in a mask containing "false" values. Conversely, cells containing any value <em>other than</em> the "nodata" value are equivalent to cells in a mask containing true values. Each band may possess a unique "nodata" value which applies only to that band.</p> |
| 170 | | |
| 171 | | |
| 172 | | <p>Rasters have the potential to specify different spatial information with each band, whereas vectors may specify only one. In order to treat vectors and rasters uniformly, this architecture requires that all bands of a raster convey the <em>same</em> spatial information. All bands for a given grid cell must contain the "nodata" value, or all bands for a given grid cell must contain a value other than "nodata". This architecture forbids a raster to contain grid cells where some bands are nodata and others are not.</p> |
| 173 | | |
| 174 | | |
| 175 | | <p>Vectors have the potential to specify values other than numbers. This is beyond the capability of rasters, and therefore the structure which associates a geometry with a list of values must limit the list of values to numeric types. The list of values is ordered, and the type of each element in the list may be different, just as the bands of a raster may have different types.</p> |
| 176 | | |
| 177 | | |
| 178 | | <h3 id="Summary">Summary<a href="#Summary" class="wiki-anchor">¶</a></h3> |
| 179 | | |
| 180 | | |
| 181 | | <p>Using these conventions, both vectors and rasters may represent spatial information associated with a value. Likewise, both vectors and rasters may represent purely spatial information. Once the type of information is known, the method to represent the information is straightforward.</p> |
| 182 | | |
| 183 | | |
| 184 | | <h2 id="Expected-Results-and-Information-types">Expected Results and Information types<a href="#Expected-Results-and-Information-types" class="wiki-anchor">¶</a></h2> |
| 185 | | |
| 186 | | |
| 187 | | <p>The following table lists the potential combinations of inputs and output for two-input spatial operations. Implementations of spatial operations may declare that they support one or more rows from this table.</p> |
| 188 | | |
| 189 | | |
| 190 | | <table> |
| 191 | | <tr> |
| 192 | | <td><strong>Combination</strong> </td> |
| 193 | | <td> <strong>Input 1</strong> </td> |
| 194 | | <td> <strong>Input 2</strong> </td> |
| 195 | | |
| 196 | | <td> <strong>Returns</strong> </td> |
| 197 | | </tr> |
| 198 | | <tr> |
| 199 | | <td> 1 </td> |
| 200 | | <td> Pure Spatial </td> |
| 201 | | |
| 202 | | <td> Pure Spatial </td> |
| 203 | | <td> Pure Spatial </td> |
| 204 | | </tr> |
| 205 | | <tr> |
| 206 | | <td> 2 </td> |
| 207 | | <td> Pure Spatial </td> |
| 208 | | |
| 209 | | <td> Spatial+Value </td> |
| 210 | | <td> Pure Spatial </td> |
| 211 | | </tr> |
| 212 | | <tr> |
| 213 | | <td> 3 </td> |
| 214 | | <td> Spatial+Value </td> |
| 215 | | |
| 216 | | <td> Pure Spatial </td> |
| 217 | | <td> Pure Spatial </td> |
| 218 | | </tr> |
| 219 | | <tr> |
| 220 | | <td> 4 </td> |
| 221 | | <td> Spatial+Value </td> |
| 222 | | |
| 223 | | <td> Spatial+Value </td> |
| 224 | | <td> Pure Spatial </td> |
| 225 | | </tr> |
| 226 | | <tr> |
| 227 | | <td> 5 </td> |
| 228 | | <td> Pure Spatial </td> |
| 229 | | |
| 230 | | <td> Pure Spatial </td> |
| 231 | | <td> Spatial+Value </td> |
| 232 | | </tr> |
| 233 | | <tr> |
| 234 | | <td> 6 </td> |
| 235 | | <td> Pure Spatial </td> |
| 236 | | |
| 237 | | <td> Spatial+Value </td> |
| 238 | | <td> Spatial+Value </td> |
| 239 | | </tr> |
| 240 | | <tr> |
| 241 | | <td> 7 </td> |
| 242 | | <td> Spatial+Value </td> |
| 243 | | |
| 244 | | <td> Pure Spatial </td> |
| 245 | | <td> Spatial+Value </td> |
| 246 | | </tr> |
| 247 | | <tr> |
| 248 | | <td> 8 </td> |
| 249 | | <td> Spatial+Value </td> |
| 250 | | |
| 251 | | <td> Spatial+Value </td> |
| 252 | | <td> Spatial+Value </td> |
| 253 | | </tr> |
| 254 | | </table> |
| 255 | | |
| 256 | | |
| 257 | | |
| 258 | | |
| 259 | | <p>A "Pure Spatial" information type may be represented by either a geometry or by a mask (a special case of the raster data type). The Spatial+Value information type may be represented by either a non-mask raster, or by a datatype which implements the <code>CV_GeometryValuePair</code> from ISO 19123. The following table describes the mapping between information types and data types.</p> |
| 260 | | |
| 261 | | |
| 262 | | <table> |
| 263 | | <tr> |
| 264 | | <td> </td> |
| 265 | | <td> <strong>Pure Spatial</strong> </td> |
| 266 | | <td> <strong>Spatial+Value</strong> </td> |
| 267 | | |
| 268 | | </tr> |
| 269 | | <tr> |
| 270 | | <td> <strong>Vector</strong> </td> |
| 271 | | <td> <code>CV_DomainObject</code> or <code>GM_Object</code> </td> |
| 272 | | |
| 273 | | <td> <code>CV_GeometryValuePair</code> </td> |
| 274 | | </tr> |
| 275 | | <tr> |
| 276 | | <td> <strong>Raster</strong> </td> |
| 277 | | <td> <code>CV_Grid</code> (mask) </td> |
| 278 | | |
| 279 | | <td> <code>CV_Grid</code> (values) </td> |
| 280 | | </tr> |
| 281 | | </table> |
| 282 | | |
| 283 | | |
| 284 | | |
| 285 | | |
| 286 | | <p>Note that the same data type (an implementation of <code>CV_Grid</code> from ISO 19123) is capable of communicating both Pure Spatial and Spatial+Value information for "Raster" data. The difference is in the values of the grid cells, not in the type of the data. This reduces the number of required data types from four to three. <code>CV_Grid</code> will be referred to as raster, <code>GM_Object</code> will be referred to as "geometry", and <code>CV_GeometryValuePair</code> will be referred to as "geomval".</p> |
| 287 | | |
| 288 | | |
| 289 | | <blockquote> |
| 290 | | <p><strong>Example 1:</strong> Consider the <em>intersection</em> operation: returning common area between two inputs. The vector support in GIS systems is typically one eighth of the row which specifies that two Pure Spatial inputs result in a Pure Spatial output (combination 1). Typical GIS systems implement one eighth of this row due to the fact that they typically operate only on (and only return) geometry objects. A system implementing seamless vector and raster operations would also provide a means to return a mask, which is a special type of raster. Therefore, in terms of data types, this one line would become the following table. Note that because we are expanding the "Purely Spatial" line in the information type table, all of the rasters are actually masks: they lack value information. Observe also that adding the ability to return as well as accept spatial information using either representation adds support for the last seven lines of the data type table. |
| 291 | | <table> |
| 292 | | <tr> |
| 293 | | <td> <strong>Input 1</strong> </td> |
| 294 | | |
| 295 | | <td> <strong>Input 2</strong> </td> |
| 296 | | <td> <strong>Returns</strong> </td> |
| 297 | | </tr> |
| 298 | | <tr> |
| 299 | | <td> geometry </td> |
| 300 | | |
| 301 | | <td> geometry </td> |
| 302 | | <td> geometry </td> |
| 303 | | </tr> |
| 304 | | <tr> |
| 305 | | <td> geometry </td> |
| 306 | | <td> raster </td> |
| 307 | | |
| 308 | | <td> geometry </td> |
| 309 | | </tr> |
| 310 | | <tr> |
| 311 | | <td> raster </td> |
| 312 | | <td> geometry </td> |
| 313 | | <td> geometry </td> |
| 314 | | |
| 315 | | </tr> |
| 316 | | <tr> |
| 317 | | <td> raster </td> |
| 318 | | <td> raster </td> |
| 319 | | <td> geometry </td> |
| 320 | | </tr> |
| 321 | | |
| 322 | | <tr> |
| 323 | | <td> geometry </td> |
| 324 | | <td> geometry </td> |
| 325 | | <td> raster </td> |
| 326 | | </tr> |
| 327 | | <tr> |
| 328 | | |
| 329 | | <td> geometry </td> |
| 330 | | <td> raster </td> |
| 331 | | <td> raster </td> |
| 332 | | </tr> |
| 333 | | <tr> |
| 334 | | <td> raster </td> |
| 335 | | |
| 336 | | <td> geometry </td> |
| 337 | | <td> raster </td> |
| 338 | | </tr> |
| 339 | | <tr> |
| 340 | | <td> raster </td> |
| 341 | | <td> raster </td> |
| 342 | | |
| 343 | | <td> raster </td> |
| 344 | | </tr> |
| 345 | | </table> |
| 346 | | |
| 347 | | </p> |
| 348 | | </blockquote> |
| 349 | | |
| 350 | | |
| 351 | | <blockquote> |
| 352 | | <p><strong>Example 2:</strong> Consider an intersection operation returning values from one of the inputs in the common area. This is sometimes known as a "clip" operation. In typical GIS systems, this is usually implemented as an operation which accepts a raster and a vector, returning a raster. In a seamless raster/vector system, the same operation is defined in terms of information type. To be as similar as possible to the traditional GIS implementation would require that the seamless operation support only lines with one Purely Spatial input and one Spatial+Value input, returning a Spatial+Value result (combinations 6 and 7). To be fully seamless, all variants of the operation listed in the data type table should be implemented. There may be a justification for intentionally supporting a less than fully seamless operation. In this case, implementers may decide to support only those variants which return a raster, as the expected result of a "clip" operation is a grid which only contains values over the spatial intersection of two objects. Alternatively, the same operation having a different return type (or taking different arguments) may be known by different names. These aspects must be considered individually for each operation as they are defined. |
| 353 | | <table> |
| 354 | | |
| 355 | | <tr> |
| 356 | | <td> <strong>Input 1</strong> </td> |
| 357 | | <td> <strong>Input 2</strong> </td> |
| 358 | | <td> <strong>Returns</strong> </td> |
| 359 | | |
| 360 | | <td> <strong>Comment</strong> </td> |
| 361 | | </tr> |
| 362 | | <tr> |
| 363 | | <td> geometry </td> |
| 364 | | <td> raster </td> |
| 365 | | |
| 366 | | <td> raster </td> |
| 367 | | <td> input 2 must contain values </td> |
| 368 | | </tr> |
| 369 | | <tr> |
| 370 | | <td> raster </td> |
| 371 | | <td> geometry </td> |
| 372 | | |
| 373 | | <td> raster </td> |
| 374 | | <td> input 1 must contain values </td> |
| 375 | | </tr> |
| 376 | | <tr> |
| 377 | | <td> raster </td> |
| 378 | | <td> raster </td> |
| 379 | | |
| 380 | | <td> raster </td> |
| 381 | | <td> one input must contain values and the other must not </td> |
| 382 | | </tr> |
| 383 | | <tr> |
| 384 | | <td> geomval </td> |
| 385 | | <td> raster </td> |
| 386 | | |
| 387 | | <td> raster </td> |
| 388 | | <td> input 2 must be a mask </td> |
| 389 | | </tr> |
| 390 | | <tr> |
| 391 | | <td> raster </td> |
| 392 | | <td> geomval </td> |
| 393 | | |
| 394 | | <td> raster </td> |
| 395 | | <td> input 1 must be a mask </td> |
| 396 | | </tr> |
| 397 | | <tr> |
| 398 | | <td> geometry </td> |
| 399 | | <td> geomval </td> |
| 400 | | |
| 401 | | <td> raster </td> |
| 402 | | <td> </td> |
| 403 | | </tr> |
| 404 | | <tr> |
| 405 | | <td> geomval </td> |
| 406 | | <td> geometry </td> |
| 407 | | |
| 408 | | <td> raster </td> |
| 409 | | <td> </td> |
| 410 | | </tr> |
| 411 | | <tr> |
| 412 | | <td> geometry </td> |
| 413 | | <td> raster </td> |
| 414 | | |
| 415 | | <td> geomval </td> |
| 416 | | <td> input 2 must contain values </td> |
| 417 | | </tr> |
| 418 | | <tr> |
| 419 | | <td> raster </td> |
| 420 | | <td> geometry </td> |
| 421 | | |
| 422 | | <td> geomval </td> |
| 423 | | <td> input 1 must contain values </td> |
| 424 | | </tr> |
| 425 | | <tr> |
| 426 | | <td> raster </td> |
| 427 | | <td> raster </td> |
| 428 | | |
| 429 | | <td> geomval </td> |
| 430 | | <td> one input must contain values and the other must not </td> |
| 431 | | </tr> |
| 432 | | <tr> |
| 433 | | <td> geomval </td> |
| 434 | | <td> raster </td> |
| 435 | | |
| 436 | | <td> geomval </td> |
| 437 | | <td> input 2 must be a mask </td> |
| 438 | | </tr> |
| 439 | | <tr> |
| 440 | | <td> raster </td> |
| 441 | | <td> geomval </td> |
| 442 | | |
| 443 | | <td> geomval </td> |
| 444 | | <td> input 1 must be a mask </td> |
| 445 | | </tr> |
| 446 | | <tr> |
| 447 | | <td> geometry </td> |
| 448 | | <td> geomval </td> |
| 449 | | |
| 450 | | <td> geomval </td> |
| 451 | | <td> </td> |
| 452 | | </tr> |
| 453 | | <tr> |
| 454 | | <td> geomval </td> |
| 455 | | <td> geometry </td> |
| 456 | | |
| 457 | | <td> geomval </td> |
| 458 | | <td> </td> |
| 459 | | </tr> |
| 460 | | </table> |
| 461 | | |
| 462 | | </p> |
| 463 | | </blockquote> |
| 464 | | |
| 465 | | |
| 466 | | <h2 id="Result-Grid-Iteration-Engine">Result Grid Iteration Engine<a href="#Result-Grid-Iteration-Engine" class="wiki-anchor">¶</a></h2> |
| 467 | | |
| 468 | | |
| 469 | | <p>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.</p> |
| 470 | | |
| 471 | | |
| 472 | | <p>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:</p> |
| 473 | | |
| 474 | | |
| 475 | | <ul> |
| 476 | | |
| 477 | | <li>Spatial information |
| 478 | | <ul> |
| 479 | | <li>Does "Input 1" contain (or intersect) the output cell?</li> |
| 480 | | <li>Does "Input 2" contain (or intersect) the output cell?</li> |
| 481 | | <li>Is the output cell included in the result?</li> |
| 482 | | </ul> |
| 483 | | </li> |
| 484 | | <li>Value information |
| 485 | | <ul> |
| 486 | | |
| 487 | | <li>Is "Input 1" Spatial Only or Spatial+Value? |
| 488 | | <ul> |
| 489 | | <li>If Spatial+Value and "Input 1" contains the output cell, what is the value?</li> |
| 490 | | </ul> |
| 491 | | </li> |
| 492 | | <li>Is "Input 2" Spatial Only or Spatial+Value? |
| 493 | | <ul> |
| 494 | | <li>If Spatial+Value and "Input 2" contains the output cell, what is the value?</li> |
| 495 | | </ul> |
| 496 | | |
| 497 | | </li> |
| 498 | | <li>Given spatial information, and potentially value information, for "Input 1" and "Input 2", what is the value to store in the result cell?</li> |
| 499 | | </ul></li> |
| 500 | | </ul> |
| 501 | | |
| 502 | | |
| 503 | | <p>These determinations can be factored out of the main iteration engine as "extension points". Potential extension points may be defined as follows:</p> |
| 504 | | |
| 505 | | |
| 506 | | <ul> |
| 507 | | |
| 508 | | <li>Input |
| 509 | | <ul> |
| 510 | | <li>Does input contain a point?</li> |
| 511 | | <li>Is input spatial only or Spatial+Value?</li> |
| 512 | | <li>What is the value of input at the specified point?</li> |
| 513 | | </ul> |
| 514 | | </li> |
| 515 | | <li>Spatial operation (is the output cell included in the result?)</li> |
| 516 | | |
| 517 | | <li>Value computation (what is the value to store in the result?)</li> |
| 518 | | </ul> |
| 519 | | |
| 520 | | |
| 521 | | <p>A very generic core utility could be provided with the definition of:</p> |
| 522 | | |
| 523 | | |
| 524 | | <ol> |
| 525 | | <li>Input extension points defined for <code>geometry</code>, <code>geomval</code>, and <code>raster</code> data types.</li> |
| 526 | | |
| 527 | | <li>Spatial operation extension points defined for common operations: difference, intersection, symmetric difference, and union.</li> |
| 528 | | <li>Value computation extension points defined for: mask value, copy value from input 1 (preferred) or input 2 (if necessary), expression evaluation.</li> |
| 529 | | </ol> |
| 530 | | |
| 531 | | |
| 532 | | <p>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.</p> |
| 533 | | |
| 534 | | |
| 535 | | <h2 id="See-also">See also<a href="#See-also" class="wiki-anchor">¶</a></h2> |
| 536 | | |
| 537 | | |
| 538 | | <ul> |
| 539 | | <li><a href="http://www.cef-cfr.ca/uploads/Membres/WKTRasterSpecifications1.0.pdf" class="external">Original WKT Raster presentation</a> (now Postgis Raster)</li> |
| 540 | | <li><a href="http://trac.osgeo.org/postgis/wiki/WKTRaster" class="external">Postgis Raster Home Page</a></li> |
| 541 | | <li><a href="http://docs.codehaus.org/download/attachments/31212/ISO19123+Primer.pdf" class="external">ISO 19123 Primer</a></li> |
| 542 | | </ul> |
| 543 | | |
| 544 | | </div> |
| 545 | | }}} |
| | 1 | |
| | 2 | = Seamless spatial operations architecture = |
| | 3 | |
| | 4 | == Introduction == |
| | 5 | |
| | 6 | This page presents an extensible and reusable architecture capable of delivering on the promise of seamless raster and vector spatial operations. A spatial operation is any operation where the spatial characteristics of an object affect the outcome of the operation. Usually, the result of such an operation is spatial information which must somehow be conveyed. |
| | 7 | |
| | 8 | A description of what "seamless" means, with some worked examples, may be found in the original [http://www.cef-cfr.ca/uploads/Membres/WKTRasterSpecifications1.0.pdf WKT Raster presentation.] This is not a well defined domain, so the architecture selected to actualize the original vision must be flexible and adaptable. It should be expected that seamless operations will evolve over time, as the facility is applied to practical problems. |
| | 9 | |
| | 10 | == Scope == |
| | 11 | |
| | 12 | This architecture articulates a strategy and best practices for developing spatial operations which evenhandedly handle raster and vector data. Common traits and requirements for such operations are expressed. This architecture assumes the ability to load, store and access raster and vector data is present, and does not include such operations. |
| | 13 | |
| | 14 | This architecture is somewhat abstract, and while it is designed to work within the PostGIS framework (which uses the non-object-oriented language C), the fundamental concepts and structure should be applicable to any system. Implementation details are not considered here, although the structure of conforming implementations is specified. |
| | 15 | |
| | 16 | == Types of information == |
| | 17 | |
| | 18 | Vector operations operate on "vector objects", which are geometries. These geometries represent purely spatial information. Depending on the type of geometry, they may represent a single point, an array of points, lines or curves, areas, or volumes. Operations on these geometries generate purely spatial information which is also represented by a geometry (e.g., the difference between two polygons is the area of the first polygon which is not overlapped by the second one; this area is represented by a resultant polygon). |
| | 19 | |
| | 20 | Raster operations operate on gridded data. The grid itself conveys spatial information, and the data associated with each grid cell conveys value information. Typical raster operations may operate on the spatial or the value information of a raster, or both. The result of a raster operation may also convey spatial information, value information, or both. |
| | 21 | |
| | 22 | 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: |
| | 23 | |
| | 24 | # Purely spatial information |
| | 25 | # Spatial information with associated numeric value |
| | 26 | |
| | 27 | 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.) |
| | 28 | |
| | 29 | == A tour of ISO 19123 == |
| | 30 | |
| | 31 | The association of spatial information to numeric value is the fundamental building block of the ''coverage'' spatial type defined in [http://docs.codehaus.org/download/attachments/31212/ISO19123 Primer.pdf ISO 19123]. Individual associations, even aggregations of associations, are not themselves coverages. This architecture leverages the concepts developed in ISO 19123, in as far as they are applicable, in order to avoid reinventing the wheel. The intent is not to provide a conforming implementation, but to identify parallels. A complete coverage implementation may be able to leverage the building blocks defined by this architecture as a back end. With respect to the goals of this architectural definition, the principal benefit of leveraging the coverage toolbox is to aid the definition of a means to uniformly interact with fundamentally different data types. |
| | 32 | |
| | 33 | This architecture deals only with a very limited profile of the toolbox defined in ISO 19123. Specifically, geometric objects are limited to 2 coordinate dimensions (x,y or lat,lon) and 0, 1, or 2 topological dimensions (points, lines, and polygons). In addition, the data types of associated values are constrained to numeric types (integers and floating point numbers of various sizes.) These limitations define the common ground between the capabilities of image formats (which persist raster data) and the vast majority of systems capable of handling geospatial data. |
| | 34 | |
| | 35 | === Associations: the building blocks === |
| | 36 | |
| | 37 | Each individual association is represented by a <code>CV_GeometryValuePair</code>, or one of its children. Children of <code>CV_GeometryValuePair</code> set limits on the spatial information allowed, and specific coverage types (e.g., point coverages) are composed of associations formed by one of these children (e.g., <code>CV_PointValuePair</code>). The hierarchy is given in the following figure. |
| | 38 | |
| | 39 | [[Image:461]] |
| | 40 | |
| | 41 | This architecture does not require a full implementation of the entire hierarchy. Only two data types are required: <code>CV_GeometryValuePair</code> and <code>CV_GridPointValuePair</code>. The names of the implementing data types are unimportant, they must simply occupy the roles in the above diagram. Rigid adherence to the UML diagram would require that a <code>CV_DomainObject</code> be explicitly represented. This architecture specification allows the direct substitution of a geometry object for the cases where a temporal component is not part of the domain. If the domain is to include temporal information, however, a domain object with both a spatial and temporal component must be defined. |
| | 42 | |
| | 43 | The "value" field of the <code>CV_GeometryValuePair</code> must be constrained to be a list of numeric types (each member of the list may have different types). Alternatively, a data structure type, such as "<code>struct</code>" in C, may be used, provided that all the fields are numeric. When applied to a raster, the "value" field represents the information in all the raster's bands (or a subset thereof), in order. |
| | 44 | |
| | 45 | === A raster is a CV_Grid === |
| | 46 | |
| | 47 | A raster is more than a single association of spatial information to value information, yet less than a coverage. The raster data type is an aggregation of many individual associations which possess a gridded spatial structure. A georeferenced raster ties this gridded spatial structure to geolocations. A raster is, in short, a means of efficiently representing many values which are associated with many places. The following UML diagram shows the relevant constructs defined by ISO 19123. |
| | 48 | |
| | 49 | [[Image:462]] |
| | 50 | |
| | 51 | A <code>CV_Grid</code> by itself consists only of the metadata necessary to define a regular grid: number of dimensions, extent along each axis, and names for the axes. This constitutes basic header metadata only. There is no geospatial information at all. The data are also absent. All instances of <code>CV_Grid</code> may be related to certain other basic structures, as shown in the figure. However, the meaning of these structures and the extent to which they are populated with information, may vary depending on the information available. |
| | 52 | |
| | 53 | Children of <code>CV_Grid</code> add functionality. Children in the "Positioning" box add georeferencing information and capabilities. Children in the "Valuation" box add the raster data itself, as well as the ability to access it. Each child in the "Positioning" box represents a ''type'' of geolocation, adding the ability to translate back and forth between grid indices and location on the ground. This is equivilent to loading a header with geotags which specify the projection type as well as supplying all the parameters necessary to calculate position. An instance of a child in the "Valuation" box understands how to access the data, whether in memory or in a file. For the purposes of this architecture specification, a '''raster''' is the union of a member in the Positioning box with a member of the Valuation box: representing a fully georeferenced grid type with full access to the gridded data (whether that data is on disk or in memory). |
| | 54 | |
| | 55 | The <code>CV_GridPoint</code>, articulated in the above figure, differs from a <code>CV_DomainObject</code> only in the ability to store the grid coordinates ''as well as the geolocation''. This is not considered critical. The associations with other pieces of information (such as <code>CV_Footprint</code> or <code>CV_GridCell</code>) need not be explicitly maintained so long as they can be calculated. This architecture specification does not require the explicit implementation of a separate <code>CV_GridPoint</code> type. In fact, a loose interpretation of ISO 19123 is encouraged in this case, particularly due to the fact that raster cells may be interpreted as points or as cell areas. It is explicitly considered permissible to construct an association between the polygon forming the outline of the grid cell and the cell's values (as a <code>CV_GeometryValuePair</code>), instead of using the prescribed <code>CV_GridPointValuePair</code>. If it is necessary to represent the gridded data using these individual associations, the spatial object should accurately reflect the point or area to which the values apply. |
| | 56 | |
| | 57 | It is rarely necessary or desirable to represent a raster as a collection of <code>CV_GeometryValuePairs</code>, however it is useful to explicitly articulate the fact that the raster is composed of these individual associations. It is also useful to explicitly acknowledge that each grid point has a footprint, and each grid cell is bounded by four grid points (again, loosely interpreting this to mean that grid points may constitute the ''center'' of four grid cells instead of the four corners of a single cell.) Calculating the footprint of an individual cell may be a useful utility to include in a software package. Internally representing the gridded data in this structure is generally not necessary because the spatial location is generally trivial to compute on the fly. |
| | 58 | |
| | 59 | === Top level coverage === |
| | 60 | |
| | 61 | The basic top level schema for the coverage type is defined in the figure below. This builds on the tools provided previously and provides a common access mechanism which does not depend on the type of the underlying data. |
| | 62 | |
| | 63 | [[Image:463]] |
| | 64 | |
| | 65 | Coverages add value over a simple collection of geometry-value pairs. They ensure that the collection of geometry-value pairs has a consistent value (e.g., values in the coverage have the same "type" everywhere). Three methods (<code>find</code>, <code>select</code>, and <code>list</code>) are shown on the Coverage type itself. Another method, an important method, is not shown on this diagram: <code>evaluate</code>. |
| | 66 | |
| | 67 | {| |
| | 68 | | '''Method''' |
| | 69 | | '''Description''' |
| | 70 | |- |
| | 71 | | <code>evaluate</code> |
| | 72 | | returns a set of values for a given point. |
| | 73 | |- |
| | 74 | | <code>select</code> |
| | 75 | | returns all the geometry-value pairs which "lie within" the provided geometry |
| | 76 | |- |
| | 77 | | <code>find</code> |
| | 78 | | returns a list of geometry-value pairs, in order of distance from the provided point |
| | 79 | |- |
| | 80 | | <code>list</code> |
| | 81 | | returns a list of all the constituent geometry-value pairs which make up the coverage |
| | 82 | |- |
| | 83 | | <code>evaluateInverse</code> |
| | 84 | | returns a set of locations which match a particular set of values |
| | 85 | |} |
| | 86 | |
| | 87 | These methods are the same for all coverages, regardless of type. The two main children of a <code>CV_Coverage</code> create a distinction between ''discrete coverages'', which are simple aggregations of individual geometry-value pairs; and ''continuous coverages'', which are capable of interpolating between geometry-value pairs. Both types of coverages are defined by geometry-value pairs. |
| | 88 | |
| | 89 | === Summary === |
| | 90 | |
| | 91 | ISO 19123 provides tools to handle the association of a spatial object with a value. It defines a mechanism to accomplish this association which is conceptually similar regardless of the geometric objects participating in the association. It explicitly articulates how gridded information may be expressed as a set of these associations. Tools provided by ISO 19123 outline the seamless treatment of raster and vector data as two alternate expressions of the same information. |
| | 92 | |
| | 93 | == Representation == |
| | 94 | |
| | 95 | This architecture considers "raster" and "vector" data types to be representational tools. Each representational tool is a means of conveying information. Each has different expressive capabilities. In addition, two distinct types of information have been articulated. These are: purely spatial information; and spatial information having an associated numeric value. This architecture defines a means to represent each information type using each representational tool. |
| | 96 | |
| | 97 | === Purely spatial information === |
| | 98 | |
| | 99 | Vectors represent purely spatial information using geometry objects. These may be arbitrarily complex, and the constituent points are not necessarily aligned to any particular grid. |
| | 100 | |
| | 101 | Rasters represent purely spatial information using a mask. A mask is a special case of a raster where the grid cells hold true or false values. Each grid cell possesses spatial location information (e.g., for each grid cell (i, j), a real-world position can be calculated). A true value in a cell indicates that the spatial location associated with the cell is included in the spatial information conveyed by the raster. Likewise, a false value indicates that the spatial information associated with the cell is ''not'' included. The spatial information conveyed by the raster as a whole is the sum of its parts. More specifically, the spatial information conveyed by the overall raster is the union of the spatial information conveyed by each cell with a true value. |
| | 102 | |
| | 103 | === Spatial information with associated numeric value === |
| | 104 | |
| | 105 | Vectors represent combined spatial and value information with a structure, record, datatype, or class which has a geometry part and a value part. In [http://docs.codehaus.org/download/attachments/31212/ISO19123 Primer.pdf ISO 19123] this is represented as the type <code>CV_GeometryValuePair</code>. In the postgis raster extension, there is a <code>geomval</code> type. Any data structure which enforces a one-to-one relationship between a particular geometry and a particular list of values will accomplish this end. Using such a structure, there is a clear separation: the geometry conveys the spatial information and the value conveys the value information. |
| | 106 | |
| | 107 | Rasters have the ability to store one or more numeric values at each cell. The number of values present at each cell is exactly equal to the number of bands present in the overall raster. Each band may have a different numeric type, and the bands are ordered. Spatial information is conveyed by "nodata" values: cells containing the "nodata" value are equivalent to cells in a mask containing "false" values. Conversely, cells containing any value ''other than'' the "nodata" value are equivalent to cells in a mask containing true values. Each band may possess a unique "nodata" value which applies only to that band. |
| | 108 | |
| | 109 | Rasters have the potential to specify different spatial information with each band, whereas vectors may specify only one. In order to treat vectors and rasters uniformly, this architecture requires that all bands of a raster convey the ''same'' spatial information. All bands for a given grid cell must contain the "nodata" value, or all bands for a given grid cell must contain a value other than "nodata". This architecture forbids a raster to contain grid cells where some bands are nodata and others are not. |
| | 110 | |
| | 111 | Vectors have the potential to specify values other than numbers. This is beyond the capability of rasters, and therefore the structure which associates a geometry with a list of values must limit the list of values to numeric types. The list of values is ordered, and the type of each element in the list may be different, just as the bands of a raster may have different types. |
| | 112 | |
| | 113 | === Summary === |
| | 114 | |
| | 115 | Using these conventions, both vectors and rasters may represent spatial information associated with a value. Likewise, both vectors and rasters may represent purely spatial information. Once the type of information is known, the method to represent the information is straightforward. |
| | 116 | |
| | 117 | == Expected Results and Information types == |
| | 118 | |
| | 119 | The following table lists the potential combinations of inputs and output for two-input spatial operations. Implementations of spatial operations may declare that they support one or more rows from this table. |
| | 120 | |
| | 121 | {| |
| | 122 | | '''Combination''' |
| | 123 | | '''Input 1''' |
| | 124 | | '''Input 2''' |
| | 125 | | '''Returns''' |
| | 126 | |- |
| | 127 | | 1 |
| | 128 | | Pure Spatial |
| | 129 | | Pure Spatial |
| | 130 | | Pure Spatial |
| | 131 | |- |
| | 132 | | 2 |
| | 133 | | Pure Spatial |
| | 134 | | Spatial Value |
| | 135 | | Pure Spatial |
| | 136 | |- |
| | 137 | | 3 |
| | 138 | | Spatial Value |
| | 139 | | Pure Spatial |
| | 140 | | Pure Spatial |
| | 141 | |- |
| | 142 | | 4 |
| | 143 | | Spatial Value |
| | 144 | | Spatial Value |
| | 145 | | Pure Spatial |
| | 146 | |- |
| | 147 | | 5 |
| | 148 | | Pure Spatial |
| | 149 | | Pure Spatial |
| | 150 | | Spatial Value |
| | 151 | |- |
| | 152 | | 6 |
| | 153 | | Pure Spatial |
| | 154 | | Spatial Value |
| | 155 | | Spatial Value |
| | 156 | |- |
| | 157 | | 7 |
| | 158 | | Spatial Value |
| | 159 | | Pure Spatial |
| | 160 | | Spatial Value |
| | 161 | |- |
| | 162 | | 8 |
| | 163 | | Spatial Value |
| | 164 | | Spatial Value |
| | 165 | | Spatial Value |
| | 166 | |} |
| | 167 | |
| | 168 | A "Pure Spatial" information type may be represented by either a geometry or by a mask (a special case of the raster data type). The Spatial Value information type may be represented by either a non-mask raster, or by a datatype which implements the <code>CV_GeometryValuePair</code> from ISO 19123. The following table describes the mapping between information types and data types. |
| | 169 | |
| | 170 | {| |
| | 171 | | |
| | 172 | | '''Pure Spatial''' |
| | 173 | | '''Spatial Value''' |
| | 174 | |- |
| | 175 | | '''Vector''' |
| | 176 | | <code>CV_DomainObject</code> or <code>GM_Object</code> |
| | 177 | | <code>CV_GeometryValuePair</code> |
| | 178 | |- |
| | 179 | | '''Raster''' |
| | 180 | | <code>CV_Grid</code> (mask) |
| | 181 | | <code>CV_Grid</code> (values) |
| | 182 | |} |
| | 183 | |
| | 184 | Note that the same data type (an implementation of <code>CV_Grid</code> from ISO 19123) is capable of communicating both Pure Spatial and Spatial Value information for "Raster" data. The difference is in the values of the grid cells, not in the type of the data. This reduces the number of required data types from four to three. <code>CV_Grid</code> will be referred to as raster, <code>GM_Object</code> will be referred to as "geometry", and <code>CV_GeometryValuePair</code> will be referred to as "geomval". |
| | 185 | |
| | 186 | <blockquote> |
| | 187 | |
| | 188 | '''Example 1:''' Consider the ''intersection'' operation: returning common area between two inputs. The vector support in GIS systems is typically one eighth of the row which specifies that two Pure Spatial inputs result in a Pure Spatial output (combination 1). Typical GIS systems implement one eighth of this row due to the fact that they typically operate only on (and only return) geometry objects. A system implementing seamless vector and raster operations would also provide a means to return a mask, which is a special type of raster. Therefore, in terms of data types, this one line would become the following table. Note that because we are expanding the "Purely Spatial" line in the information type table, all of the rasters are actually masks: they lack value information. Observe also that adding the ability to return as well as accept spatial information using either representation adds support for the last seven lines of the data type table. |
| | 189 | |
| | 190 | {| |
| | 191 | | '''Input 1''' |
| | 192 | | '''Input 2''' |
| | 193 | | '''Returns''' |
| | 194 | |- |
| | 195 | | geometry |
| | 196 | | geometry |
| | 197 | | geometry |
| | 198 | |- |
| | 199 | | geometry |
| | 200 | | raster |
| | 201 | | geometry |
| | 202 | |- |
| | 203 | | raster |
| | 204 | | geometry |
| | 205 | | geometry |
| | 206 | |- |
| | 207 | | raster |
| | 208 | | raster |
| | 209 | | geometry |
| | 210 | |- |
| | 211 | | geometry |
| | 212 | | geometry |
| | 213 | | raster |
| | 214 | |- |
| | 215 | | geometry |
| | 216 | | raster |
| | 217 | | raster |
| | 218 | |- |
| | 219 | | raster |
| | 220 | | geometry |
| | 221 | | raster |
| | 222 | |- |
| | 223 | | raster |
| | 224 | | raster |
| | 225 | | raster |
| | 226 | |} |
| | 227 | |
| | 228 | </blockquote><blockquote> |
| | 229 | |
| | 230 | '''Example 2:''' Consider an intersection operation returning values from one of the inputs in the common area. This is sometimes known as a "clip" operation. In typical GIS systems, this is usually implemented as an operation which accepts a raster and a vector, returning a raster. In a seamless raster/vector system, the same operation is defined in terms of information type. To be as similar as possible to the traditional GIS implementation would require that the seamless operation support only lines with one Purely Spatial input and one Spatial Value input, returning a Spatial Value result (combinations 6 and 7). To be fully seamless, all variants of the operation listed in the data type table should be implemented. There may be a justification for intentionally supporting a less than fully seamless operation. In this case, implementers may decide to support only those variants which return a raster, as the expected result of a "clip" operation is a grid which only contains values over the spatial intersection of two objects. Alternatively, the same operation having a different return type (or taking different arguments) may be known by different names. These aspects must be considered individually for each operation as they are defined. |
| | 231 | |
| | 232 | {| |
| | 233 | | '''Input 1''' |
| | 234 | | '''Input 2''' |
| | 235 | | '''Returns''' |
| | 236 | | '''Comment''' |
| | 237 | |- |
| | 238 | | geometry |
| | 239 | | raster |
| | 240 | | raster |
| | 241 | | input 2 must contain values |
| | 242 | |- |
| | 243 | | raster |
| | 244 | | geometry |
| | 245 | | raster |
| | 246 | | input 1 must contain values |
| | 247 | |- |
| | 248 | | raster |
| | 249 | | raster |
| | 250 | | raster |
| | 251 | | one input must contain values and the other must not |
| | 252 | |- |
| | 253 | | geomval |
| | 254 | | raster |
| | 255 | | raster |
| | 256 | | input 2 must be a mask |
| | 257 | |- |
| | 258 | | raster |
| | 259 | | geomval |
| | 260 | | raster |
| | 261 | | input 1 must be a mask |
| | 262 | |- |
| | 263 | | geometry |
| | 264 | | geomval |
| | 265 | | raster |
| | 266 | | |
| | 267 | |- |
| | 268 | | geomval |
| | 269 | | geometry |
| | 270 | | raster |
| | 271 | | |
| | 272 | |- |
| | 273 | | geometry |
| | 274 | | raster |
| | 275 | | geomval |
| | 276 | | input 2 must contain values |
| | 277 | |- |
| | 278 | | raster |
| | 279 | | geometry |
| | 280 | | geomval |
| | 281 | | input 1 must contain values |
| | 282 | |- |
| | 283 | | raster |
| | 284 | | raster |
| | 285 | | geomval |
| | 286 | | one input must contain values and the other must not |
| | 287 | |- |
| | 288 | | geomval |
| | 289 | | raster |
| | 290 | | geomval |
| | 291 | | input 2 must be a mask |
| | 292 | |- |
| | 293 | | raster |
| | 294 | | geomval |
| | 295 | | geomval |
| | 296 | | input 1 must be a mask |
| | 297 | |- |
| | 298 | | geometry |
| | 299 | | geomval |
| | 300 | | geomval |
| | 301 | | |
| | 302 | |- |
| | 303 | | geomval |
| | 304 | | geometry |
| | 305 | | geomval |
| | 306 | | |
| | 307 | |} |
| | 308 | |
| | 309 | </blockquote> |
| | 310 | |
| | 311 | == Result Grid Iteration Engine == |
| | 312 | |
| | 313 | 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. |
| | 314 | |
| | 315 | 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: |
| | 316 | |
| | 317 | * Spatial information |
| | 318 | ** Does "Input 1" contain (or intersect) the output cell? |
| | 319 | ** Does "Input 2" contain (or intersect) the output cell? |
| | 320 | ** Is the output cell included in the result? |
| | 321 | * Value information |
| | 322 | ** Is "Input 1" Spatial Only or Spatial Value? |
| | 323 | *** If Spatial Value and "Input 1" contains the output cell, what is the value? |
| | 324 | ** Is "Input 2" Spatial Only or Spatial Value? |
| | 325 | *** If Spatial Value and "Input 2" contains the output cell, what is the value? |
| | 326 | ** Given spatial information, and potentially value information, for "Input 1" and "Input 2", what is the value to store in the result cell? |
| | 327 | |
| | 328 | These determinations can be factored out of the main iteration engine as "extension points". Potential extension points may be defined as follows: |
| | 329 | |
| | 330 | * Input |
| | 331 | ** Does input contain a point? |
| | 332 | ** Is input spatial only or Spatial Value? |
| | 333 | ** What is the value of input at the specified point? |
| | 334 | * Spatial operation (is the output cell included in the result?) |
| | 335 | * Value computation (what is the value to store in the result?) |
| | 336 | |
| | 337 | A very generic core utility could be provided with the definition of: |
| | 338 | |
| | 339 | # Input extension points defined for <code>geometry</code>, <code>geomval</code>, and <code>raster</code> data types. |
| | 340 | # Spatial operation extension points defined for common operations: difference, intersection, symmetric difference, and union. |
| | 341 | # Value computation extension points defined for: mask value, copy value from input 1 (preferred) or input 2 (if necessary), expression evaluation. |
| | 342 | |
| | 343 | 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. |
| | 344 | |
| | 345 | == See also == |
| | 346 | |
| | 347 | * [http://www.cef-cfr.ca/uploads/Membres/WKTRasterSpecifications1.0.pdf Original WKT Raster presentation] (now Postgis Raster) |
| | 348 | * [http://trac.osgeo.org/postgis/wiki/WKTRaster Postgis Raster Home Page] |
| | 349 | * [http://docs.codehaus.org/download/attachments/31212/ISO19123 Primer.pdf ISO 19123 Primer] |
