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

[Jorge Arévalo]

Hello,

2009/7/29 Frank Warmerdam <warmerdam at pobox.com>:
> 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,
> 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
>
>