NetCDF Driver Improvements

[warmerdam]

Paavo Jumppanen (CSIRO) has prepared substantial improvements to the netcdf driver. He recently updated them and writes:

I've looked at and integrated my changes into the gdal-1.4.2 code and
now a a working development version. My modified driver behaves as the
unmodified one when used in the normal way. My interpretation XML I have
ditched in place of arguments passed in the filename in a manner in the
same spirit of the original driver. I did so to be consistent with the
spirit of GDAL and to not lead to confusion as there appears to be other
XML stuff in the library that I'm not familiar with. The changed files
I've attached to this email.

The functionality of the new driver is much the same as my old variant
except in the way it is specified. This is summarised in my comment
block for the netCDFInterpretation class:
//
------------------------------------------------------------------------
-----
// class netCDFInterpretation

//
------------------------------------------------------------------------
-----
// The purpose of this class is to extract and collate explicit meta
data
// from the string passed to GDAL when requesting to open the file. This

// extra meta data allows users to customise the way in which the netCDF
// driver interprets the data within the specified netCDF file. The 
// following key value pairs can be appended to the open string to
change
// driver behaviour:
//
// units=<units value>
// coordinates=<lon name>,<lat name>
// extent=<left value>,<top value>,<right value>,<bottom value>
// range=<min value>,<max value>
// scaling=<scale value>(,<offset value>)
// hue=<start hue value>(,<end hue value>)
// lightness=<start lightness value>,(<end lightness value>)
// saturation=<start saturation value>,(<end saturation value>)
// bands=<N>
// band<1>=<var name 1>,<var value 1>,<var name 2>,<var value 2>...
// band<2>=<var name 1>,<var value 1>,<var name 2>,<var value 2>...
//  .
//  .
//  .
//
// As an example, we might have this in a Mapserver layer definition:
//
// DATA
NETCDF:"SSTcomp3d_Aasia_1995.nc":sst:coordinates=lon,lat:range=5,30:unit
s="degrees
C":hue=240,0:lightness=128,156:saturation=255:scaling=0.16,15:bands=1:ba
nd1=time,11768
//
// This tells the driver which variables to use for longitude and
latitude,
// the range to display (values outside the range are transparent), the 
// units of the data, the HLS colour map to use to colourise the data,
// the scaling to apply to the raw data, the number of bands to create,
// and how to select that band. In the last instance, the band<N> entry
// is used to specify the missing coordinate values for the band in
cases
// where the number of coordinates in the array data is greater than
two.
// To be able to use the colour map you msut also specify a range for
the 
// mapping to be applied to.
//
------------------------------------------------------------------------
-----

Basically, if you open with,

DATA NETCDF:"SSTcomp3d_Aasia_1995.nc":sst

It works the old way. If you add any extra parameters then it does it
the new way based on what you've specified. If you wish to include it in
the code base I would be delighted. If you don't I'll live with that and
just maintain the extensions I need privately. 

There is one issue that disturbs me though. I found an issue with the
current driver code whereby if you have a data set in which the top y
coord value is less than the bottom y coord value the image gets
flipped. It's hard to explain but it happens with a very useful
bathymetry file we have at CSIRO. With the old driver no matter what I
did there is no way I could get the image coming up the right way. It's
a long time since I looked into that issue so my recollection of the
reason is not clear but there are comments in the code describing it. 

        //Here we have arranged the transformation such that the maximum
        //y values are always top and the scale is always negative. 
        //Stictly speaking this is clearly not necessary although I am 
        //doing it this because I need to, as images of that type end up
        //being flipped for some reason that I'm unsure of.
        double dOrigin;
		.
		.


The reason why I'm mentioning it to you is that my gut feeling is that
the real source of the problem lies elsewhere but I don't understand the
code well enough (and don't have the time to learn it in detail) to be
able to fix it in the right place. The fix I wrote seems to work without
side effect, and I did the re-write to the latest code base such that it
does not utilise my fix if opening in the old way, only when you add
extra parameters to the filename. Therefore, it should be safe for
existing users. If you happen to figure out the "real" reason why this
happens and the "best" fix then I'd be truly greatful.

Regards,

Paavo.