[postgis-devel] Deprecate ST_MapAlgebraExpr and ST_MapAlgebraFct

[Bborie Park]

On Thu, Oct 11, 2012 at 9:09 AM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca> wrote:
> Just three comments:
>
> - Reducing the number of signature: yes! but not at the cost of functionality. The nice feature here is "Being able to do map algebra on one or two rasters WITHOUT having to write (or learn to write) plpgsql functions. Quick and easy and not novice first attempt killer.
>
> - Maintenance: Isn't there a way to integrate another way to compute pixel values (i.e. by having PostgreSQL to evaluate an expression instead of calling a custom function) in the same iterator? And otherwise. what kind of maintenance will be needed? The function is very stable. And if we were not to do things because we don't know who will maintain them in the future, should we just stop writing open source software?

I see you've never looked at the C 2 raster map algebra code.  I wrote
one function that juggles either four possible expressions as
parameterized queries or one regprocedure function.  The expression
based chunk is significantly more error-prone.

The problem is that for the Fct and Expr variants, there are four
separate C functions (three for 1-raster and 1 for 2-raster) that are
independent of each other.  That's a whole lot of monolithic C code
that needs to be maintained.

>
> - This is not an argument to keep the expression variants but only a defense of its signature: Did we think about the fact that this kind of signature (the two raster one: ..., expression, nodata1expr, nodata2expr, nodatanodataval) is probably our only way to get enough information to eventually optimize the iterator (by copying chunk of values when some of the nodata1expr, nodata2expr, nodatanodataval resume to [rast1], [rast2], or a constant) in the case the UNION of the extents, the extent of the first or the extent of the second raster is requested? There is no way for the iterator to know what the custom function do in this situation, but we can with this kind of signature (or probably a similar one using keywords instead).
>

I currently plan on doing as strk suggests, use temporary functions
generated before passing to C for actual operation.  The iterator
should NEVER know what the custom function passed to it will do
because it can NEVER assume that it can know.  The same is true for
ANY expression.  For cases where you control EVERYTHING, sure but that
is such a small percentage of all possible use caes.  But for
something as generic as map algebra, everything needs to be generic.
Once something generic is in place, then it is worth looking for speed
improvements for specific cases, such as ST_Union.  We're nowhere near
there yet.

-bborie