[postgis-users] Basic postgis raster questions

[Pierre Racine]

> >I may be missing the boat here, but it seems to me that a version of
> >ST_Intersection() which returns a raster would eliminate the need for a
> >separate geometry parameter, and would be more in line with the spirit
> >of "seamless vector/raster" processing. It also would seem that your
> >separate geometry parameter would behave very much like a
> >raster-returning ST_Intersection(), except that it is only usable "vicariously" via
> the stats functions.
> 
> Right. It would even be of greater value for other functionalities even if, I think,
> it would be slower for the particular case of computing stats .

Sorry but I must come back on this.

This is true when the vector area is small in comparison with the raster area AND if the raster coverage is tiled. In this case vectorization is possible and provide results very fast. This is true also if the raster is not tiled but is small. This operation provide very precise numbers because the intersection is done in vector mode and every pixel are cut when necessary. What you get is not a mere count of the pixels intersecting "a la Starspan" but true areas.

In the other case (if the vector area is big in comparison the raster area OR the raster is big and not tiled) the all vector method is catastrophic as you have to vectorize many time large parts of the raster and this become unpracticable. This is why we need a pixel counter (ST_Histogram) accepting geometries. The provided result are somewhat coarser (take all the pixel or nothing) and provide a "a la Starspan" result, but at last, provide a result in reasonable time.

This is why we need ST_Histogram, ST_SummaryStat, etc., accepting a geometry as parameter.

Pierre