[postgis-users] Proposed SQL interface for PGRaster

[Webb Sprague]

Hi

On 12/5/06, Mark Cave-Ayland <mark.cave-ayland at ilande.co.uk> wrote:
> On Tue, 2006-12-05 at 12:39 -0500, Stephen Marshall wrote:
> > I have written a proposal for the SQL interface to PGRaster, a
> > raster-in-DB implementation. [...]

(1) Use cases:  Perhaps I am a bit "off", but I was wondering if we
should write a few use-cases for this?  I think your pg_raster_to*
functions imply some use-cases, but it would be nice for us
touchy-feely types to get a more human interface discussion going,
especially with respect to how we would import, analyze, and export
raster data, in a gmt or mapserver context probably.

(2) Internal format: I wonder if it wouldn't be better to decide on an
internal format and just write conversion functions.  It would have to
be a format that can handle an infinite number of bands, multiple (but
finite) levels of granularity, have good compression, perhaps do some
sort of caching, and deal gracefully (somehow) with the lossy vs
non-lossy issue. Mr Sid is an interesting elaboration on this idea,
but I don't know enough about it or free analogues to say anything
more.

(3) Tiling and views: It might be worthwhile to think about having
every raster be a set of 1 or more tiles (pgChip type?), probably of
an optimized size, and have the user level functions deal with views
of this set.  For example, a get_raster(raster_name, polygon_bound,
output_type=tiff) would automagically assemble the correct pieces from
the correct tiles and generate a single raster from a set of tiles
that are referenced by the single name "raster_name". An insert
statement would disaggregate into tiles and store metadata
appropriately.

(4) I don't think I would have multiple insert options, at least at
the user level (who I assume to be smart DBA).  I think a single
paradigm is best, if possible.

Cheers, and thanks for taking the lead on this!

W