[gdal-dev] More multiresolution and datatype questions

[Frank Warmerdam]

Lowell Johnson wrote:

> > 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
> > characteristics.
> 
> I also think that the ability to incrementally build an image by adding
> individual bands at any time may come in handy in some situations.
> 
> If the datatype passed into the Create() function was a pointer, it could
> (optionally) be interpretted as an array (of size nBands) of data types.
> But that would mean a change to some of the core GDAL and possibly end
> applications, which (understandably) may not be a popular solution.


Lowell,

As you suspect, i am not keen on changing the Create() arguments. Lets plan on
adding a GDALDataset method for adding a band to an existing dataset.



> I'm not exactly sure what you have in mind regarding "the base level
> GDALRasterBAnd" and its specialized metadata, but this does sound like the
> kind of solution I was hoping for. Since the GDALDataset object contains
> the RasterXSize, RasterYSize, I was thinking that these values would define
> a "base band" resolution.
> 
> If you could flesh out a few more of the details of this idea to help my
> understanding, that would be greatly appreciated.


OK, I will try to spell this out a bit. Imagine one of your new multi-resolution
files (what format will they be in?) call abc.dat with two bands, one that is
1000x1000 and a second that is 500x500. Assume we have no "real" overviews
built.

To applications this file would look like a two band dataset that is 1000x1000.
The first band really is 1000x1000 and has no overviews as far as the application
can tell.

The second band appears to be 1000x1000 but also has a 500x500 overview. The
GDALRasterBand also has some particular piece of metadata which indicates that
the 500x500 data is the "real" raw data. Perhaps a "REAL_RAW_DATA=OVERVIEW_0"
or something like that. If an application accesses the second band normally
the low res data will be automatically resampled up to 1000x1000.

So, generic GDAL applications will just see this as a two band 1000x1000 dataset.
"Multiresolution aware" dataset can check the metadata, and access the overview
directly if they want the "real" data at it's native resolution.

I don't know if you have looked at how the formats are implemented or not.
Normally we would implement a format specific class derived from GDALDataset
for representing datasets of the format, and a format specific class derived
from GDALRasterBand for representing bands.

For our multiresolution format we might implement MultiResDataset, and
MultiResRasterBand for these roles. But we also need a "pseudo-band"
implementation that acts as the 1000x1000 second band that gets automatically
resampled. Lets call this "PseudoRasterBand" and when instantiated it would
basically be given a reference raster band that it would get data from in
order to satisfy application requests. This PseudoRasterBand could
potentially be used by other multiresolution formats than yours if it is
done right.

So when we open our hypothetical multiresolution dataset we would instantiate
a MultiResDataset with the first band being a MultiResRasterBand, and the
second band being a PseudoRasterBand. The second band would have an overview
band which is the 500x500 MultiResRasterBand that "feeds" the PseudoRasterBand.

I would be willing to implement the PseudoRasterBand for you if you would like.

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