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, > > [email protected] > > 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
