I'd like to re-address this question to David, or really anyone who is not looking to pick a fight.<br><br>These specifications sacrifice two major things (consistency with PostGIS, and the potential to extend beyond two rasters) and presumably you bought some functionality with this tradeoff. Can you outline what additional functionality you gained by this decision?<br>
<br>Thanks,<br>Bryce<br><br><div class="gmail_quote">On Mon, Nov 21, 2011 at 6:12 PM, Bryce L Nordgren <span dir="ltr"><<a href="mailto:bnordgren@gmail.com">bnordgren@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><div class="gmail_quote"><div><ol>
<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><font color="#888888"><br>Bryce<br><blockquote>
</blockquote><br></font></div><br></div>This conflicts with postgis: SELECT 2+NULL; is NULL.
</blockquote></div><br>