[GH-3330] Keep the other bands when replacing a band's no-data value

[Eliaaazzz]

Did you read the Contributor Guide?

• Yes, I have read the Contributor Rules and Contributor Development Guide

Is this PR related to a ticket?

• Yes, and the PR name follows the format [GH-XXX] my subject. Closes RS_SetBandNoDataValue with replace=true zeroes every band except the target one #3330

What changes were proposed in this PR?

RasterBandEditors.setBandNoDataValue(raster, bandIndex, noDataValue, replace = true) allocates a fresh WritableRaster with every band and then wrote only bandIndex - 1 into it. The remaining bands came back as the allocation default of 0, while their sample dimensions still described the original data, so the raster looked intact in its metadata and had lost its pixels.

On a three-band raster, setBandNoDataValue(raster, 1, -999.0, true) returned:

• band 1 as [1, 2, 3, 4, -999, 6, 7, 8, 9], correct
• band 2 as all zeros, where [11 ... 19] was expected
• band 3 as all zeros, where [21 ... 29] was expected

Replacing on a band other than the first lost band 1 the same way. The fix copies every band across and applies the replacement only to the targeted one.

This reaches SQL as RS_SetBandNoDataValue(raster, bandIndex, noDataValue, true) on any raster with two or more bands.

How was this patch tested?

New test RasterBandEditorsTest.testSetBandNoDataValueWithReplaceOptionKeepsOtherBands, which replaces on band 1 and then on band 2 of a three-band raster and asserts the full contents of all three bands each time, plus the resulting no-data metadata. It fails on master with band 2 and band 3 read back as zeros.

Both existing tests for the replace option, testSetBandNoDataValueWithReplaceOption and testSetBandNoDataValueWithReplaceOptionRaster, use single-band rasters, which is why this went unnoticed. They still pass unchanged.

mvn -pl common test on Windows with JDK 17: the same 13 tests fail before and after the change (RasterBandEditorsTest.testClip, 5 RasterEditorsTest.testResample*, 7 RasterOutputTest.testAsMatrix*). They fail identically on unmodified master, so they are pre-existing on this platform and unrelated. Everything else passes.

I could not run spark/common locally: it fails to compile on the generated OSM PBF protobuf sources (package proto4 does not exist) before reaching any raster code. Leaving those suites to CI.

Did this PR include necessary documentation updates?

• No, this PR does not affect any public API so no need to change the documentation. The behaviour now matches what RS_SetBandNoDataValue already documents.

🤖 Generated with Claude Code

https://claude.ai/code/session_01P6hpqAnXfeaWRLkL1VQDMd