[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