[Gdal-dev] Possible enhanced NetCDF support in GDAL

A.Th.C. Hulst hulst at argoss.nl
Wed Jun 27 03:23:41 EDT 2007


I'm spilling some ideas here. Maybe the main developers have a comment or two?

On Wednesday 27 June 2007 08:42:45 you wrote:
> As an example, how would the current netcdf driver react to the nc file
> I have of SST which is in 3 dimensional arrays with 2 spatial and one
> time co-ordinate? How would I select a particular slice to display and
> would it automatically interpret the co-ordinates correctly? I have
> grave doubts that it would and that is why I have an external XML file
> to describe to the driver how it should interpret the metadata.
Consider one of my wave model result files which displays correctly as 
grayscale. Note that this gdalinfo includes my modifications.
----------------------------------
hulst at smartone:/var/www/mapserver/data/windwave$ gdalinfo ww3_output.nc
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
Driver: netCDF/Network Common Data Format
Size is 512, 512
Coordinate System is `'
Metadata:
  NC_GLOBAL#history=Generated by Argoss WMES
 <SNIP>
Subdatasets:
  SUBDATASET_1_NAME=NETCDF:"ww3_output.nc":zonal_wind_speed
  SUBDATASET_1_DESC=[169x157x288] zonal_wind_speed (8-bit integer)
  SUBDATASET_2_NAME=NETCDF:"ww3_output.nc":meridional_wind_speed
  SUBDATASET_2_DESC=[169x157x288] meridional_wind_speed (8-bit integer)
  SUBDATASET_3_NAME=NETCDF:"ww3_output.nc":sign_wave_height
<SNIP>
------------------------
and
------------------------

hulst at smartone:/$ gdalinfo netCDF:"ww3_output.nc":sign_wave_height

Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
Driver: netCDF/Network Common Data Format
Size is 288, 157
Coordinate System is `'
Origin = (-0.625000000000000,-78.500000000000000)
Pixel Size = (1.250000000000000,1.000000000000000)
Metadata:
  NC_GLOBAL#history=Generated by Argoss WMES
  NC_GLOBAL#descriptor=
  NC_GLOBAL#wind_source=gfs
  NC_GLOBAL#calibration_version=1
  NC_GLOBAL#assimilation_version=0
  NC_GLOBAL#grid_identifier=gl
  NC_GLOBAL#grid_configuration=4
  NC_GLOBAL#wmes_identifier=95
  NC_GLOBAL#model_identifier=3
  sign_wave_height#units=m
  sign_wave_height#_FillValue=-32768
  sign_wave_height#scale_factor=7.629511e-04
  sign_wave_height#add_offset=2.499962e+01
  time#_FillValue=-3.3e+33
  latitude#units=degrees_north
  longitude#units=degrees_east
  direction#units=degrees
  frequency#units=hertz
Corner Coordinates:
Upper Left  (  -0.6250000, -78.5000000)
Lower Left  (  -0.6250000,  78.5000000)
Upper Right (     359.375,     -78.500)
Lower Right (     359.375,      78.500)
Center      ( 179.3750000,   0.0000000)
Band 1 Block=288x1 Type=Float32, ColorInterp=Palette
  NoData Value=-32768
  Offset: 24.9996185302734,   Scale:0.000762951094657183
  Metadata:
    NETCDF_VARNAME=sign_wave_height
    NETCDF_DIMENSION_time=13654.5
    NETCDF_time_units=Days since 01-jan-1970 00:00:00

<SNIP>

Band 169 Block=288x1 Type=Float32, ColorInterp=Palette
  NoData Value=-32768
  Offset: 24.9996185302734,   Scale:0.000762951094657183
  Metadata:
    NETCDF_VARNAME=sign_wave_height
    NETCDF_DIMENSION_time=13661.5
    NETCDF_time_units=Days since 01-jan-1970 00:00:00
----------------------------------------

As you can see, you refer to the variable by name, and time slice by "band" 
number. This is a reasonable assumption as the record axis will be the time 
axis 9 out of 10 times.

In mapserver this would be referred to as:
DATA netCDF:"ww3_output.nc":sign_wave_height
PROCESSING bands="1"

In your case, it could be
DATA netCDF:"ww3_output.xml":sign_wave_height
PROCESSING bands="1"

which could cause OpenUsingInterpretationXML to search for a section with that 
variable type (sign_wave_height) and use it for coloring. You even could set 
a default coloring for unspecified variables. My idea was to add time axis 
support in a wrapper around mapserv. The wrapper would set the PROCESSING 
bands= parameter throught MapScript (Perl most likely).

Another option, more in the spirit of gdal, could be to extend the PROCESSING 
LUT="agimpfile" mechanism to accept your xml file. The advantage being that 
data and representation are seperated and one colorintrepretation file could 
be used for several netcdf files (you can remove the filename element). That 
would certainly be ideal for me as I produce gigs of netCDF data with 
atmospheric, oceanographic and tidal models.

It would then be:
DATA netCDF:"ww3_output.nc":sign_wave_height
PROCESSING bands="1"
PROCESSING LUT="myColorIntrepretation.xml"

Regards,
Sander




More information about the Gdal-dev mailing list