[raster]: ST_SetBandNoDataValue should apply to all bands if no band specified

[robe]

In thinking about this more I think the fact that ST_SetBandNoDataValue assumes band 1 when no band is specified is more of a defect than a breaking change that we should fix before 2.1.0 final is released. This defect is going to be even more annoying in 2.1.0 than it was in 2.0 because 2.1.0 makes it so much easier to work with multiple bands at a time.

For users who had only one band, which I would venture to guess is about the 90% of users who used the (no band specified option), nothing changes. since all of 1 band is still 1 band.

For users who for whatever reason didn't specify a band though they had multiple bands, they were either misguided thinking this worked on all bands (or only needed it for the first band because they were doing a 1 band operation). I would suspect for them the change may slow their processing down a tad bit but not by much, or be a welcoming fix .

So that leaves people like me who say — yeh we have an ST_ColorMap that explodes our single band into bright beautiful colors

oh but wait:

I've got to do this to get a transparent overlay

ST_SetBandNoDataValue(ST_SetBandNoDataValue(ST_ColorMap(rast,..),1,255),2,255),3,255)

instead of this:

ST_SetBandNoDataValue(ST_ColorMap(rast,..),255)

oops I forgot to do the same for band 4 why is my picture so screwed up

I must add this is also in alignment with our change in ST_Union behavior that assumes all bands if no bands specified.

Of course Bborie and Pierre can conclude I'm full of sh..t and push this to future or mark as won't fix.

[dustymugs]

The problem I have is that changing this behavior would be slippery slope. There are many other functions that assume nband = 1, e.g. ST_SetValue, ST_SetBandIsNoData(), ST_SummaryStats(), ST_BandMetaData().

But the reality is that we need to be able to process many bands at once.

Just in case, I double-checked how gdaldem handles NODATA for color-relief output and it behaves in the same manner as ST_ColorMap.

[dustymugs]

After thinking some more (by a few seconds), I'd rather see a different function signature instead of modifying the current behavior.

ST_SetBandNoDataValue(
  rast raster,
  nband int[],
  nodataval double precision[]
)

[robe]

Okay then I guess this will have to wait till 2.2 and we already have that ticketed in the other ticket.