[postgis-devel] two-raster ST_MapAlgebraExpr specification discussion

Bryce L Nordgren bnordgren at gmail.com
Tue Nov 22 08:49:10 PST 2011


On Tue, Nov 22, 2011 at 3:30 PM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca>wrote:

> > These specifications sacrifice two major things (consistency with
> PostGIS, and
>
> The default behavior, when there is no alternative expression provided, is
> to set the resulting value to null when one of the overlapping value is
> null. So there is no conflict between this behavior and SELECT null + 4; =
> null
>
>
Correct. The question is, what did you gain by providing the ability to
override?


>  > the potential to extend beyond two rasters)
>
> Could you provided a SQL query involving 4 rasters for example? I think
> doing this exercise will make you realize that supporting processing on an
> array of raster stored in four different tables leads to impractical
> applications, too complex queries and uncertain processing time...
>

SQL queries are out, because you support only two at a time. Algorithm:
differenced Normalized Burn Ratio (dNBR). 4 bands, two landsat scenes
(likely to be 4 tables). Doing the calculation in a single expression is
more efficient because you don't have to allocate, create and store the
intermediate calculations.



> Again those conflicts are the only fruit of your imagination. They will
> vanish when you will spend more time trying things than writing long
> useless complaining emails... We really have other things to do. I'm not
> the only one thinking this...
>

This is exacly what I meant about someone trying to pick a fight, so the
email wasn't addressed to you. You are so eager to see a complaint from me
that you just won't see the more or less neutral questions I pose, and it
is utterly beyond the pale that I might have an application in mind which
motivates the observations.

As to the rest, I'm essentially taking care of architectural design and
implementation for the long term accumulation of maintainable, reusable
production code in C. I understand this qualifies as "nothing productive"
in your book because you're buried in rapid prototyping mode. However, it's
essential for the long term success of this effort. You could at least
acknowledge that because I'm handling it, your efforts can be focused on
pushing out this release. To see the running status of my contribution,
you're once again invited to look here:

https://github.com/bnordgren/postgis/commits/ri-gen2-svn

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


More information about the postgis-devel mailing list