[gdal-dev] How to consider data types when implementing IWriteBlock

[jramm]

Hi
I have implemented the write support in the NWT_GRD format, having to make a
few compromises. I'd like to go through them and see if they are reasonable.
I have also attached the diff.

1. The existing read driver reports 4 bands for a GRD dataset. The first 3
are essentially 'virtual' - they are RGB bands which are interpreted from
the single band of data actually on disk using color info in the header.
When opening in write mode, I have prevented more than 1 band being created.
Therefore in update mode, you cannot read from the 'virtual' bands; it is
created with 1 band to which you write the actual data. So you have some
slightly odd behaviour in that, you open it in `update` mode, it has 1 band,
you then close and reopen in `read only` mode, it has 4 bands. I wonder if
it would be better for the read driver to utilize the GDAL ColorTable stuff
somehow, instead of creating these 'virtual' bands?

2. The no data value is fixed on disk as 0; this is then converted to
-1.e37f by the read driver (as per the vertical mapper grid standard) upon
reading. On writing, I have allowed setting the no data value to anything,
and these values are treated as no data when writing. So you may create a
dataset having set the no data value to e.g. -999. However, when you close
it and open it in 'read' mode, the nodata value will be reported as -1.e37f

3. The GRD format supports data being written on disk as either 16bit
unsigned ints or 32bit unsigned ints, In the NWT_GRDRasterBand constructor,
allowance is made for this, however in the read driver, values are always
read as unsigned short (suggesting that if data were 32bit ints, we might
encounter over/underflow). I have done the same in the IWriteBlock, but I am
wondering if their should be a check to see whether the written value should
be an `unsigned short` or an `unsigned int`

4. Spatial Reference. The spatial reference is stored on disk in the 'MITAB'
format and a conversion function is used in the existing GetProjectionRef. A
function to convert the other way exists and I use this in SetProjection.
However, some stuff is obviously lost in the conversion as setting the
projection with e.g. EPSG:27700 and then reading it back loses the EPSG
information. Is there a way (using PamDataset maybe?) to store the GDAL
projection so that GDAL will always recognise it correctly, while still
writing the NWT_GRD format projection in the correct place in the tab/grd
file?

Are these reasonable compromises or can it be done better?

Thanks
James



--
View this message in context: http://osgeo-org.1560.x6.nabble.com/How-to-consider-data-types-when-implementing-IWriteBlock-tp5260901p5261675.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.