[gdal-dev] More multiresolution and datatype questions

[Lowell Johnson]

Hello Frank,

Thanks for the response. I wanted to drop a quick note with a few short
replies. I don't have a good picture of exactly what you are suggesting,
but it sounds like something that will most likely work fine for us.

On Fri, 12 Oct 2001, Frank Warmerdam wrote:
> 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?
> 
> 
> Lowell,
> 
> 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.

Yes, after sending my last message I thought about the use of the options
list. That does seem like an acceptable solution at this point.

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

[snip]
> > 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?

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.

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

Yes, that sounds much more straightforward for our situation. I do like
the subdataset capability for its flexibility, but for this particular
issue (simple multiresolution) it seems a bit awkward.

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

No apology necessary. I appreciate the thoughtful response and concern
given to our issues.

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

Thank you. Once I have more detailed comments and questions, I may indeed
give you a call for discussion.

Thanks again for your help. Talk to you later.


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