[postgis-devel] WKTRaster ST_MapAlgebra

[Pierre Racine]

>I agree that information is lost in the process. So the cell size is
>set to the cell size in the first raster parameter ("master"), or
>overridden by an optional cell size parameter?

I'd like both options in two different functions (actually the same function with different parameters, ie. overloading)...

>> PostGIS has a function which snap geometries to a grid
>(http://postgis.refractions.net/documentation/manual-1.5/ST_SnapToGrid.html) I would probably want to
>be able to similarly snap my raster to a grid like this when resampling. These parameter should be
>passsable to both ST_MapAlgebra() and ST_Resample(). We could also create a RasterGrid kind of object
>carrying those four parameters. Then we would have full control over the alignment/cell size of
>resulting rasters in many operations. A feature that lack in many package (maybe I'm too adventurous
>here).
>
>
>That sounds like you would want ST_MapAlgebra to look like:
>
>1- ST_MapAlgebra(rastergrid|geometry, [rastergrid|geometry,...],
>'mathematical expression', 'rastergrid' |'geometry') ->
>rastergrid/geometry
>
>where the 1st 'rastergrid' was the master, or:
>
>2- ST_MapAlgebra(raster|geometry, [raster|geometry,...], 'mathematical
>expression', 'raster' |'geometry', originx, originy, pixelsizex,
>pixelsizey) -> raster/geometry

Sounds good! (I assume that rastergrid in the first one is actually a raster)

I would probably also like to have:

3- ST_MapAlgebra(rastergrid|geometry, [rastergrid|geometry,...], 'mathematical expression', 'raster' |'geometry', integer) ->raster/geometry

where the last integer is the index of the raster to use as the master raster in the list of raster provided.

An also:

4- ST_MapAlgebra(rastergrid|geometry, [rastergrid|geometry,...], 'mathematical expression', 'raster' |'geometry', rastergrid) ->raster/geometry

in which I can pass a rastergrid object to a totally different alignment (corresponding, say, to a third layer).

ST_Resample would have similar overloading. I think all this discussion should actually be more related to the design of the ST_Resample function. Then it is only a matter of how ST_MapAlgebra use it. No?

We could also not try to touch the alignment, just making sure that the result is aligned with one or other input raster and let final alignement to ST_Resample. In this case, in the worst case, I would do something like:

5- ST_Resample(ST_MapAlgebra(raster, [raster,...], 'mathematical expression', integer), originx, originy, pixelsizex, pixelsizey)

or

6- ST_Resample(ST_MapAlgebra(raster, [raster,...], 'mathematical expression', integer), rastergrid)

This would remove the need for #2 and #4. That would probably be more simple and explicit... In brief I think realignment should be the responsability of ST_Resample() and ST_MapAlgebra should not have to take care of it. Otherwise MapAlgebra HAVE to take care of pixel size. Otherwise we may loose information. This is why we need #3.

In the Resample description I would write something like: "recompute a raster in order to change its pixel size and/or the position of its upper left corner."

Pierre