[postgis-tickets] [PostGIS] #2617: [raster] Enhanced mask object for raster map algebra

[PostGIS]

#2617: [raster] Enhanced mask object for raster map algebra
-------------------------+--------------------------------------------------
 Reporter:  dustymugs    |       Owner:  dustymugs     
     Type:  enhancement  |      Status:  new           
 Priority:  medium       |   Milestone:  PostGIS Future
Component:  raster       |     Version:  trunk         
 Keywords:               |  
-------------------------+--------------------------------------------------

Comment(by dustymugs):

 Replying to [comment:7 nclay]:
 > Isn't the usage of dash (-) the same as using NULL to indicate that that
 pixel should be ignored?
 > No, a NULL indicates that a NULL should be returned. A (-) indicates an
 effective skip, eg do not return anything at all. However with the
 purposed compact option a NULL could be used here to indicate the same.
 >

 Effective skip = no value = NODATA? So what would the callback function
 receive? From what I can see in the code, NULL values in the mask set the
 nodata flag to true for that position in the mask.

 > Convert 2d array to 1D array, placement and why.
 > The reason in my mind to convert the 2D array to a 1D array is to make
 it abundantly clear that when you compact a mask, you loose effective ways
 (other than counting cells and that would be determined by implementation)
 of predetermining placement of values within the returning array. This
 would be done to allow for easy building of a array or list of poi's to be
 returned (at the C level) with little regard for order as some rows would
 have x values and others may have y values and another may have m
 values... The only predetermined placement of a value in the 1D array
 would be the last value in the 1D array being the specified, poi value.
 In my mind.
 >

 I find the lack of a high degree of obviousness disconcerting and leaves
 me with significant reservations of the compact mode.

 > This is a new topic:
 >
 > {{{
 > poiList = [ [0,0,3.l4],[0,4,3.14],[2,0,3.14],[2,4,3.14]]
 > eg.
 > poilist = [[x,y,mValue],...,[poix,poiy,1]]
 > }}}
 >
 > Furthermore, I think we should move toward a list of poi's, so that we
 can do optimizations for sparse masks. Such as presetting dominate
 determinable values like 0 or NULL using memory setting.  Thus only
 iterating over masks values that are non-deterministic.
 >

 An interesting idea that should require a significant amount of thinking.
 It does sound like it is ideal for the sparse situation.

 > However, idea should be carefully weighed and planed, as to not
 detrimentally affect the performance of dense masks. This may come down to
 a user definable optional hint:
 > {{{
 > sparse = BOOLEAN
 > }}}
 > when not specified (NULL) the MapAlgebra will try its best to determine
 whether to preset values or not and compress the poi list ( I am not
 saying to dynamically compress the output array just the internal
 representation of the mask. ) eg. dropping  the deterministic values from
 the poi list and setting the dominate deterministic value in the output
 array prior to iterating over the poiList.
 >
 > An example would be: A weighted mask with a large population of its
 cells set to 0, lets say greater than 50%. This analysis could be done
 while building the poiList from the mask.
 >
 > Also, If the returning of a 1D array when compacted is a sticking point
 for you then I can live with returning a 2D array then too. However you
 would have the issues as stated above.

 Traversing an array is always O(N) where N is the number of elements. A
 smaller array can be traversed faster than a larger array.

 I'd suggest creating a new ticket for discussing the list of POI approach
 as that is completely more radical and a more appropriate alternative to
 having compacted masks.

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