[postgis-tickets] [PostGIS] #2341: [raster] ST_MapAlgebra mask parameter

[PostGIS]

#2341: [raster] ST_MapAlgebra  mask parameter
-------------------------+--------------------------------------------------
 Reporter:  nclay        |       Owner:  dustymugs    
     Type:  enhancement  |      Status:  new          
 Priority:  medium       |   Milestone:  PostGIS 2.2.0
Component:  raster       |     Version:  trunk        
 Keywords:               |  
-------------------------+--------------------------------------------------

Comment(by nclay):

 Replying to [comment:6 dustymugs]:
 > Replying to [comment:4 nclay]:
 > > That is what I had in mind. I am sill working on it and should have it
 ready for testing, by Monday. I have the raster iterator done and its
 pixel fetcher done that considers of a mask. When you say that "Existing
 distancex and distancey variants will be changed to run on top of the mask
 variants since the mask ones are more flexible." My current code has it
 where if the Mask parameter is null then the "old code runs", and if a
 Mask is provided the 'new code is run'. Are you saying that, the code
 should be cleaned up so that we create a mask,
 > > {{{
 > >
 > > mask = ARRAY[
 > >   [1, 1, 1],
 > >   [1, 1, 1]
 > >   [1, 1, 1]
 > > ]
 > >
 > > }}}
 > >
 > > To be passed mimicking the old behaviour? Or is the current branching
 behaviour acceptable?
 >
 > How are you defining the SQL-level ST_MapAlgebra() function to do the
 branching? If you're just appending the mask parameter to existing
 function signatures, that is messy and redundant.
 >
 > As part of what I envision, the changes would also require changing
 RASTER_nMapAlgebra() in rt_pg/rt_pg.c and rt_raster_iterator() in
 rt_core/rt_api.c to operate upon masks instead of distances. Because of
 the deep changes, I don't think a separate band pixels by mask getter
 function is needed. A alternative approach would be a general utility
 function that operates on a values array based upon a mask array.
 >
 > So, crudely thought out.
 > {{{
 > rt_errorstate
 > rt_util_pixel_mask(rt_pixel *pixels, int npixels, double precision
 **mask, int dimx, int dimy, int weighted)
 > }}}

 What about considering the mask in rt_pixel_set_to_array? That would save
 us some iterations over the pixels.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/2341#comment:9>
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.