[gdal-dev] More multiresolution and datatype questions

[ldjohn at u...]

On Thu, 18 Oct 2001, Frank Warmerdam wrote:

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

Hello Frank,

OK, adding bands sounds good to me. I'm also investigating the use of the
Create() control parameters for handling multiple data types as was
mentioned previously.

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

We are creating a new LAS data format that will handle multiresolution,
multi-datatype images. We are doing this because we have to support
Landsat 7, ASTER, and MODIS formats, all of which are multiresolution
(in addition, MODIS is multi-datatype) formats. With our existing LAS
data format, we have to break multires images into multiple images, one
per resolution/datatype. This makes the book-keeping rather messy.

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

Sounds good. If actual overviews were built for the second band, I assume
they would be subsampled from the 500x500 data. So we would not expect
any additional second-band overviews to have resolutions over 500x500 (but
they would be legal). Is that true? Say we added a 250x250 overview. An
application would see a 1000x1000 band with two overviews. For a
MultiResDataset-aware application, would only one overview (250x250) be
reported? I don't know enough about GDAL overview usage to know if this
even makes sense.

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

Yes, I have been prototyping the existing LAS data format into a
LASDataset class derived from the RawDataset class.

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

OK, sounds good.

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

That would be much appreciated. Thank you.

Over the last couple of weeks, our investigations combined with your 
helpful responses have pretty much sold us on using GDAL for our new
image I/O library. So, barring any unforeseen obstacles, I expect that we
will be moving forward with plans to incorporate GDAL into LAS. In
return, we will be releasing any and all formats that we add to GDAL.


Lowell
-- 
--------------------------------------------------
Lowell D. Johnson ldjohn at u...
Software Engineering
Raytheon Systems
EROS Data Center
47914 252nd Street, Mundt Federal Bldg
Sioux Falls, SD 57198
--------------------------------------------------