[raster] Change the ST_MapAlgebra nodatavalueexpr text parameter to nodataval double precision

[pracine]

The original plan to support refering to neighbour pixel in Mapalgebra was to refer to them using their position relative to the pixel being compute. e.g.: "rast[-1,0] + 1" rast[-1,0] refering to the first pixel at the left of the pixel being computed. This prove to be hard to use when the desired neighbour area include most pixels of an area larger than the first neighbour.

The better alternative is to propose a variant to ST_MapAlgebra named ST_MapAlgebraNgb which would pass a vector of value (or a small raster) to a user defined summarizing function that would return the value to be assigned to the pixel.

The original ST_MapAlgebra nodatavalueexpr text parameter was intented to give a way to provide an alternative expression in case one pixel value refered by the relative neighbour syntax (rast[-1,0]) would be nodata.

Since this syntax will not be offered/implemented there is no more need for a nodatavalueexpr, a more simple nodatavaluereplacement value is sufficient.

[dzwarg]

Is this ticket intended to only change the name of the parameter from "nodatavalueexpr" to "nodatavaluerepl"?

Or does this ticket also imply that the evaluation of the "nodatavaluerepl" string will no longer occur, and that any text passed in as this parameter gets converted to the raster cell data type and stored as "newinitialvalue" in RASTER_mapAlgebra?

[dzwarg]

Rename of "nodatavalueexpr" to "nodatavaluerepl".

[pracine]

Replying to dzwarg:

Is this ticket intended to only change the name of the parameter from "nodatavalueexpr" to "nodatavaluerepl"? Or does this ticket also imply that the evaluation of the "nodatavaluerepl" string will no longer occur, and that any text passed in as this parameter gets converted to the raster cell data type and stored as "newinitialvalue" in RASTER_mapAlgebra?

This is not just a parameter name change. The expression passed should evaluate to a numeric value the same type of the resulting pixel type. I guess the best bet for the type of this parameter is double precision even if the requested resulting raster pixel type is int. Yes this value should be used to initialize the raster in order to avoid (skipping) computing values for nodata values.

I would change the script/plpgsql/st_mapalgebra.sql first.

Sorry for the late answer.

[pracine]

More explanations:

-nodatavalueexpr would be an expression possibly containing "rast".

-nodatavaluerepl is not an expression, it is a constant replacement value of type double.

After analysis (done with David in Mtl) we concluded that it makes no sense to pass a nodata value expression (nodatavalueexpr) of "rast" since in this case "rast" is always "nodata" and hence a constant. So it is better, simpler and makes more sense to just pass a constant "nodata value replacement" (nodatavaluerepl).

Everything would work with nodatavalueexpr. But it makes more sense to pass a constant. It is also a bit faster as it does not have to be evaluated.

[dustymugs]

Fixed in r8110.