[james-willis]

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 Split no-data replacement out of RS_SetBandNoDataValue into RS_ReplaceBandNoDataValue #3423

What changes were proposed in this PR?

Give no-data replacement its own function instead of a boolean flag on RS_SetBandNoDataValue. This is a breaking change aimed at 2.0.

	Before	After
Set or clear the no-data value (metadata only)	RS_SetBandNoDataValue(raster[, band], value)	unchanged
Rewrite the no-data pixels to the new value, then declare it	RS_SetBandNoDataValue(raster, band, value, true)	RS_ReplaceBandNoDataValue(raster, band, value)
Java	RasterBandEditors.setBandNoDataValue(raster, band, value, replace)	setBandNoDataValue(raster, band, value) / replaceBandNoDataValue(raster, band, value)

The two modes were very different operations behind one signature. The flag turned a cheap metadata edit into a pixel rewrite, and it didn't combine with a null value, which means "remove the no-data value" everywhere else. SedonaDB is adding the same API. There, whether a function reads pixels is declared per function, so a flag would make every RS_SetBandNoDataValue call load pixels, and the reviewers on apache/sedona-db#1343 preferred a separate function. This PR makes the same split here so both engines keep one API.

RS_ReplaceBandNoDataValue keeps the old replace=true behaviour:

• A pixel holds the current no-data value by RasterUtils.isNoData: numeric comparison, -0.0 matches 0.0, and any NaN matches a NaN no-data value. That's the same rule SedonaDB uses.
• The band must already have a no-data value, or it throws IllegalArgumentException.
• Other bands are unchanged.
• A null argument returns null.

The NaN-to-integer error message in RS_SetPixelType now recommends the new function.

Unlike the other raster setters, the function takes only an explicit band. The existing 2-argument forms default to band 1 here but reject a multiband raster in SedonaDB, and a new function doesn't need to inherit that difference.

How was this patch tested?

• Existing replace tests in RasterBandEditorsTest, RasterOutputTest and rasteralgebraTest moved to the new function.
• New tests:
  • the missing-no-data error, in Java and SQL
  • null propagation
  • -0.0 matching a 0.0 no-data value
  • the SQL example from the new doc page
• Run locally (JDK 17): RasterBandEditorsTest, RasterBandAccessorsTest, RasterEditorsTest and RasterOutputTest (117 passing), plus rasteralgebraTest (174 passing). pre-commit is clean.

Did this PR include necessary documentation updates?

• Yes, I am adding a new API. I am using the current SNAPSHOT version number in vX.Y.Z format.
  • New RS_ReplaceBandNoDataValue page, plus a row in the raster function list.
  • The RS_SetBandNoDataValue page drops the replace form and notes its removal in v2.0.0.
  • A breaking-change entry in the 2.0.0 release notes, and a section in the Sedona 2.0 migration guide showing how to rewrite the true and false forms.