[postgis-devel] Raster todo list

[Bryce L Nordgren]

> > I completely agree, and actually I think the structure of the available
> functions
> > should reflect this. For instance, rather than have many thin wrappers
> over a
> > single huge do-it-all function like MapAlgebra, I'd prefer to build a
> complex
> > function (MapAlgebra) from simpler ones (ST_Intersection).
>
> How would you build a very generic MapAlgebra requiring raster expressions
> like 'rast1 * rast2 + 120' from something like ST_Intersection?
>
>
Well since you asked, here's how I would approach the problem:

Make ST_Intersection(raster,raster) return a mask (e.g., a one-band raster
having only true/false values). The mask represents the common area.
MapAlgebra uses this mask to determine the size and properties of the
resultant raster (corner location, # pixels in x and y direction, size of
pixels, etc.). MapAlgebra adds the ability to compute a value using a
user-specified arbitrary expression, but only does so over the grid cells
having a "true" value in the mask.

Better, MapAlgebra is not concerned with how the mask is generated, and so
it can use ST_Difference, ST_SymDifference, ST_Union, or ST_Intersection to
determine the spatial extent of the result with little or no change of code.
Better yet, since all MapAlgebra needs is a mask, it can accept a
user-specified mask which was generated by an arbitrarily complex process.
Even better yet, if users are allowed to specify the mask, the mask can be
re-used for multiple calls to MapAlgebra and does not need to be
re-computed.

Clearly, a one-raster MapAlgebra variant is all that is needed if
ST_Difference or ST_SymDifference is used to define the area for which
results are desired, as the "valid area" is guaranteed to only have data
from one raster (not necessarily the same raster).

 Using this philosophy, there is a clear and logical separation between the
spatial operation (ST_{Difference,SymDifference,Union,Intersection}) and the
value computation part (MapAlgebra). More modular, easier to understand,
easier to re-use, easier to maintain.

:)

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