[postgis-users] Proposed SQL interface for PGRaster

[Craig Miller]

I second all of these suggestions, especially the suggestion to assume that
all rasters are tiles a la pgChip.

--Craig
 

> -----Original Message-----
> From: postgis-users-bounces at postgis.refractions.net 
> [mailto:postgis-users-bounces at postgis.refractions.net] On 
> Behalf Of Webb Sprague
> Sent: Tuesday, December 05, 2006 10:55 AM
> To: PostGIS Users Discussion
> Subject: Re: [postgis-users] Proposed SQL interface for PGRaster
> 
> 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
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users