gdal raster calc: add a --dialect=muparser|builtin, where builtin can be used to compute a single band from all bands of a single input dataset

[rouault]

CC @dbaston

[dbaston]

@rouault This is along the lines of what I was thinking with this comment: https://github.com/OSGeo/gdal/pull/12406#discussion_r2094547998

But rather than an argument --pixel-function that is mutually exclusive with --calc, I would consider something like --dialect [muparser/builtin] that can be eventually extended to --dialect python

[rouault]

But rather than an argument --pixel-function that is mutually exclusive with --calc, I would consider something like --dialect [muparser/builtin] that can be eventually extended to --dialect python

done

[dbaston]

Isn't this behavior different from the muparser dialect in a fundamental way, in that with muparser N bands of input will produce N bands of output, but with --dialect builtin, N bands of input will produce 1 band of output?

Both modes seem useful but I think that behavior should remain independent of the dialect.

So if X is a 3-band raster, gdal calc --dialect muparser --calc "sum(X)" currently creates a 3-band raster. But you could also imagine a --flatten switch, in which it creates a 1-band raster with the sum of the three input bands.

Similarly,, if X and Y are 3-band rasters, gdal calc --dialect builtin --calc sum could create a 3-band raster whose bands represent X1 + Y1, X2 + Y2, X3 + Y3.

[rouault]

But you could also imagine a --flatten switch, in which it creates a 1-band raster with the sum of the three input bands.

Excellent suggestion. Thanks for challenging my proposals! Now implemented

[dbaston]

Nice! I have been tied up on other things but hope to look at this soon.

[rouault]

With muparser "sum(X, Y)" we get X[1] + Y[1], X[2] + Y[2], but with builtin "sum" we are getting X[1] + Y[1], Y[2]

any suggestion on what we should do ?

[dbaston]

I implemented the muparser behavior intentionally to match what numpy would do in this situation. That's why the inputs must have the same number or bands, or a single band.

[rouault]

I implemented the muparser behavior intentionally to match what numpy would do in this situation. That's why the inputs must have the same number or bands, or a single band.

interesting. Didn't know that numpy would do this. --dialect=builtin updated to have same behavior

[dbaston]

We don't need source names for --dialect builtin, so https://github.com/rouault/gdal/pull/65 removes that requirement

[dbaston]

Additional suggestions in https://github.com/rouault/gdal/pull/68, https://github.com/rouault/gdal/pull/67