The specifications for two-raster ST_MapAlgebraExpr handle nodata values as follows: <br><div class="gmail_quote"><br>======<br><div>Alternative expressions, evaluated in place of the main expression, can be provided as parameter to deal with nodata values:

<br>-nodata1expr is evaluated when the first raster pixel value is nodata or
 when the first raster is absent from the pixel area being evaluated<br>-nodata2expr is evaluated when the second raster pixel value is nodata 
or when the second raster is absent from the pixel area being evaluated<br>-nodatanodataexpr is evaluated when both rasters pixel values are nodata
 or when the both rastera are absent from the pixel area being evaluated<br>-expression is evaluated when both raster pixel values are withdata.
<blockquote><blockquote>
</blockquote>
</blockquote>
All expressions default to NULL. When an expression is NULL every pixel 
filling the condition of this expression is set to NULL (nodata).<br><br>======<br><br>I'd like to begin a discussion of this aspect of two raster mapalgebra, starting with a few notes:<br><ol><li>This conflicts with postgis: SELECT 2+NULL; is NULL.</li>
<li>This conflicts with C: 2.0 + NaN is NaN.</li><li>This conflicts with the behavior of the band math function in ENVI.<br>
</li><li>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.</li><li>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.</li>
<li>This is much more complex than the nearly universally accepted method of propagating nodatas thru the expression.<br></li></ol>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.<br>
<br>What I'd really like to see is some pathway to eventually getting to a signature like this: <br>ST_MapAlgebraExpr(rastarray ARRAY (of raster), bandarray ARRAY (of bands), expr text, pixeltype text) <br><br>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.<br>
<br>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.<br><br>Bryce<br><blockquote>
</blockquote><br></div><br></div>