[Gdal-dev] Possible enhanced NetCDF support in GDAL

A.Th.C. Hulst hulst at argoss.nl
Wed Jul 18 02:59:54 EDT 2007


Hi Paavo,

> Sorry for the delay in responding. I was away on a winter break from
> work.
I was slightly confused about this remark until I realized that your in 
Australia :P

On Wednesday 18 July 2007 07:27:32 you wrote:
> True, the gdal-1.4.2 build correctly interprets the structure to the SST
> file so I could technically use it as is except for the lack of colour
> table and data scaling through the offset and scale parameters in the
> file.
The latter issues are addressed by my hack. I have an updated netcdf.cpp of 
1.4.1. I don't believe there were any changes made to the driver for 1.4.2.

> However, even if that were possible it would be a bad idea to use
> it as is for our mapping application because of speed. The driver as is
> will take all the data in the selected variable and create a raster band
> for each even though I only wish to use one of those raster bands. For
> files with small numbers of time slices this is probably not much of a
> penalty but in my case, we have 365 bands. If I run gdalinfo on my SST
> variable in one of these files it takes over a second for the program to
> complete running. Compare this with my gdal-1.2.6 reading just what I
> want it to, which is almost instantaneous.
For gdalinfo this is true, it loops over all bands. However, from the 
mapserver application and other utilities like gdal_translate a band can be 
chosen so this is not an issue.

I'm setting up a mapserver in our DMZ at the moment that will show a wave 
field that is directly read from a 700Mb netCDF file. Given that is a just a 
virtual server and does not have much resources, it should still perform 
well. My matrix size here is 248x288x157. I don't expect the performance to 
differ much for your file (365x720x181 ?).

I'll send you a personal e-mail with the URL and mapfile when I have 
everything working properly.

Sander









More information about the Gdal-dev mailing list