[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