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

Jorge Arévalo jorge.arevalo at gmail.com
Sun Jul 12 20:12:06 EDT 2009


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?.

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?

Best regards
Jorge


More information about the gdal-dev mailing list