[gdal-dev] Re: [SoC] GDAL WKTRaster weekly report #9

[Even Rouault]

Le Friday 31 July 2009 18:04:14 Jorge Arévalo, vous avez écrit :
>
> Yes, it's not commited yet. But, where do you store the overviews? The
> overviews are a kind of datasets exposed via GetOverview method and
> based in the first level dataset, right? So, when I'm creating a
> dataset, I can create overviews as other datasets that are stored in
> an array in the more general dataset. Then, they are like "children
> datasets". Is this point incorrect?

You can have a look at the GTiff driver (but just a quick one as it is an 
horrible complex thing. I don't want you to have an headache ;-)), for an 
example of a driver that support its own overviews, especially 
GTiffRasterBand::GetOverviewCount() and GTiffRasterBand::GetOverview() in 
frmts/gtiff/geotiff.cpp

It works exactly the way you've described : the base dataset has an array of 
children datasets, one for each overview level. It is responsible for 
instanciating them and destroying them in its own destructor.

>
> > Is there any mechanism currently for creating overviews?  How have
> > you been testing overviews?
>
> gdal2wktraster script is able to construct overview tables, as Mateusz
> said. I tested the code by creating an overview of a dataset (with
> gdal2wktraster script) and reading it with gdalinfo as metadata of
> SUBDATASETS domain. I need more testing at this point, to somehow read
> each overview and maybe store it as out-db raster. I'm not sure on how
> to test it properly.

If you support overviews with the standard GetOverview() mechanism of a raster 
band, you should be able to display them by using any GDAL based viewer 
(qgis, openev) and zooming out the raster by the appropriate factor. Or 
gdal_translate -outsize 50% 50% in_dataset out_ovr_2.tif, will just extract 
the overview of factor 2.

>
> > Under DOUBTs you ask what happens if the bounding box of a block
> > does not match any real block in the table, what should happen.  In this
> > case IReadBlock() should fill the buffer with the nodata value (zero if
> > nodata is not set).
>
> Ok, understood.
>
> > You also mention a doubt about how to handle the 16BF type, which is
> > apparently "16-bit float".  I have never seen such a thing before and I'm
> > not sure why it is part of the WKTRaster specification. I would suggest
> > removing it.
> >
> > However, if we wanted to support it (and you could figure out what it
> > actually is), then I think it would be most appropriate to transform it
> > into a 32bit float as it is read in IReadBlock().  Presumably the full
> > range of a 16bit float could not be kept in a 16 bit integer.
>
> Actually, now I transform it in a 32bit float
>
> > Likewise, 1BB, 2BUI, and 4BUI values (if supported) should be
> > translated on the fly into GDT_Byte values.  However, there is a special
> > NBITS metadata item in the IMAGE_STRUCTURE metadata domain that can
> > be set in these cases to represent the special nature of the image data.
> > Likewise there is a special value to indicate signed eight bit integers.
> > These values are discussed in:
> >
> >  http://trac.osgeo.org/gdal/wiki/rfc14_imagestructure
> >
> > However, I consider implementation of these esoteric types optional given
> > the relatively limited time remaining.
>
> Ok. Added to my todo list.
>
>
> Thanks Frank
>
> Best regards,
> Jorge
>
> > Best regards,
> > --
> > ---------------------------------------+---------------------------------
> >----- I set the clouds in motion - turn up   | Frank Warmerdam,
> > warmerdam at pobox.com
> > light and sound - activate the windows | http://pobox.com/~warmerdam
> > and watch the world go round - Rush    | Geospatial Programmer for Rent
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev