[gdal-dev] Re: 3 doubts on GDAL WKT Raster driver

[Jorge Arévalo]

Hello Frank, I put these questions on the list too.

2009/7/25 Frank Warmerdam <warmerdam at pobox.com>:
> Jorge Arévalo wrote:
>>
>> On one hand, if I want a driver that supports user-defined (or
>> raster_columns-defined, in this case) nodata values, I should
>> implement SetNoDataValue and GetNoDataValue methods on
>> RasterBand-derived class. SetNoDataValue method could simply store the
>> argument in a class property called "fNoDataValue", for example. And
>> GetNoDataValue could return this property. Ok, but... Don't I need
>> something more? Maybe a metadata entry? Which methods use this concept
>> of "NoDataValue" to perform any operation, or to take any decission? I
>> saw in PNG driver that only the method that create new datasets use
>> this nodata value. And it drives me to the next doubt...
>
> Jorge,
>
> I anticipate a few items needed for nodata support.
>
> 1) You need to initially read the nodata values for the different
> bands from the nodata_values array in the RASTER_COLUMNS table, and
> keep track of it on the band objects.

Yes, done. A property called "fNoDataValue" in the RasterBand keeps
the value. Enough?


>
> 2) You need to implement GetNoDataValue() to return that.

Done.

>
> 3) You need to implement SetNoDataValue() to update the value kept
> on the band, *and* to update the value in the RASTER_COLUMNS table.

Half-done :-). Easy to end.

>
> 4) The IReadBlock() method should fill the raster array with the
> nodata value if there is no corresponding block in the table.

OK, but only if the read nodata value for this block is different from
the nodata value in the raster_columns table, right? Oh, and the fact
that there's no corresponding block in the table is possible only in
cases of missing tiles, I suppose.

>
> Somewhat similarly, at some point you should implement SetGeoTransform()
> and SetProjection() in such a way that they update the
> pixelsize_x, pixelsize_y, extent and srid columns properly in
> the RASTER_COLUMNS table.  I'm not sure if there would need to be
> a bulk update of blocks in the table - I imagine so.  Ouch, I'm not
> sure if that should be high priority.

Understood. I think in common situations these values read from the
block will match the values in raster_column. So, I could set a lower
priority for this task. My high-priority tasks now are inplace update
and support for outdb rasters, plus correcting found errors (this is a
transversal task with highest priority always). I'm on the way :-)

>
>> The inplace update concept implies that I may want to update any
>> block/band information. For this reason, I've implemented the
>> IWriteBlock method on RasterBand-derived class. This concept is
>> different to the concept of creating new Datasets. Right?
>
> Right, this is not like creating a new dataset (table), or band
> on a dataset.  All IWriteBlock does is replace the raster value
> of an existing row, or create a new row with the new raster value
> for the block if the block did not already exist.

OK. Done and testing.



>
>>   If I want
>>
>> to support creating new datasets, I should implement the Create and/or
>> CreateCopy methods in Dataset class. Do I need to implement these
>> methods to support inplace update?
>
> Create() and/or CreateCopy() are not needed for inplace update.  However,
> you may find you need to extend the Open() method to track whether the
> dataset is being opened for read-only or read-write access.

Yes, done.


>
>> Finally, the concept of overviews. I've written the code to support
>> overview creation. This is: The Dataset-derived class has an array of
>> Datasets as a class property. I create as many sub-datasets as
>> overview tables related with the WKT raster table are. All the
>> datasets have a pixel size reduced by its overview_factor, and all of
>> them are stored in the array. Should I do anything more? I'm not
>> really sure.
>
> I do not think it makes sense to support creating overviews until
> such time as you have implemented Create or CreateCopy since I
> imagine alot of common mechanics will be needed.

OK, but I've written the code for reading overviews in the way I've
described. Do you think that's the correct way...


>
>> Summarizing, I've implemented these Dataset methods:
>>
>> - Open
>> - GetProjectionRef
>> - GetGeoTransform
>>
>> And these RasterBand methods:
>>
>> - IReadBlock
>> - IWriteBlock
>> - GetColorInterpretation
>> - SetNoDataValue
>> - GetNoDataValue
>
> How did you implement GetColorInterpretation()?  I was not aware
> that WKTRaster included any metadata about band color interpretation.
> If it does not, then you just leave the default implementation in
> place and avoid overriding it.

Yes, that was a doubt. I left the default implementation, because, as
you said, the WKT Raster don't include metadata about band color
interpretation, but later, I did a "default" interpretation. Simply,
if I have one band, I return Grey color, if I have 3 bands, RGB, and
if I have 4 bands, ARGB. Ok, they are only suppositions. 4 bands could
be CMYK scheme, instead of ARGB. I'll delete this implementation.


>
>> Plus additional auxiliary methods, and constructors/destructors.
>>
>> Should I implement any additional method if I want to support nodata
>> values, inplace update and overviews support? In addition to the
>> basis, of course (read-only support for regularly-blocking multiband
>> rasters)
>
> I believe overview creation is pretty involved.  Do you already have
> overview reading implemented?  Do you know if Mateusz has added support
> in his loader script to build overviews?

Yes, I've implemented overview reading. And Mateusz' script allow
building overview tables and overview metadata table.

>
> BTW, I think the above questions would be good ones to have asked on
> the list - adding the possibility of other useful feedback.

Done :-)

Thanks for responses.

Best regards
Jorge