[postgis-users] Re: Rasters

[Patrick]

"Paul Ramsey" <pramsey at refractions.net> wrote in message 
news:D5628771-98D0-467F-B201-E53AAA356383 at refractions.net...
> OK, raster people.  My problem is that I cannot envision the use  cases 
> for raster in the database, so, make it easy for me! :)
>
Hi Paul,

Let me try to enlighten you.

> - What is the atomic unit of storage for rasters in the database?  Is  it 
> complete scenes?  Something else?

The answer to this question is not an easy one. On an object-level the 
raster itself is the atomic unit. In other words, there should be something 
like a pg_rasters table, which lists stored rasters and which allows to 
select on global attributes like SRID, envelope, content, purpose, age, etc.

Below that level the raster is composed of bands that each are 2-dimensional 
arrays of some data type (IIRC they can be n-dimensional according to ISO 
and OGC, but the difference is essentially trivial). Bands define content 
more than anything else and they have no particular bearing on design or 
implementation. (Unless of course rasters are implemented having multiple 
band values represented as a composite type (not unlike 
band-interleaved-by-pixel, BIP).)

Band data will be stored in tiles which will very likely be the size of the 
db page. Applications wanting to read or write entire raster bands will do 
so in tile size chunks. Having a TILE(x, y) keyword in would be nice 
therefore:

SELECT TILE(0, 5) FROM myraster;

Below the tile is the pixel. For all practical purposes, pixels would never 
be manipulated inside the db, except in raster-level operations such as 
coordinate system conversion and resampling.

> - What is some SQL I would apply against my raster tables?  Make up  some 
> descriptive function names and show me some example SQL and tell  me what 
> it does.

See above. Think INSERT, UPDATE and DELETE. Basically, all of these apply to 
tiles of data. What is done to those tiles depends on the application.

> - How do vector data and raster data interact?  Note the atomicity 
> question above.
>
That is mostly up to the application. What would have to supported by the db 
is the standard set of geometrical operators: return those pixels that 
overlap with some geometry object, etc.

In general, I think that it would be best to start humble: manage raster 
data in tiles. PostGIS needs to store tiles and serve them up upon request. 
This, coupled with the standard DBMS functions of access control, 
concurrency control, and backup support, would already be a tremendous 
feature. Later more sophisticated options could be added, such as returning 
data from arbitrarily sized areas and resampling.

Hth,
Patrick