[PATCH] Band selection in NETCDF driver

[gaffigan]

Allow selection of individual band using extended syntax

NETCDF:"filename":subdataset:index0:index1:...:indexN

where index0,...,indexN are indicies of higher-order dimensions

This is a subset of the enhancements included in ticket #1808, http://trac.osgeo.org/gdal/ticket/1808. In using the updates from that ticket, I had encountered segfaults when accessing grids through Mapserver. While waiting for those enhancements to be vetted and distributed in a future gdal release, I have instead been using the attached patch very extensively over the past year.

​http://ak.aoos.org/data/patch/frmts_netcdf_bands.patch

[gaffigan]

patch to netcdfdataset.cpp

[etourigny]

Paolo,

I have written a patch (attached here) which supports the following syntax, which can input a list of band numbers and sequences.

NETCDF:<file.nc>:<varname>:<bandnums> (<bandnums>=i,j-k,...)

However, this ticket (and the supplied path) suggests rather

NETCDF:"filename":subdataset:index0:index1:...:indexN

where the indexes are for the various netcdf dimensions, rather than GDAL band number.

1) Which approach do you think is more sensible?

2) Does it make sense to get more than 1 band (with my given syntax)

thanks, Etienne

[capooti]

Etienne, I have applied your patch at my gdal 1.9 installation and works really well with my datasets ;) In my case the band number approach makes more sense (this would let me avoid the virtual raster approach), but maybe it is just for me. For what I need to do, just getting a single band would be enough, but having the possibility to pull more bands would be handy, I think, in many cases.

[etourigny]

You mean my approach (band number) makes more sense for you than the approach suggested in this ticket (indicies of higher-order dimensions)?

[capooti]

Replying to etourigny:

You mean my approach (band number) makes more sense for you than the approach suggested in this ticket (indicies of higher-order dimensions)?

yes, in my case the band number approach (--> your patch) is fine. Not exactly sure, though, what it is meant with "indicies of higher-order dimensions".

FYI, my nc dataset is composed by 104 subdataset (one for each different variable) and each subdataset is composed by 10 bands (one for each day, in a 10 days scenario).

[etourigny]

Your files have 3 dimensions (X,Y,T). For file with 4 dimensions (X,Y,Z,T) you could specify the indices for each dimension e.g. NETCDF:file.nc:varname:1:2

[etourigny]

attaching a patch against current trunk. This allows to specify either the absolute band number as reported by gdal, or the indices for each higher-order dimensions

e.g. NETCDF:file.nc:varname:2 or NETCDF:file.nc:varname:1:2

Please test it against your datasets if you want it included in trunk!

If someone can supply a small dataset with at least T and Z, so I can make an autotest also.

[Jukka Rahkonen]

Perhaps the driver ​http://www.gdal.org/frmt_netcdf.html supports all this nowadays, @etourigny?

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.