[postgis-devel] [PostGIS] #590: [raster] Two rasters version of ST_MapAlgebra

[PostGIS]

#590: [raster] Two rasters version of ST_MapAlgebra
----------------------------+-----------------------------------------------
 Reporter:  pracine         |       Owner:  dustymugs    
     Type:  task            |      Status:  assigned     
 Priority:  critical        |   Milestone:  PostGIS 2.0.0
Component:  postgis raster  |     Version:  trunk        
 Keywords:                  |  
----------------------------+-----------------------------------------------

Comment(by dustymugs):

 I'm concerned about several items in the working specs for ST_MapAlgebra
 before I get into writing it.  I've put into blocks the text from the
 working spec I have questions about...

 1. In the item regarding the alignment of both rasters...

 {{{
 Both raster must be aligned. This is determined using the
 ST_SameAlignment() function described below. If a resampling is necessary
 they use the planned ST_Resample() function to resample the second raster
 to the first one before processing (or the first to the second if a MASTER
 parameter is provided). If ST_Resample() is not yet implemented when these
 functions are implemented, just return an error message: "ERROR:
 MapAlgebra? on rasters with different alignment not yet implemented."
 }}}

 I don't know if it is appropriate for ST_MapAlgebra to do the alignment
 automatically as the behavior would differ from the behavior of other
 exceptions, primarily different SRIDs.  Technically, you could reproject
 the second raster to that of the first automatically as well but we're
 outputting an exception instead.  Outputting an exception is in-line with
 the behavior found in the geometry functions.

 In addition, the resampling of the second raster may change (probably
 will) depending on the resampling algorithm used, which I think is a
 decision that the end-user must make.

 2. For the resulting raster's extent...

 {{{
      The computation extent (extentexpr in the functions below) and hence
 the extent of the resulting raster can be:

         -'FIRST' (the extent of the first raster) (default),
         -'SECOND' (the extent of the first raster),
         -'INTERSECTION' (the extent of the intersection of both rasters)
 (could also be default),
         -'UNION' (the extent of the union of both rasters).
 }}}

 I think the default should be INTERSECTION or UNION as they are the most
 obvious from the user's standpoint.  I'd prefer INTERSECTION as that is
 typically the most compact.

 3. For the expressions dealing with nodata...

 {{{
     Alternative expressions, evaluated in place of the main expression,
 can be provided as parameter to deal with nodata values:

         -nodata1expr is evaluated when the first raster pixel value is
 nodata or when the first raster is absent from the pixel area being
 evaluated
         -nodata2expr is evaluated when the second raster pixel value is
 nodata or when the second raster is absent from the pixel area being
 evaluated
         -nodatanodataexpr is evaluated when both rasters pixel values are
 nodata or when the both rastera are absent from the pixel area being
 evaluated
         -expression is evaluated when both raster pixel values are
 withdata.

     All expressions default to NULL. When an expression is NULL every
 pixel filling the condition of this expression is set to NULL (nodata).
 }}}

 My concern is with the last sentence "When an expression is NULL every
 pixel filling the condition of this expression is set to NULL (nodata).".
 What is the nodata value in this situation when the pixel is set to NULL?

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