[postgis-devel] two-raster ST_MapAlgebraExpr specification discussion

[Bryce L Nordgren]

I'd like to re-address this question to David, or really anyone who is not
looking to pick a fight.

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?

Thanks,
Bryce

On Mon, Nov 21, 2011 at 6:12 PM, Bryce L Nordgren <bnordgren at gmail.com>wrote:

>
>
>    1. This conflicts with C: 2.0 + NaN is NaN.
>    2. This conflicts with the behavior of the band math function in ENVI.
>    3. 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.
>    4. 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.
>    5. 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
>
>
>
> This conflicts with postgis: SELECT 2+NULL; is NULL.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20111122/a3bd1b38/attachment.html>