[postgis-devel] Speeding up ST_Intersects(raster, geometry)

[Paragon Corporation]

Pierre,
> Another approach (which correspond probably more to what you have in mind)
is:

> 1) intersect the geometry with a grid of point representing the pixel
centroids of the raster (fast enough)

> 2) scann each of the resulting points for the presence of a withdata value
using the upcoming ST_Value(point) (I don't know the speed of ST_Value)

> This is certainly much easier/faster to implement. Is it faster?
Using ST_Value in SQL/PLPgSQL is slow for the same reason that ST_PointN and
ST_GeometryN are slow (its that going into the PostGIS/Raster boundary that
gives a high penalty more so than calling native PostgreSQL functions like
array functions).  
If you really want this kind of thing easy and fast to do in plpgsql, you
need 
An ST_Value that will return blocks of pixel values rather than a single
value.

If we go with simple extents then maybe something that returns an array of
pixel values given a col_start, col_end, row_start, row_end,.


> In the end I dont think this prevent us from implementing some sort of
caching for the presence/absence of nodata values in the raster (proposal 3
or 4). Which proposal do you prefer? The same way at some point we will have
to cache some statistics of the values (max, min, mean) (and upgrade the WKB
specification).

I think it's a bit premature to define a ContainsNoDataValue bit since we
really don't know how slow the processing we are doing is and as you say it
take up an extra free bit.  I also question the value of it.  Seems more
useful to be able to discard a raster tile entirely or just check or
polygonize/rasterize the shared extent as you mention.

That could provide enough gain that these extra bits are unnecessary.

Putting too much emphasis on NoDataValue bothers me too as I would think
that might change depending on the analysis you are doing.

Do you care about presence of swamp grass intersecting your geometry or soil
etc.  Then in that case pixel value ranges are most important.


Thanks,
Regina