[postgis-devel] two-raster ST_MapAlgebraExpr specification discussion

Bryce L Nordgren bnordgren at gmail.com
Mon Nov 21 10:12:56 PST 2011


The specifications for two-raster ST_MapAlgebraExpr handle nodata values as
follows:

======
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).

======

I'd like to begin a discussion of this aspect of two raster mapalgebra,
starting with a few notes:

   1. This conflicts with postgis: SELECT 2+NULL; is NULL.
   2. This conflicts with C: 2.0 + NaN is NaN.
   3. This conflicts with the behavior of the band math function in ENVI.
   4. I'll have to fire up Arc to make sure, but I'm pretty sure it will
   conflict with the behavior of the grid calculator too.
   5. This is specific to the two-raster version and is not extensible to
   three rasters or more. In essence: by doing this, you are declaring that
   you're going to treat every expression-based combination of rasters with a
   different number of inputs as a special case which needs to be
   independently handled.
   6. This is much more complex than the nearly universally accepted method
   of propagating nodatas thru the expression.

In other cases, the philosophy has been to stick to the way PostGIS does
things. Was there some really very good justification for this rather
radical departure? If so, it needs to be on the specification page too.

What I'd really like to see is some pathway to eventually getting to a
signature like this:
ST_MapAlgebraExpr(rastarray ARRAY (of raster), bandarray ARRAY (of bands),
expr text, pixeltype text)

where the expression refers to input rasters by position in the arrays
(e.g, rast1 is rastarray[1],bandarray[1]), NODATA is propagated through the
expression, and the extent of the result is always the intersection of the
input rasters.

>From what I can see so far, the complexity at two rasters has exploded to
the point where there's really no hope of adding more.

Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20111121/8a32ba05/attachment.html>


More information about the postgis-devel mailing list