[postgis-devel] Deprecate ST_MapAlgebraExpr and ST_MapAlgebraFct
Pierre.Racine at sbf.ulaval.ca
Thu Oct 11 09:09:40 PDT 2012
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?
- 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).
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net [mailto:postgis-devel-
> bounces at postgis.refractions.net] On Behalf Of Bborie Park
> Sent: Thursday, October 11, 2012 9:25 AM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Deprecate ST_MapAlgebraExpr and
> On Thu, Oct 11, 2012 at 12:20 AM, Sandro Santilli <strk at keybit.net> wrote:
> > On Wed, Oct 10, 2012 at 04:00:36PM -0700, dustymugs wrote:
> >> On 10/10/2012 03:32 PM, Pierre Racine wrote:
> >> > That means no support for people not comfortable with writing a custom
> >> True. But maybe they just needed a reason to get into writing their own
> >> functions.
> > Could a way be found to allow for inline functions ?
> > Basically a way to accept function-or-expression as the argument
> > and convert the expression into a function internally.
> Converting expressions to temporary functions are doable.
> The question then becomes, should the expression be using keywords,
> e.g. [rast1]? Or should it look like the code one would expect in a
> > I'd like to see the number of signatures going down...
> Same here.
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
More information about the postgis-devel