<br><font size=2 face="sans-serif">I added geomval to the concept map on
the wiki page. Also added a section on it.</font>
<br>
<br><tt><font size=2>postgis-users-bounces@postgis.refractions.net wrote
on 07/22/2011 05:48:24 PM:<br>
<br>
> Some observations:<br>
> [...]</font></tt>
<br>
<br><tt><font size=2>I think you mistook my intent. I want to show people
that if they intend to do the "obvious" thing, meaning to think
of a table as a raster coverage the same way that a table has been taken
to be a vector coverage for years, there are a few caveats. </font></tt>
<br>
<br><tt><font size=2>How you think of the table depends on what you're
doing with the table. </font></tt>
<br>
<br><tt><font size=2>> This distinction disappear if you do something
like this on a raster<br>
> coverage to produce a very different kind of raster coverage being
<br>
> something very new in the GIS world and having, really, no <br>
> distinction with a vector coverage: CREATE TABLE rastcov AS SELECT
<br>
> ST_AsRaster((gv).geom, 1), (gv).val FROM (ST_DumpAsPolygons(rast)
<br>
> gv) foo. (Note that ST_AsRaster() is still to be implemented). The
<br>
> result is a raster coverage, composed of a series of rows acting <br>
> exactly like a vector coverage but in which the geometries are <br>
> stored as small (or bigger) rasters. You might prefer to work with
<br>
> this kind of object if you really want your raster coverage to have
<br>
> the exact same characteristics of a vector coverage (one geometric
<br>
> area per row value).</font></tt>
<br>
<br><tt><font size=2>So essentially you're proposing to create one raster
for every distinct pixel value in the raster? Each raster being a "mask"
containing the locations of it's one value. And you want to select the
distinct pixel values first by creating polygons which outline the pixels
for each value, then converting each individual geometry back into a mask
containing only "nodata" or the value in question.</font></tt>
<br>
<br><tt><font size=2>I think it might be faster to use ST_Reclass(), provided
there was some "ST_DistinctValues(raster)" method.</font></tt>
<br>
<br><tt><font size=2>Could I request a "ST_AsRaster(setof geomval)
returns raster" which acts as the inverse of ST_DumpAsPolygons? So
if you did ST_AsRaster(ST_DumpAsPolygons(rast)), you'd get your original
raster back? That's more along the lines of what I'd expect. That way,
you can take the raster apart into geometries, edit them, then get a new
raster back. I was kind of assuming that was what ST_AsRaster did...</font></tt>
<br><tt><font size=2><br>
> "The third observation is that a "raster coverage"
does not need to <br>
> be backed by a table at all. A single raster item could provide all
<br>
> of the data required." Totally agree, but storing a raster coverage
<br>
> in PostgreSQL as a multi row table give some major advantages: 1)
<br>
> You get fast gist indexing of the tiles for (almost) free, 2) You
<br>
> can store coverage of (theoretically) 32 TB, 3) You don't have to
<br>
> provide tiles for all the covered area, 4) tiles can overlap, 5) <br>
> Tiles can have different dimensions, 6) implementation was relatively
easy.<br>
</font></tt>
<br><tt><font size=2>The point was that any of the "aggregation"
functions (or mapalgebra) could produce something for display or analysis
by returning an item with the "raster" data type. It need not
be stored in a table before being displayed or used in the next processing
step.</font></tt>
<br>
<br><tt><font size=2>Note that if one is trying to consider a table to
be a single raster broken into rows, #3 #4 and #5 are disadvantages. Extra
care must be taken to constrain the flexibility those items provide. Calling
attention to this fact is the point of the wiki page.</font></tt>
<br>
<br><tt><font size=2>The reason is: the "raster coverage" itself
has metadata which pertains to the coverage as a whole. If a "row
raster" is to be considered to belong to a "raster coverage",
it must conform to the "raster coverage metadata". Including:</font></tt>
<br>
<br><tt><font size=2>* location of a corner pixel</font></tt>
<br><tt><font size=2>* pixel size in each dimension</font></tt>
<br><tt><font size=2>* number of pixels in each dimension</font></tt>
<br><tt><font size=2>* number of bands</font></tt>
<br><tt><font size=2>* types of bands</font></tt>
<br><tt><font size=2>* srid</font></tt>
<br>
<br><tt><font size=2>These are recorded in "raster_columns",
along with the column extent. Each row must conform to all of these criteria,
and the extent of the "row" must be contained within the extent
of the column. Failure to comply means the row rasters cannot be aggregated
in a simple way to form a larger "raster coverage": they must
be resampled onto a common grid before display or processing.</font></tt>
<br>
<br><tt><font size=2>Clearly, if you don't consider the rows to be part
of a larger coverage, then this does not apply.</font></tt>
<br>
<br><tt><font size=2>> <br>
> "Clearly, a table with a raster column could be used as an index
<br>
> into many unrelated rasters. This is a legitimate use of the table
<br>
> facility. However, it is an example of a table which could not be
<br>
> used to provide information to a "raster coverage." I totally
agree <br>
> with your conclusion. It is possible to use PostGIS raster this but
<br>
> it is also very possible to use it in a clever way. </font></tt>
<br>
<br><tt><font size=2>Again, the point is that it's perfectly valid to use
it this way. It's not wrong, and it's not un-clever. If you need an index,
take advantage of the flexibility offered by #3, #4, and #5. The advantage
of doing so is that you do not have to create a new table for each "type"
of raster. For anything other than the most trivial of cases, that will
become unmanageable.</font></tt>
<br>
<br><tt><font size=2>In addition to the "index" case, it is perfectly
acceptable to consider a table to be a "raster type definition".
The table may then contain many raster coverage instances belonging to
the same type. However, you still cannot aggregate rows belonging to different
raster coverages into some "hybrid raster coverage". </font></tt>
<br>
<br><tt><font size=2>For example, define a table to contain "Landsat
Band 2" images. Columns are "raster, path, row, date". (Path
& row is a coarse global grid used by landsat to describe the location
of a scene. Two scenes over the same path, row cover the same area.) Insert
one scene over a given path/row; divide it into 1000 rows just for kicks.
16 days later, you get another scene with the same path/row and load it
into the database using 1000 rows. </font></tt>
<br>
<br><tt><font size=2>You must guard against combining rows from different
scenes. All queries have to select for path, row, date. This is also legitimate
if this is what you need to do. But it puts the onus on the user to be
aware of the subtleties to ensure they achieve the expected results.</font></tt>
<br>
<br><tt><font size=2>So we have two ways of using a table, and the user
needs to be aware of the subtleties of both:</font></tt>
<br>
<br><tt><font size=2>* The table stores more than one raster coverage.
(e.g., "raster type definition", "index of unrelated images")
Here the user must ensure row data from different coverages are never mixed.</font></tt>
<br><tt><font size=2>* The table stores only one raster coverage. Here
the user does not have to worry about mixing coverages.</font></tt>
<br>
<br><tt><font size=2>Vector coverage tables are rarely used to store multiple
coverage instances, but if they are, there is no technical obstacle to
combinining elements from different coverages. There is an obstacle with
inhomogeneous rasters. Vector coverage tables do not sport a grid definition,
so the grid definitions of individual rows do not need to be compatible.
Raster row data which are part of the same collection must ensure their
grid definitions are compatible.</font></tt>
<br>
<br><tt><font size=2>Bryce</font></tt>