[postgis-devel] [raster] About recent commit r8313

dustymugs dustymugs at gmail.com
Wed Dec 7 10:20:01 PST 2011


On 12/07/2011 10:13 AM, Chris Hodgson wrote:
> I listened with some surprise to the earlier discussions about removing
> regular blocking, but remained silent as I didn't have the time to
> really think about it. But I'd like to lend my support to Mateusz's
> complaint... is it truly wise to throw away the opportunity to optimize
> this case? In my work with rasters, all of the other "random bunch of
> rasters" use cases are just a stepping stone on the way to "the one"
> complete, regularly blocked/tiled dataset. The regularly blocked raster
> is the one that needs to be fastest, as it is the one that end users
> would be most likely to render maps from. Plus, it is the one with the
> most potential for optimization. Frank's a pretty smart guy, he's been
> doing rasters since before PostGIS was a gleam in our collective eye, I
> wouldn't bet against him on this.
>

The regular_blocking isn't going anywhere.  The problem in the earlier 
discussions was being able to enforce regular_blocking on a raster 
column.  Since there is no way to enforce regular blocking at the 
present time (and probably not until 2.1), the question was whether or 
not to keep the regular_blocking column in the constraint-based 
raster_columns view.

Since there is no way to check that a raster column is regularly 
blocked, the user is provided an method to set an informational 
("garbage") constraint indicating that a raster column is regularly blocked.

Once the logic is available to check that a raster column is regularly 
blocked, the informational constraint will become a real table/column 
constraint.

-bborie



More information about the postgis-devel mailing list