Opened 17 years ago

Last modified 5 years ago

#1808 closed defect

NetCDF Driver Improvements — at Version 1

Reported by: warmerdam Owned by: warmerdam
Priority: normal Milestone: closed_because_of_github_migration
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords: netcdf
Cc: Mateusz Łoskot, dnadeau, PCJ, Kyle Shannon

Description (last modified by 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. 

Change History (1)

comment:1 by warmerdam, 17 years ago

Description: modified (diff)

Trim out unrelated flipping issue.

Denis, would you be in a position to review and apply the driver changes? If not, I can turn it over to Mateusz though he has little experience with the esoteric world of netcdf as far as I know.

Note: See TracTickets for help on using tickets.