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

 My comments are interspersed...

 Replying to [comment:5 nclay]:
 >
 > 1. We are on the same page ALL  masks are valid except for irregular
 (jagged).
 > {{{
 > mask = [
 > 1,1,1,1
 > 1,1
 > ]
 > }}}
 >
 > Would be Invalid.
 >

 Correct. Not to mention that PostgreSQL does not permit ragged arrays.

 > 2. Yes that was a kluge of an Idea, to add padding. However what came of
 it is that it, was an idea that it would be nice to have a way of
 expressing that you dont want a cell to be considered or returned at all.
 This has its limitations mainly to sparse masks and spatially irrelevant
 operations. An concrete example yet not very useful would be:
 > {{{
 > mask = [
 > 3.14,-,-,-,3.14
 >  -,-,-,-,-
 > 3.14,-,-,-,3.14
 > ]
 > poi = [3,2]
 > }}}
 >
 > This would return a 1D  a  array containing the values from the four
 corners of the mask multiplied by their respective weights, also the value
 at the poi would be returned for the common case where you would like to
 poi -,+,*,/ aggregate function.
 >
 > This would be applicable to HAAT, where you are only really concerned
 with the values along 8 radials ( every 45 degrees ) from 2 to 16 km. Yes,
 currently you could pass in an mask array with nulls and receive a array
 with nulls in the respective positions but that is a lot of nulls to be
 only ignored when passed to an aggregate such as avg(). Why not through
 them out early on if the user explicitly ask for that? I would value your
 opinion on this.
 >

 Isn't the usage of dash (-) the same as using NULL to indicate that that
 pixel should be ignored?

 Convert that 2D array to a 1D array? How do we specify placement (e.g.
 left to right, top to bottom) and why (e.g. why left to right, top to
 bottom instead of bottom to top, right to left?)? I think there will be
 too many assumptions made here and this would be non-obvious to end-users.

 As for "Why not through them out early on if the user explicitly ask for
 that?", my response would be: What did the user explicitly ask for? (Yes,
 question with a question. But I have an answer! ;-)

 From what the user has provided as input (assuming the current proposed
 mask composite type), we only know that the user wants to act upon those
 pixels indicated in the mask. We copy the mask structure for creating the
 value array to prevent confusion. One way to let the user decide to have a
 compact value array would be to add another boolean parameter to the
 proposed mask composite type...

 {{{
 compact = BOOLEAN
 }}}

 I think we're on the same page on this.

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