Hello, 2009/7/29 Frank Warmerdam <[email protected]>: > Jorge Arévalo wrote: >> >> Hello, >> >> Here, the report: >> http://www.gis4free.org/blog/2009/07/26/gsoc-09-weekly-report-9-1707-2407/ >> >> And here, the project page: >> http://trac.osgeo.org/gdal/wiki/WKTRasterDriver > > Jorge, > > The progress looks good. You mentioned adding overviews tables as > subdatasets of the general dataset. This isn't the usual way of > representing overviews which should be accessable via GetOverview() on > the GDALRasterBand. Was this aspect done as well?
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? > > 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. > > 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
