Eliaaazzz opened a new pull request, #3331:
URL: https://github.com/apache/sedona/pull/3331

   ## Did you read the Contributor Guide?
   
   - Yes, I have read the [Contributor 
Rules](https://sedona.apache.org/latest/community/rule/) and [Contributor 
Development Guide](https://sedona.apache.org/latest/community/develop/)
   
   ## Is this PR related to a ticket?
   
   - Yes, and the PR name follows the format `[GH-XXX] my subject`. Closes #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.com/claude-code)
   
   https://claude.ai/code/session_01P6hpqAnXfeaWRLkL1VQDMd
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to