[gdal-dev] Is it possible to modify netCDF driver so that it
behaves like geotiff driver when operating on multiple datasets netcdf
file
Hendy Sumanto
hsumanto at vpac.org
Thu Mar 8 22:14:48 EST 2012
> I suggest you have a look at the recent netcdf driver in trunk, I have
> implemented proper handling of multidimension netcdf variables
> (T,Z,Y,X). This might be able to resolve your problem - providing you
> are able to create a netcdf file with multiple dimensions as this is
> not done by the driver.
>
> Basically, if a netcdf file has multiple dimensions (other than X,Y),
> the driver creates multiple bands in GDAL (as before), but when the
> file is written back to netcdf, the driver creates a single variable
> instead of a variable for each band. However, this does not work for
> gdalwarp directly, but works if using an intermediary VRT file.
>
> See http://trac.osgeo.org/gdal/ticket/2581
Really appreciate that you have implemented the proper handling of multidimension netcdf variables.
> You are confusing GDAL "dataset" with GDAL "band" and netcdf
> "variable", which is quite normal. Let me explain:
>
> A "dataset" has its own projection and geotransform(GT), and a number
> of bands which are (usually) of the same data type. In your gtiff
> example, there is one dataset in WGS84 GCS with multiple bands of the
> same type (Float64).
> A netcdf file can have many "variables", each with their own
> projection/geotransform (lon/lat variable and/or grid_mapping
> variable) and data type. So in many cases a netcdf file can contain
> many "datasets" (one for each variable) when opened in GDAL - which
> are treated as "subdatasets: (as in your example).
>
> So when translating a multi-band gtiff file to netcdf, the GDAL netcdf
> driver creates a variable for each band, so that is why a multi-band
> gtiff gets converted to netcdf with many variables (although they are
> of the same type and projection/GT).
Thanks for the clear explanation now I understand exactly the differences amongst GDAL "dataset", GDAL "band" and netcdf "variable".
> > I am wondering if it is possible to modify the current netCDF driver
> > so that it behaves like geotiff driver when operating on multiple
> > bands (datasets) netcdf file.
> > Any opinion on this is really appreciated.
>
> In order for the driver to create a netcdf file which will have
> muliple bands (and not sub-datasets) it would have to create a single
> variable, with an extra dimension (such as time or height/depth) to
> store the mulriple bands in a single variable.
> Another option would be to modify the driver to scan for all variables
> in Open(), and instead of creating subdatasets create a number of
> bands IF they are of the same type and projection.
>
> Either one are rather involved I'm afraid...
At a first think about it, the second option seems to be a better option.
It would be great if we could add this into netCDF driver improvements list.
> > This might be a potential issue though:
> > When the several datasets have the same data type, it is not an
> > issue but
> > when the several datasets have different data type (some datasets
> > are float while some other metadata are integer), then it might be
> > an issue as when we do gdalwarp operation selecting one method of
> > interpolation, that chosen interpolation method will be applied
> > across all data types for all datasets in that single file.
>
> I'm afraid that many file formats do not support bands of different
> data types (such as GTiff), which would make it difficult to translate
> to/from other formats.
> A potential limitation is the GDALDriver::Create() function which
> takes a single data type as argument.
> http://www.gdal.org/gdal_drivertut.html#gdal_drivertut_creation
>
> -> although individual drivers do not have to respect that (I think) -
> perhaps Even or someone else can comment?
Cool at least now I fully understand that GDAL do not support bands of different data types
as we are thinking to separate metadata variables which have different data type into separate netcdf file
instead of combining them with the actual data and possible just try to implement a mechanism which could be used
to append all these variable when user would like to have them combined in a single file.
Regards,
Hendy
More information about the gdal-dev
mailing list