| 53 | | This single table could back any number of coverages. It could back a "Population" coverage simply by returning the value in the Population column whenever the query point intersects the geometry. |
| | 53 | This single table could back any number of coverages. It could back a "Population" coverage simply by returning the value in the Population column whenever the query point intersects the geometry. Likewise, a coverage could return the value of any of the other columns, or any combination of the other columns. The coverage ''interprets'' the `geometry` column to be the ''domain'' and one or more of the other columns as the ''range''. |
| | 54 | |
| | 55 | Note that if there is more than one `geometry` column, the coverage must pick only one to use as the ''domain''. The coverage is a way of interpreting, representing, and accessing a self-consistent collection of data. |
| | 56 | |
| | 57 | === Raster Coverages === |
| | 58 | |
| | 59 | Raster coverages are backed by regularly gridded data. The ''domain'' is always a point. The ''range'' is one or more numeric values, referred to as "bands". Text values and timestamp values are not allowed. One can convert this gridded data into table form, if desired, although this is almost never useful. Simply construct a table with one `geometry` column and one numeric column for each band. Each cell in the table may then be represented by its own row. The principal advantage of the regular gridded structure is the ease with which relevant data can be located, given a spatial region of interest. This structure allows certain optimizations for speed which are not possible using a collection of data in table form. |
| | 60 | |
| | 61 | In PostGIS, the data required to back a raster coverage is contained in a single data type called `raster`. This single type has both location information and value information. Each point within a raster can have it's own set of values. This subtle point has some not-so-subtle implications. |
| | 62 | |
| | 63 | The first observation concerns the meaning of a table having a raster column. Consider a vector coverage: there is a clean one-to-one relationship between all of the values in a single row. The geometry in a particular row is associated with the values in that same row. If the geometry is a polygon, the values in the same row are associated with the entire polygon. The geometry column may contain a very complex multipolygon or a large multipoint geometry, and the value columns may be arrays, but there is no way to associate individual array elements with individual polygons or individual points. If it is necessary to associate different values with different parts of the geometry, you have to make a new row. Now consider the implications of this one-to-one relationship when one of the columns is a raster: there is ''still'' no way to associate values in other columns with individual points inside the raster. The information in the other columns applies to the entire raster. |
| | 64 | |
| | 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. |
| | 66 | |
| | 67 | 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. |
| | 68 | |
| | 69 | '''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. |
