[gdal-dev] How do we know the number of raster bands of a WKT Raster object?

[Mateusz Loskot]

Jorge Arévalo wrote:
> Hello,
> 
> On Sun, Jul 12, 2009 at 11:53 PM, Mateusz Loskot<mateusz at loskot.net> wrote:
>> Frank Warmerdam wrote:
>>> Jorge Arévalo wrote:
>>>> Hello,
>>>>
>>>> I have a doubt: I have a raster loaded in PostgreSQL with
>>>> gdal2wktraster, and I'm not sure of the best way to know the number of
>>>> raster bands the raster has. The fields "pixel_types" and
>>>> "nodata_values" from raster_columns table are arrays with one element
>>>> per raster band, so, counting the number of elements of one of these
>>>> arrays, I can get the number of raster bands. But it doesn't seem to
>>>> be a very "elegant" way. Do we have another way to do this?
>>> Jorge,
>>>
>>> I believe taking the count of values in the pixel_types array is the
>>> correct approach to determining the number of bands.
>> Yes, I can confirm this is the way to find number of bands of raster
>> (raster coverage) registered in RASTER_COLUMNS table.
>>
>> Number of bands per single raster BLOB (row) can be retrieved
>> using SQL function ST_NumBands
>> (http://trac.osgeo.org/postgis/browser/spike/wktraster/rt_pg/rtpostgis.sql.in.c?rev=4146#L167)
>>
> 
> Thanks Mateusz. And this has remainded me of something always make me
> to doubt, in the context of GDAL WKTRaster driver.
> 
> I can get information about raster properties in RASTER_COLUMNS table,
> but I can get this information from each row too. So, in which
> information source should I trust? If they both have sync problems
> (for example, if the number of raster bands in RASTER_COLUMNS table
> doesn't match the number of bands in the header of each raster), what
> should I do?.

In my opinion, you should always trust RASTER_COLUMNS.
This is a metadata table with all raster tables registered. Plus, for
regular blocking it stores additional information required for
manipulating collection of tiles (coverage, matrix of raster tiles).

Actually, I believe that one day WKT Raster should provide validation
functions on SQL level, so it's possible to (optionally|obligatorily)
validate rasters being loaded into table.

Some simple validation has been implemented on metadata level in
AddRasterColumn

http://trac.osgeo.org/postgis/browser/spike/wktraster/rt_pg/rtpostgis.sql.in.c?rev=4146#L412

> My logic says that the information stored in rasters is the good one,
> and it may be used to correct the information read from RASTER_COLUMNS
> table, if needed. AFAIK, there's no automatic update of RASTER_COLUMNS
> table. Then, this table can easily be out of date. Am I right?

The problem is that...it's hard to say which approach is correct.
There has been some discussion about that and AFAIR there was no
consensus reached so far.

For myself, regular blocking applications have higher priority and as
such I consider RASTER_COLUMNS as valid and overriding.

If WKT Raster driver for GDAL is supposed to work with regular blocking
(RB), then if querying RB-enabled tables, you must assume all rasters
(tiles,rows) have common properties - as stated in the specification.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org