Changes between Version 7 and Version 8 of UsersWikiCoveragesAndPostgis

Timestamp:

07/21/11 16:58:25 (13 years ago)

Author:

bnordgren

Comment:

--

UsersWikiCoveragesAndPostgis

@@ -65 +65 @@
   '''Implication 1:''' A table which backs a "raster coverage" cannot be constructed by analogy with a table which backs a "vector coverage". Simply substituting `raster` for `geometry` as a column type does not create data for a raster coverage. Each row in a table backing a vector coverage forms a single association between a location and a value. A row containing a `raster` item contains ''many'' associations between location and value and ''additionally'' forms a single association between the raster as a whole and the rest of the values in the row. 
 
-The second observation is that each raster is self-consistent (e.g., each cell has the same number and type of bands), but there are no guarantees about how the raster in one row is related to a raster in another row (e.g., a raster in a different row may have a different number of bands, or they may be of a different type.) The column type alone is not sufficient to guarantee that all rows will have compatible data.
+The second observation is that each raster is self-consistent (e.g., each cell has the same number and type of bands), but there are no guarantees about how the raster in one row is related to a raster in another row (e.g., a raster in a different row may have a different number of bands, or they may be of a different type.) The column type alone is not sufficient to guarantee that all rows will have compatible data. One row may hold a raster containing a single band of elevation data, another row may be a 3 band R, G, B image.
 
-  '''Implication 2:''' Rows of the same table cannot be assumed to convey values of consistent types. If an operation requires that values have consistent types, it may only be applied to a table which makes these guarantees: either by constraints or by carefully inserting rows from known sources.
+  '''Implication 2:''' Different rows of the same table cannot be assumed to convey values of consistent types. If an operation requires that values have consistent types, it may only be applied to a table which makes these guarantees: either by constraints or by carefully inserting rows from known sources. Likewise, these same guarantees must be made if the table is to be considered a "raster coverage", with each row containing a portion (subsection or "tile") of the overall dataset.
+
+  '''Implication 3:''' To render a "raster coverage" backed by a table having a raster column as well as other columns, only the information in the raster column is actually displayed: the other columns are ignored. 
+
+  '''Implication 4:''' Locating information in a table having the above guarantees and which backs a "raster coverage" is a two-stage process. The first step is to locate the row(s) which could potentially contain the desired location. The second step is to retrieve the value(s) from the candidate raster, if it does in fact contain the desired location. 
+
+The third observation is that a "raster coverage" does not need to be backed by a table at all. A single `raster` item could provide all of the data required. If a table is used, it needs only a single column (instead of the two columns required by a table which backs a vector coverage).
+
+Clearly, a table with a raster column could be used as an index into many unrelated rasters. This is a legitimate use of the table facility. However, it is an example of a table which could not be used to provide information to a "raster coverage."