[postgis-devel] Deprecate ST_MapAlgebraExpr and ST_MapAlgebraFct

[dustymugs]

On 10/10/2012 04:23 PM, Pierre Racine wrote:
>>> Speed is not always the deciding feature...
>>>
>> You may come to regret those words... ;-)
> 
> I always prefer things that save me time over things that save computer time. For sure I prefer those that can do both, but if you think about how things were slow just some years ago. Imagine if someone would have said "we should not do it because it's too slow"... There would be no car, no internet, not many things actually. We would still be in prehistoric ages... I will never regret offering more functionality.
> 

Saving you time is NOT the same as "is the query done yet?"  For one-off
queries, saving you time is fine.  For something repeatable, query speed
is tantamount.

>>> 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...
> 
> Will be easier for them to say: let's use ArcGIS instead... Am I the only one working with non programmers here? I get plenty of people here able to write SQL statements but not able to write SQL functions. That another level of abstraction. You want your nice statement to be faster, now you have to learn how to write a plpgsql function...
>  
>> 2. user defined expressions are always a security weakness (SQL
>> injection) and there is no way we can say that this is impossible.
> 
> You are writing SQL, how can you inject SQL when you are writing SQL? It's like if you would say, there might be some C injection in my C code. Not much sense... 
> 

Since the expression is evaluated as an SQL statement, it can be
injected.  There is no injection for the keywords in the expression (due
to parameterization) BUT the expression as a whole can.

>> 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.
> 
> AFAIK there is no such thing as a neighborhood variant working with expressions. There are only custom function neighborhood ones because, as you mention, handling neighbor is far more complex then handling one pixel at a time.
> 

There isn't.  My big concern is the quantity of code floating around for
the various ST_MapAlgebraXXX variants.  Who's going to maintain it?

>> Basic tools should always be available in the API with some "generic"
>> advanced tools being provided for use in more specific applications.
> 
> What would that look like?
> 
> I strongly suggest we keep the two expression variants. They work very well and make life easier in many situations.
> 

Are you volunteering to maintain the expression variants?

-bborie