Opened 16 years ago
Closed 5 years ago
#2540 closed enhancement (wontfix)
[PATCH] Band selection in NETCDF driver
Reported by: | gaffigan | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | closed_because_of_github_migration |
Component: | GDAL_Raster | Version: | unspecified |
Severity: | normal | Keywords: | netcdf |
Cc: | dnadeau, capooti, Oleg.Goussev@… |
Description
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.
Attachments (3)
Change History (13)
by , 16 years ago
Attachment: | frmts_netcdf_bands.patch added |
---|
comment:1 by , 16 years ago
Cc: | added |
---|---|
Component: | default → GDAL_Raster |
Keywords: | netcdf added |
comment:2 by , 12 years ago
Cc: | added |
---|
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
by , 12 years ago
Attachment: | netcdf-selectbands.txt added |
---|
comment:3 by , 12 years ago
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.
follow-up: 5 comment:4 by , 12 years ago
You mean my approach (band number) makes more sense for you than the approach suggested in this ticket (indicies of higher-order dimensions)?
comment:5 by , 12 years ago
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).
comment:6 by , 12 years ago
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
comment:7 by , 12 years ago
Cc: | added |
---|
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.
by , 12 years ago
Attachment: | netcdf-bandno-1.txt added |
---|
comment:8 by , 9 years ago
Summary: | band selection in NETCDF driver → [PATCH] Band selection in NETCDF driver |
---|
comment:9 by , 6 years ago
Perhaps the driver http://www.gdal.org/frmt_netcdf.html supports all this nowadays, @etourigny?
comment:10 by , 5 years ago
Milestone: | → closed_because_of_github_migration |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
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.
patch to netcdfdataset.cpp