Hello, On Fri, Jul 31, 2009 at 8:41 PM, Even Rouault<[email protected]> wrote: > 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
Yes, I've read the GTiff code several times and I think it's really complex, but very useful too. Many thanks for the tip Even :-) > > 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. > So, I can create an array of children datasets to store the overviews, but I shouldn't add the datasets as metatada under SUBDATASETS domain. Is it right? >> >> > 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. > OK. Successfully tested :-). But I've found a mistake. When I create an overview (a children dataset), its properties are the same properties of the general dataset (his parent), apart from pixel size, table name and column_name, of course. The problem appears when sharing the PGconn object. My code looks like this: poDS->overview[i]->hPGconn = poDS->hPGconn If each dataset's destructor (from the general one and from the overviews) calls PQfinish over the same object, I get a segmentation fault after the first time, of course. So, I have 2 options: - Detect when a connection object has been freed, and perform only one call. How should I do this? - Don't share the PGconn object. Should I declare a static PGconn pointer? What is the best approach? Thanks in advance Best regards, Jorge >> >> > 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
