[postgis-users] pgchip

[strk at refractions.net]

I'm finally taking a look at pgchip myself, so I can answer
this old mail.

pgchip is "stuffing". Moreover, it's using a "future" field
of the CHIP structure to encode extra information. This
clashes with assumptions present in the canonical input
functions of postgis that prevent storing more info then
barely pixel_size*width*height in the "data" field.
Pgchip is indeed adding palette informations as well.

Generally speaking, a possibility we have to "chipping"
could be similar to what we use for TopoGeometry.
The Raster datatype could be a complex type referring
to a set of relations that contain "tiles" informations.
In this case a CHIP would be a single "tile", possibly
composed by a single raster band.

Operations on such a complex type would be - ehm - complex.

--strk;

On Fri, Dec 16, 2005 at 08:57:33AM -0800, Paul Ramsey wrote:
> Simon Benjamin has added a link <http://simon.benjamin.free.fr/pgchip/ 
> > to pgchip (we knew someone would do it eventually!) on the wiki  
> <http://postgis.refractions.net/support/wiki>.
> 
> Simon, one of the fiddlier problems with rasters once you get them  
> into the database is random access... for our *only* raster-in- 
> database project, we cut the rasters up into small chunks below the  
> page size, so that we could quickly pull together the chunks we  
> needed.  That meant that a single input raster could be exploded into  
> thousands of storage chips (hence the type name).  Are you chipping  
> or stuffing?  The trouble with chipping is that it requires a de- 
> chipper in order for the stored data to be at all useful (see, raster  
> in arcsde, which uses the same trick, and dechips in arcmap or arcims).
> 
> P.