[raster] ST_Band

[mloskot]

This tasks belongs to the Objective 0.1.6f specified in the WKT Raster roadmap

As stated in the comment 7 of the Specification Comments following the Code Sprint in http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking01, we should prefer the option of adding a band parameter to every function working on a single band like ST_AsTIFF(). In all these cases, if the band parameter is omitted, the function should work on the first band.

ST_Band() is nevertheless a must have function for future release.

[pracine]

If we agree on lowering the priority of this ticket I will update the planification.

[dustymugs]

As part of the FV.01, I propose the following function versions for ST_Band:

ST_Band(rast raster, nbands int[]) -> raster

nbands is an array of 1-based band indices of the bands to copy into the output raster

Ex: For a raster rast with 3 bands:

ST_Band(rast, ARRAY[1,3,2])

ST_Band(rast, ARRAY[3,2,1])

You can rearrange the bands as above. You can also duplicate the bands:

ST_Band(rast, ARRAY[1,2,3,2,1])

ST_Band(rast raster, nband int) -> raster

nband is a single integer of the 1-based band index of the band to copy into the output raster

Ex: ST_Band(rast, 1)

ST_Band(rast, 3)

ST_Band(rast raster, nbands text) -> raster

nbands is a comma separated string of 1-based band indices indicating the bands to copy into the output raster

Ex: ST_Band(rast, '1,2')

ST_Band(rast, '1,2,3, 1, 1 , 2')

ST_Band(rast raster)

the band to extract is automatically assumed to be one.

Ex: ST_Band(rast) -> raster

Should I include a expanded version of the ST_Band(rast raster, nbands text) to provide the ability to specify the delimiter?

[pracine]

Sounds good!

[dustymugs]

Adds ST_Band support. Includes core and regression tests

[dustymugs]

I've added a patch including ST_Band support. Core and regression tests are included.

[dustymugs]

tweaked patch so that patch can be applied in same manner as all dependent patches

[dustymugs]

Added new patch so that the patch can be applied in same manner as all other dependent incremental patches...

patch -p1 < st_band.patch

[pracine]

ST_Band should not return an error when specified band(s) is or are out of range. It should follow the rule established at the tip of rt_pg.c and the behavior of other functions taking a band argument which is to return NULL with a NOTICE. (We might want to create an new ticket for that.)

[dustymugs]

OK. I'll make the appropriate changes to all the other patches based upon that rule in rt_pg.c. I guess I never paid attention to that rule. My fault.

[dustymugs]

Refactored to account for changed memory handling.

[dustymugs]

Attached latest ST_Band patch (st_band.3.patch) to refactor for changed memory handling. Merges cleanly against r7145. This is the first in the series of incremental patches.

[dustymugs]

Added in r7147.