RS_SetBandNoDataValue with replace=true zeroes every band except the target one

[Eliaaazzz]

Expected behavior

RS_SetBandNoDataValue(raster, bandIndex, noDataValue, replace => true) replaces the pixels matching the old no-data value in the given band. Every other band comes back unchanged.

Actual behavior

On a raster with more than one band, every band except the target one comes back filled with zeros. The bands' sample dimensions are preserved, so the raster still describes the original data while the pixels are gone.

RasterBandEditors.setBandNoDataValue allocates a fresh WritableRaster with numBands bands for the replacement, then writes only bandIndex - 1 into it. The remaining bands keep the allocation default of 0.

WritableRaster wr = RasterFactory.createBandedRaster(dataTypeCode, width, height, numBands, null);
double[] bandData = rasterData.getSamples(0, 0, width, height, bandIndex - 1, (double[]) null);
// ... replace rasterNoData with noDataValue in bandData ...
wr.setSamples(0, 0, width, height, bandIndex - 1, bandData);
return RasterUtils.clone(wr, null, bands, raster, null, true);

Both existing tests for the replace option (testSetBandNoDataValueWithReplaceOption and testSetBandNoDataValueWithReplaceOptionRaster) use single-band rasters, which is why this is not caught.

Steps to reproduce

double[] band1 = {1, 2, 3, 4, 5, 6, 7, 8, 9};
double[] band2 = {11, 12, 13, 14, 15, 16, 17, 18, 19};
double[] band3 = {21, 22, 23, 24, 25, 26, 27, 28, 29};
GridCoverage2D raster =
    RasterConstructors.makeNonEmptyRaster(
        3, "d", 3, 3, 0, 3, 1, -1, 0, 0, 0, new double[][] {band1, band2, band3});
raster = RasterBandEditors.setBandNoDataValue(raster, 1, 5.0);

GridCoverage2D replaced = RasterBandEditors.setBandNoDataValue(raster, 1, -999.0, true);

System.out.println(Arrays.toString(MapAlgebra.bandAsArray(replaced, 1)));
// [1.0, 2.0, 3.0, 4.0, -999.0, 6.0, 7.0, 8.0, 9.0]   correct
System.out.println(Arrays.toString(MapAlgebra.bandAsArray(replaced, 2)));
// [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]      expected 11..19
System.out.println(Arrays.toString(MapAlgebra.bandAsArray(replaced, 3)));
// [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]      expected 21..29

Replacing on a band other than the first loses band 1 the same way.

The equivalent SQL is SELECT RS_SetBandNoDataValue(raster, 1, -999, true) FROM ... on any raster with two or more bands.

Sedona version

2.0.0-SNAPSHOT at 495637d. The same code is present in released 2.x and 1.x versions.

API type

Java (sedona-common) and SQL (RS_SetBandNoDataValue).

JRE version

17

Environment

Local development checkout.

Existing issues

• I searched the existing issues and did not find a duplicate.

[james-willis]

Captured in SedonaDB's parity suite (apache/sedona-db#1250) with truth-anchored xfails that flip green only when replace behaves. One extra data point from probing: the 4-arg form's SQL binding is jar-dependent — the sedona-spark-shaded-4.1 1.9.1 artifact fails to evaluate it outright, while the -4.0 artifact runs it and reproduces this corruption exactly (target band replaced correctly, every other band all zeros, per-band nodata reading as if untouched).