[postgis-users] Coverages and PostGIS wiki page

[Pierre Racine]

> > This distinction disappear if you do something like this on a raster
> > coverage to produce a very different kind of raster coverage being
> > something very new in the GIS world and having, really, no distinction
> > with a vector coverage: CREATE TABLE rastcov AS SELECT
> > ST_AsRaster((gv).geom, 1), (gv).val FROM (ST_DumpAsPolygons(rast)
> > gv) foo. (Note that ST_AsRaster() is still to be implemented). The
> > result is a raster coverage, composed of a series of rows acting
> > exactly like a vector coverage but in which the geometries are stored
> > as small (or bigger) rasters. You might prefer to work with this kind
> > of object if you really want your raster coverage to have the exact
> > same characteristics of a vector coverage (one geometric area per row
> > value).
> 
> 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.

Yes. This is a very new type of raster coverage, in this case having essentially the same characteristics of a vector coverage. It might not be suitable when the raster coverage is very continuous (ie pixel values vary a lot) but it might be suitable for other kind of coverages. I presented this new type of raster objects coverage in slide 18 & 19 of my last year FOSS4G presentation:

http://trac.osgeo.org/postgis/attachment/wiki/WKTRaster/FOSS4G2010_Pierre.pdf

It is important to note that even though it is now possible, with the implementation of ST_AsRaster, to create such a raster coverage in PostGIS, it is certainly not necessary. We will see if some people find it useful.

> 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...

This is ST_UnionToRaster(set of geometry) planned since a while but added to the specifications only recently:

http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking03

> > "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." Totally agree, but storing a raster coverage in
> > PostgreSQL as a multi row table give some major advantages: 1) You get
> > fast gist indexing of the tiles for (almost) free, 2) You can store
> > coverage of (theoretically) 32 TB, 3) You don't have to provide tiles
> > for all the covered area, 4) tiles can overlap, 5) Tiles can have
> > different dimensions, 6) implementation was relatively easy.
> 
> 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. 

Do you mean "aggregation" functions in PostgreSQL terms? ST_MapAlgebra is not an aggregate function... What do you mean by "aggregation" functions?

ST_MapAlgebra does returns a raster type...

> It need not be stored in a table before being displayed or used in the
> next processing step.

It doesn't have to...

> 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.

They are only possibilities. Possibilities are always considered advantages or desadvantages depending on the application you want to implement. Easily being able to import a coverage with overlapping tiles is certainly a big advantage in some situations/applications. For sure, like for a vector coverage, people have to know what they put in the database. The same way you can import a non topological vector layer and mess with it doing analysis, the same way you can import a messy raster coverage and mess with it. It is just our duty to provide them with tools so they can get where they want as efficiently as possible. Don't be too much biased by your own application.

> 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:
> 
> * location of a corner pixel
> * pixel size in each dimension
> * number of pixels in each dimension
> * number of bands
> * types of bands
> * srid
> 
> 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.
> 
> Clearly, if you don't consider the rows to be part of a larger coverage, then this
> does not apply.

Agreed. To form a workable raster coverage each row must conform to those constraints. And those constraints are not in opposition with 3), 4) and 5).

> > "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." I totally agree with
> > your conclusion. It is possible to use PostGIS raster this but it is
> > also very possible to use it in a clever way.
> 
> 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.

I agree. It's just that if you read about the original intent of PostGIS raster, it was not planned to optimize this kind of application (storing many raster coverage in one table), even though it is still very possible. It is planned to optimize one raster coverage per table which I think fits more GIS analysis applications (in opposition to data warehouse applications). I see your role as the one who could optimize the handling of one-row big rasters... (hopefully not at the cost of "downtimization" of the one raster coverage per table :)

By clever I mean one theme per table... Which correspond more to our familiar way of using GIS.

> So we have two ways of using a table, and the user needs to be aware of the
> subtleties of both:
> 
> * 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.
> * The table stores only one raster coverage. Here the user does not have to
> worry about mixing coverages.

I could identify 6 different ways to store rasters in PostGIS raster. Did you ever have a look at figure 1 in section 3.1.2 in the beta documentation:

http://trac.osgeo.org/postgis/wiki/WKTRaster/Documentation01

These are all possible arrangement. People have to be aware of the implications of the arrangement they use.

Pierre