-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support setting/inquiring per variable fill mode for nc3 files #383
Conversation
I'm not certain we want to delete _FillValue if/when a variables fill mode is turned off. If fill mode is turned off and the _FillValue is removed, there is no way to easily determine what, if any, of the existing data in the variable was created by a fill value and what was 'real' data. That is the only thing that immediately occurs to me off the top of my head; I'll take a look at this tomorrow but I'll want to knock out gphull-375 first in terms of merging. @DennisHeimbigner any thoughts on this? |
I agree. Once turned on, _FillValue should stay defined for exactly your reason. I understand
|
… on or off a variable's fill mode
Somehow I mistakenly thought putting/deleting attribute _FillValue automatically turns on/off a variable's fill mode. I just pushed a fix. |
FYI |
Holding off on evaluating this until our internal meeting to review |
needs to be reviewed by maintainers
It turns out that the chunksize used in the ncio-related code must be a multiple of eight in size. Both memio.c and mmapio.c were potentially violating this constraint. See also pr Unidata#400
This reverts commit 09ba25c.
Fix NC_DISKLESS returns garbage data for certain files
…github.com/rouault/netcdf-c into v3.5.0-release-branch
The problem was that for opendap, it is possible to use keywords as identifiers when there is no ambiguity. However, the DAP2 parser lost the case of the identifier used the lower case version. Fix is to use the actual text of the symbol when it is used as an identifier. Also added a test case for this (kwcase.*). Additionally cleaned up some misc. dap2 testing problems. 1. ncdap_test/tst_ncdap3.sh was using an empty test set. restored the testing of datasets. 2. as a consequence of Unidata#1, some tests needed to be updated with minor tweeks. 3. fix dapmerge to handle multiple DODS_EXTRAS attributes. 4. modify buildattribute to suppress nul characters and terminate the name at the first nul. 5. clean up various test scripts to remove residual, unused references to obsolete netcdf-4 translation. 6. export e.g. NCDUMP from test_common.in so that non-top-level shell scripts can access it.
Please do not do this. It makes our job much harder when you do these kinds |
I simply merged the master branch to this pull request branch. |
I am confused. At the top of this pr, it says: |
Note this 383 pull request was created based on ghpull-375 (see my first post). |
Reviewed w/ @DennisHeimbigner, will go into 4.5.1 after the 4.5.0 release. |
Still on our radar but trying to get 4.5.0 out the door. Dealing with an issue now related to downstream tools handling _FillValue, see #458 for more information. |
I hope we can get this merged soon. Firstly, it will be a very useful improvement (I too have felt the lack of this function for classic files - it's a pain). Secondly, there are a lot of code changes in this PR, and meanwhile I am making a lot of code changes to these files for PIO. |
It will be a bit; working on some other issues/PR's that predate these ones, and having to switch gears to non-netCDF work. But will return to these ASAP. |
There are an awful lot of extra changes in this PR that have nothing to do with setting the fill value in nc3 files. What's up with that? I really want these fill value changes, but I really wonder what is going on with all the other changes. Are we reverting a bunch of code? Some of the changes look quite scary, like changing size_t to off_t. What's going on with that? @WardF there are loads of cmake build file changes in this PR. Is this expected? Shall I try and isolate the fill value changes from @wkliao, based on a current version of master, and only including changes related to fill value? Fill values have become a sticking point for me in several tests, so it would be nice if these features could be added, but not if they are going to break stuff. |
All my changes to support setting per-variable fill mode in this PR have been extracted to #731. |
OK, so should this PR be closed without merging now? |
In my opinion, it can be safely closed without merging. |
This pull request is related to issue #379.
The current netCDF limits the use of APIs
nc_def_var_fill
andnc_inq_var_fill
to NetCDF-4 files. This request eliminates such limit in order to support per-variable mode for the classic netCDF files. I developed this pull request based on branch ghpull-375 to reuse subroutineNC3_inq_default_fill_value
.Below is the summary of changes.
no_fill
, toNC_var
struct, so a variable can have its own fill mode.def_var_fill
outside ofUSE_NETCDF4
ifdef bracket inNC_Dispatch
struct. Similar changes to dispatcher objects in libsrc, libsrc4, libsrcp, and libdap2.nc_inq_var_fill
outside ofUSE_NETCDF4
ifdef bracket in libdispatch/dvarinq.cno_fill
andfill_valuep
, to the end ofNC3_inq_var()
._FillValue
, the variable's fill mode is turned on_FillValue
, the variable fill mode is turned offnc_set_fill
, fill mode is turned on/off for all variables already defined. Any variables defined successively will also use the same mode.nc_def_var_fill
to turn off fill mode, the variable's attribute_FillValue
is deleted, if defined.nc_enddef
, filling is done only for those variable with the fill mode turned on.