[postgis-devel] [PostGIS] #2030: [raster] n-raster ST_MapAlgebra

[PostGIS]

#2030: [raster] n-raster ST_MapAlgebra
-------------------------+--------------------------------------------------
 Reporter:  dustymugs    |       Owner:  dustymugs    
     Type:  enhancement  |      Status:  assigned     
 Priority:  medium       |   Milestone:  PostGIS 2.1.0
Component:  raster       |     Version:  trunk        
 Keywords:               |  
-------------------------+--------------------------------------------------

Comment(by dustymugs):

 Replying to [comment:7 pracine]:
 > Replying to [comment:6 dustymugs]:
 > > distancex and distancey are for passing neighborhoods to the callback,
 not just the pixel value of interest.
 >
 > So you will replace ST_MapAlgebraFct (1 band version), ST_MapAlgebraFct
 (2 band version) and ST_MapAlgebraFctNgb (1 band version). Right?
 >

 Correct

 > Are the existing signatures going to be mapped to the new function or we
 will have to rewrite all our custom functions?
 >

 Existing signatures will still stay the same.  The custom functions will
 need to be rewritten though.

 > > customextent is so that the user can specify an extent that they want.
 It is in essence a filter and as a side-affect permits correct coverage
 handling.
 >
 > Can we call it a "mask"?
 >
 > In essence your multiband MapAlgebra is really what it is, a multiband
 map algebra. But I would add "intra-raster" multiband meaning the main
 goal is to do a computation involving many bands generally from the same
 raster. I can not think, and you did not show an application, where, say,
 three rasters would come from three different raster tables involving two
 joins and a multitude of possible resulting extents. My point here is to
 ask: Why not making a simpler multiband mapalgebra working only on the
 bands of a same raster? No need to pass many rasters (just an array of
 band index) and hence no need to create a new type. A much simpler
 function signature. No hassle with the possible extent since they are
 always identical. No braking of the existing mapalgebra (which work very
 well right now)... I generally tend not to complexify things if I don't
 have a useful user case. And I don't think it would be efficient and wise
 to join three raster coverages.

 Multiband (intra-raster) does work with my current signature.  I've tested
 the memory usage of passing the same raster twice in the same function
 call.  Both arguments point to the same memory space.  Adding another
 function signature to do multiple bands of one raster would just be a
 wrapper around the one signature.

 The reality is that none of us know all possible use-cases.  The core
 iterator function (rt_raster_iterator()) is written to be generic and be
 as flexible as the can be.  Hence why I'm implementing the SQL functions
 to maintain that flexibility.

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/2030#comment:10>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.