[gdal-dev] Multiresolution images

[Lowell Johnson]

On Wed, 19 Sep 2001, Frank Warmerdam wrote:
> Lowell Johnson wrote:
> > Hello,
> >
> > I'm just beginning to look at the possibilities of using the GDAL to
> > support our image I/O needs. One concern is that we need to support image
> > formats that contain bands with differing resolutions (e.g., 30m, 15m
> > projection distances). If I have read correctly, the GDAL does not support
> > multiresolution data formats. Is there a way (short of breaking the
> > different resolutions into separate images) to handle multiresolution
> > images? If not, is this something that is being considered for future
> > development?
> 
> Lowell,
> 
> There is no ability to have bands with different resolutions that are directly
> part of the same GDALDataset; however, I have recently introduced a concept of
> subdatasets. The idea here is that files that are aggregates of many
> images (such as HDF, database repositories and so forth) can be opened with
> the usual GDALOpen(), but instead of finding a bunch of bands the handle
> is also queries for subdatasets. These are just dataset names that can
> be passed to GDALOpen() against to open the subimages.
> 
> I currently use this technique for the OGDI bridge. Something like an
> ADRG tree accessed through OGDI will appear as several different layers
> each with it's own resolution. They are returned from GDAL as subdatasets.
> 
> eg.
[snip]

Maybe I'm missing something, but it seems that it may be possible to
interpret a given image as multi-resolution if each GDALRasterBand object
has a different XSize, YSize.

Say for a given image the GDALDataSet, RasterXsize and RasterYsize are 1000
x 1000 and two associated bands have XSize, YSize of 1000 x 1000 and 500 x
500. Also assume that GetGeoTransform returns a pixel size of 15 x 15
(meters). Then we can interpret the first band as having 15 meter pixels
and the second band as having 30 meter pixels.

The fact that RasterIO will automatically decimate/replicate band data to
fill a given buffer size also seems very useful for handling bands of
differing resolution.

I haven't looked into your subdataset technique to see how that may be
applied, since at this time I'm not sure that the existing GDALDataSet and
GDALRasterBand capabilities described above will not meet our needs.

Overall, I've been quite impressed with the GDAL capabilities (as
documented). We are in the process of replacing our existing image I/O
library with one that is more flexible and portable. We have been planning
to develop our own library because we didn't expect to find a good
existing match for our requirements. At this point GDAL is looking very
promising and our hope is that we can use it without the need for internal
modifications to the core functionality. If so, we will be adding several
image formats, including NDF, MODIS, Landsat 7, CIB, and undoubtedly others
that I'm forgetting. Our efforts are government-sponsored and as such are
released into the public domain. So we will have no problems sharing any
code that we develop with the larger community.

Whether we decide to use GDAL or not, thank you for developing, maintaining,
and sharing your work.


Lowell (LAS support team)

-- 
--------------------------------------------------
Lowell D. Johnson
Software Engineering
Raytheon Systems
EROS Data Center
--------------------------------------------------