[postgis-users] Coverages and PostGIS wiki page

[Pierre Racine]

Some observations:

Implication 1: There is a tool called ST_DumpAsPolygons(rast) in PostGIS raster which convert, on the fly, a raster coverage into a vector coverage with one geometry associated with one value (it certainly has to be enhanced to return the many values associated with the many bands a raster might have). If implication 1 stand for a brut PostGIS raster coverage, it does not stand for the result of the table produced by this operation applied to the entire raster table. This is how a raster table is converted, when necessary, to a vector coverage, one geometry per value. This conversion, more over, add meaning to a raster coverage by aggregating pixel areas sharing a common value, meaning which is not available in a mere raster coverage.

Implication 2: As you mention, insuring consistency between rows is easy to do with constraints. You may note that it is also possible in PostGIS to construct an inconsistent vector coverage having, in different rows, vector with different srid or different dimensions.

Implication 3: We can consider the additional columns block metadata or block common values. You might want to include them in the result if they represent a meaning at the pixel level or not if they don't. 

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


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

This make that you can quickly and literally dump a set of images, overlaping or not, some area missing or not, in a table and start working. You don't have to build a perfect rectangular area with 2000 rasters (SRTM for example) before loading them in the database.

If one can provide the same functionality with a one row raster coverage, I would be glad...

"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. A very similar remark can be done for a vector coverage: You can store a perfectly topological vector coverage in PostGIS raster as you can store a very spaghetti one. It is your responsibility to build something meaningful.

To quickly answer your question "what is the meaning of a table when it has these column types?" "what does a row represent?" A row might not represent something significant but a table does. If you pass any row through ST_DumpAsPolygons() then a row becomes something significant. The fact that a row does not mean something does not prohibit us from storing raster data in many rows. It is just a storage artifact. As a whole, a many rows raster table does not have less meaning than a one row raster coverage... What is so important in having a whole raster coverage in one row? The attributes you will append to this row won't provide you more meaning than the one you can add to each row in a multi row one. And you will have to struggle to provide the same characteristics as we have in the many row one (32 TB, overlaps, different shapes, possibility of missing tiles, quick indexing).

However having a tiling mechanism at the tile level would certainly enhance performance when tiles are big. Granted.

Pierre

> -----Original Message-----
> From: postgis-users-bounces at postgis.refractions.net [mailto:postgis-users-
> bounces at postgis.refractions.net] On Behalf Of Bryce L Nordgren
> Sent: Thursday, July 21, 2011 8:08 PM
> To: postgis-users at postgis.refractions.net
> Subject: [postgis-users] Coverages and PostGIS wiki page
> 
> 
> I just wrote a little deal which tries to tease out differences and similarities
> between raster/vector types using "coverage" concepts. I tried to be
> nontechnical. There's a pictorial "concept map" at the beginning too.
> 
> There's a temptation to gloss over the differences and just say "use raster as a
> column type the same way you'd use a geometry type". That won't work, as the
> differences are subtle but important.
> 
> The crux of the article/tutorial/thingy is "what is the meaning of a table when it
> has these column types?" "what does a row represent?" etc.
> 
> Check it out and edit it to your heart's content.
> 
> http://trac.osgeo.org/postgis/wiki/UsersWikiCoveragesAndPostgis
> <http://trac.osgeo.org/postgis/wiki/UsersWikiCoveragesAndPostgis>
> 
> Bryce