[raster] External band numbers are capped to 1 - 256

[Bborie Park]

In looking at the code, the variable for the external band number is set to uint8_t. This is reflected by the serialized raster allocating 1 byte for the band number.

Having external band numbers set to 1 - 256 is a serious limitation considering external band data is processed through GDAL, which probably has a much higher limit.

The external band number variable should be at least uint16_t, which is the same as the number of bands variable for the raster object.

I don't know when this can be fixed as this affects the serialized raster format. The raster object does have a version flag so this fix could be introduced in PostGIS 2.1.

[Bborie Park]

I've hit this bug working with ​DAYMET datasets which use a band for each day of a particular year.

[robe]

So does that mean in the docs for 2.0 and 2.1 we need to say raster band count is limited to 255 bands? If you want to get it in before I release 2.1 (like in a week) I can wait and just note the issue in 2.0.

[Bborie Park]

I won't be able to get this in before 2.1 as it will require a small but significant change to the serialized format. I'll add notes regarding the issue to the docs for 2.0 and 2.1.

[pracine]

Aren't changes to the serial format allowed only at major version (3.0)?

[Bborie Park]

Only things that require a hard dump/reload are permitted in major versions. This change is possible because there is a version flag in the serialized format.

[Bborie Park]

Notes added in r11715 for 2.0 and in r11716 for 2.1.

[Bborie Park]

Should there be RFCs for changing the raster's serialized and WKB formats? The only changes I plan on making is bumping up the format version numbers to 1 and change the variable type for out-db band indexes from uint8 to uint16.

[Bborie Park]

This format change would be done for PostGIS 2.2, which will still support version 0 formats. PostGIS 2.0 and 2.1 will only support version 0 formats unless folks think otherwise...

[Bborie Park]

My bad. ST_PixelAsPolygons was a pl/pgsql function in 2.0.

[Bborie Park]

Replying to dustymugs:

My bad. ST_PixelAsPolygons was a pl/pgsql function in 2.0.

Oops. Wrong ticket.

[robe]

Milestone renamed

[Algunenano]

The fact that this is assigned to "PostGIS Fund Me" leads me to believe that this isn't critical.