[postgis-devel] Deprecate ST_MapAlgebraExpr and ST_MapAlgebraFct

Paragon Corporation lr at pcorp.us
Wed Oct 10 13:24:32 PDT 2012

I like it.


I think now is a good time to deprecate before people start heavily using
the current names.

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
Sent: Wednesday, October 10, 2012 4:03 PM
To: PostGIS Development Discussion
Subject: [postgis-devel] Deprecate ST_MapAlgebraExpr and ST_MapAlgebraFct

Hey all,

I'm planning on committing support for n-raster (and n-band) map algebra as
ST_MapAlgebra().  This new map algebra function only works on user-specified
callback functions as trying to support an expression-based n-raster with
neighborhood would be extremely cumbersome.  Think of the number of keywords
required if you have variable size neighborhoods and unlimited number of
rasters and bands...

I'd like to deprecate all variants of ST_MapAlgebraExpr, ST_MapAlgebraFct
and ST_MapAlgebraFctNgb in 2.1 with eventual removal in 2.2.  The use of
Expr, Fct, FctNgb suffixes is tedious and the variants for 1 raster and 2
rasters is confusing for users and horrible to maintain in the codebase.

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.

This simplification unifies everything and keeps things simple and stupid.



PS: Before anyone goes nuts, I don't plan on replacing the existing code for
Expr, Fct and FctNgb variants.  I'm only adding ST_MapAlgebra() for 2.1.
The Expr, Fct and FctNgb variants will be removed in 2.2.
postgis-devel mailing list
postgis-devel at postgis.refractions.net

More information about the postgis-devel mailing list