[postgis-devel] Deprecate ST_MapAlgebraExpr and ST_MapAlgebraFct

[dustymugs]

On 10/10/2012 03:32 PM, Pierre Racine wrote:
>> As for removing expression-based map algebra, historical testing showed
>> that performance of callback functions was consistently faster than
>> expressions (even with use of prepared statements).  Not to mention the
>> ease of debugging a function rather than an expression where the problem
>> could be in the user's expression or how that expression is parsed.
> 
> Speed is not always the deciding feature...
> 

You may come to regret those words... ;-)

> That means no support for people not comfortable with writing a custom function...
> 

True.  But maybe they just needed a reason to get into writing their own
functions.  Just like users of MS Excel or any stats software end up
having to write their own functions...

On the other hand are the many problems with user-defined expressions.

1. If there is an error, is it due to the expression or the expression
parser?

2. user defined expressions are always a security weakness (SQL
injection) and there is no way we can say that this is impossible.

3. expressions only work in the simplest of cases.  How many keywords do
you need for handing a set of 5x5 neighborhoods from 5 input rasters?
That would mean 125 parameters to substitute, not to count X,Y pixel
positions from each input rasters and output raster.

> There are also a bunch of function dependent on the expr variant: 
> 
> -ST_Intersection(raster, raster)
> -ST_Clip(raster, geom),
> 

These should be refactored to use the new ST_MapAlgebra.

> It is now the most efficient way (that I know) to change the pixel type of a band:
> 
> ST_MapAlgebraExpr(rast, '32BF', '[rast]') rast
> 

Is worthy of a whole new function...

ST_ChangeBandType(raster, newpixtype)

> When I consider all the easy things I can do with the expr variant and I think about the dozens of custom functions I will have to write... I guess we will have to provide many basic ones. And maintain them...
> 

Basic tools should always be available in the API with some "generic"
advanced tools being provided for use in more specific applications.

-bborie