[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 nclay):

 Dustymugs,

 My first thought was to do the padding calculation at the C level or even
 doing offsets, although No-Op padding at the SQL level does intrigue me
 and may have use-cases.

 One useful example the calculation of FCC  HAAT ( Height Above Average
 Terrain ) as it would generate a very sparse mask array with the minimum
 radials and even the maximum radials depending on your data-set
 resolution, this  however would also require a center value or poi value
 to be returned as that value would not be readily locatable in the
 returning array.

 Another use case would be with an wedge annulus with the operations of
 sum() , avg(), etc. An updated ST_TPI with a user defined focal radius,
 would also benefit as well.  Again this would require the poi value to be
 also returned separately. No-Op in both cases would greatly reduce the
 size of the array returned, also I believe that this is one of the bottle
 necks in translating arrays.  Does the size of arrays effect the
 performance of translating arrays and would returning an extra value
 negate the performance gain?

 Maybe we should consider this at the SQL level as it would give a good
 option, for problems with sparse and spatially irrelevant mask
 calculations, mainly aggregate functions.

 As for the mixed array problem, when we currently use a non-weighted array
 we really are wanting to use and Integer but are forced for the same
 reason to cast it to a double precision, why could we not have the mask
 array be text and at the C level cast it to the appropriate type or set
 the appropriate bits? All we would be adding is an another look up on top
 of ones we already have to do and the overhead of casting mask elements
 from text to double once per MapAlgerbra call. Am I missing something
 significant that would negate the possible benefits to our users to not
 add this feature/option?

 Thanks,

 Nathaniel Hunter Clay

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