[gdal-dev] More multiresolution and datatype questions

Frank Warmerdam warmerdam at p...
Fri Oct 12 17:46:06 EDT 2001

Lowell Johnson wrote:

> GDAL handles the image data type at the band level, thus allowing for
> multi-datatype images. But I haven't seen an API call that allows for the
> creation of multi-datatype images. For instance, GDALDriver::Create()
> passes in a GDALDataType eType parameter. For multiple datatype images, I
> expected that this would be an array of size nBands. How are
> multi-datatype images created?


Because few formats support the creation of datasets with mixed types
I hadn't made it directly accessable from the create method. If you need
to implement a driver which can create mixed types, I would suggest passing
the per-band information as extra info in the options list.

Alternatively, we could add a new method on the GDALDataset for adding
bands, which would include the type. For very dynamic formats this might
be the preferred way of creating a file with fairly particular

> As stated in earlier messages, we will need support for multiresolution
> images (all bands sharing common corner coordinates, but pixel ground
> distances varying). I am probably still misunderstanding something from
> your earlier responses, but it is important that I understand the
> capabilities and limitations of GDAL.
> In an earlier response you said [bracketed comments added by me],
> > In theory that [interpretation of GDALRasterBand XSize, YSize values
> > to support multiresolution images] might be possible; however, GDAL was
> > developed with the assumption that all bands on a given GDALDataset are
> > of the same size and same geographic area. Any breaking of this
> > assumption could have dramatic consequences.
> In the Raster Band documentation, it is stated
> A raster band has the following properties:
> * A width and height in pixels and lines. This is the same as that
> defined for the dataset, if this is a full resolution band.
> What is the purpose of the band-level width and height if not for
> multiresolution? Are they only used for overviews? Before GDAL, I haven't
> encountered overviews, so I'm not familiar with their history and usage.
> But overviews seem to be smaller representations (i.e., lower
> resolution thumbnails?) of a full-resolution band.

The separate width/height information in the GDALRasterBand is only intended
for the support of overviews.

> I note that you earlier described your concept for subdatasets and how they
> can be used to support multiresolution images. This does look like it
> would be a solution, but our team would really like to have a library that
> handles each band as having a distinct resolution (pixel size), with all
> image bands sharing the same geographic corner coordinates. GDAL seems to
> have the needed elements (Xsize, YSize per band) in place, but the design
> interpretation does not support multiresolution?
> I apologize for my need to have it spelled out. I'll continue with my
> investigations, but any further explanations that you can give me will
> hopefully shorten my analysis period so that we can get on with our
> implementation process.

I have agonized over this issue for the last few days. I really hate the
idea of changing the basic data model of GDAL. When I write applications
I don't want to have to check the size of each raster band before I can
access it, which would implicitly be required if we were to relax the
restrictions on different bands having the same size.

However, what I have been thinking is that we could treat the dataset as a
whole as having the resolution of the finest of the bands. Any band at a
reduced resolution would be treated as an overview, but we would have a
base band object provided which would basically know how to resample the
true full res data out to the resolution of the dataset as a whole.

The base level GDALRasterBand could contain specialized metadata identifying
the overview which is the "true" data for applications that are savvy to
the concept of multiple resolution datasets, but more naive applications
could treat the dataset in the more conventional manner.

Does this sound OK?

It would take some extra work to implement the driver for such a
multi-resolution format, but I could provide a GDALRasterBand subclass that
is just virtual ... resampling itself from another resolution for you to

Given that you know your different bands will always be for the same
region, just with different resolutions, I think this might be a nicer
approach that the SUBDATASETS idea.

I appologise for taking so long to reply. I really felt I needed to
take some time to digest the implications.

PS. feel free to phone me at (905) 780-0450 if you want to hash this
out more quickly than by email.

Best regards,

I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at p...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

More information about the Gdal-dev mailing list