[gdal-dev] Multiresolution images

[Frank Warmerdam]

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.
% gdalinfo gltp:/adrg/usr4/mpp1/adrg/TPUS0101
Driver: OGDI/OGDI Bridge
Size is 1000, 1000
Coordinate System is `'
Origin = (-88.000183,36.000089)
Pixel Size = (0.007001,-0.004000)
Subdatasets:
SUBDATASET_1_NAME=gltp:/adrg/usr4/mpp1/adrg/TPUS0101:"TPUS0101.IMG":Matrix
SUBDATASET_1_DESC=TPUS0101.IMG as Matrix
SUBDATASET_2_NAME=gltp:/adrg/usr4/mpp1/adrg/TPUS0101:"TPUS0102.IMG":Matrix
SUBDATASET_2_DESC=TPUS0102.IMG as Matrix
SUBDATASET_3_NAME=gltp:/adrg/usr4/mpp1/adrg/TPUS0101:"TPUS0101.IMG":Image
SUBDATASET_3_DESC=TPUS0101.IMG as Image
SUBDATASET_4_NAME=gltp:/adrg/usr4/mpp1/adrg/TPUS0101:"TPUS0102.IMG":Image
SUBDATASET_4_DESC=TPUS0102.IMG as Image
...

The subdatasets names end up going to the same driver in this case but
the extra details (layer name, and access type in this case) are encoded
into the dataset name in a manner particular to the driver. Then it is
possible to act on this particular image name.

eg.
% gdalinfo gltp:/adrg/usr4/mpp1/adrg/TPUS0101:"TPUS0101.IMG":Matrix
Driver: OGDI/OGDI Bridge
Size is 14464, 1152
Coordinate System is `'
Origin = (-88.000183,32.460636)
Pixel Size = (0.000484,-0.000400)
Corner Coordinates:
Upper Left ( -88.0001833, 32.4606361)
Lower Left ( -88.0001833, 31.9998280)
Upper Right ( -80.9996073, 32.4606361)
Lower Right ( -80.9996073, 31.9998280)
Center ( -84.4998953, 32.2302321)
Band 1 Block=14464x1 Type=Byte, ColorInterp=Palette
Min=0.000/0, Max=255.000/0
Overviews: arbitrary
Color Table (RGB with 217 entries)
0: 0,0,0,0
1: 0,0,0,255
...


Note that the subdataset mechanism just provides a standard way for
applications to browse the file, and offer choices to the user. You
can skip that and still implement a mechansim based on encoding extra
information into the dataset name to get at particular images. However,
it is only useful if the user knows what to type then.

The subdatasets are returned as a particular kind of metadata. Let me know
if you want to pursue this. BTW, the OpenEV application now knows how
to prompt the user for a subdataset if subdatasets are available.

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