Unidata
ncdump DAP2 response mistakenly include variable’s attributes in the internal global attribute list
When doing ncdump -h http://test.opendap.org/opendap/GESDISC/3B-HHR.MS.MRG.3IMERG.19980101-S000000-E002959.0000.V07B.HDF5.dmrpp
You will see an "Name contains illegal characters” error.
After some investigation, I find this is a bug inside the DAP2 client.
Inside ncd2dispatch.c for the function buildglobalattrs(NCDAPCOMMON* dapcomm, CDFnode* root)
This function builds not only the global attributes but also the variables’ attributes.
For this DAP2 response: the variable name includes the path like /Grid/lat_bnds
The DAP2 client prepends the variable name for the variable attribute name.
So the attribute name becomes something like /Grid/lat_bnds.DimensionNames.
The character “/“ inside this internal attribute name causes this "Name contains illegal characters” error.
This error doesn’t happen in the DAP4 response. Uses the http://test.opendap.org/opendap/GESDISC/3B-HHR.MS.MRG.3IMERG.19980101-S000000-E002959.0000.V07B.HDF5.dmrpp.das to check all the attributes of this DAP2 response.
It is documented as part of the netcdf spec that '/' is an illegal character in names. So I fail to understand the complaint. You might want to talk to OPeNDAP organization about this.
This error doesn’t happen in the DAP4 response.
I do not understand this comment. I tried DAP4 and it also fails on same error.
This error doesn’t happen in the DAP4 response.
I do not understand this comment. I tried DAP4 and it also fails on same error.
Use ncdump -h "dap4://test.opendap.org/opendap/GESDISC/3B-HHR.MS.MRG.3IMERG.19980101-S000000-E002959.0000.V07B.HDF5.dmrpp" You should see ncdump successfully dumps the header of the data. That what I mean "this error doesn't happen in the DAP4 response."
It is documented as part of the netcdf spec that '/' is an illegal character in names. So I fail to understand the complaint. You might want to talk to OPeNDAP organization about this.
If the above statement is true, then netcdf doesn't implement this consistently. For example, for this file:
I can ncdump -h http://test.opendap.org/opendap/GESDISC/3B-MO.GPM.DPRGMI.CORRAGM.20140301-S000000-E235959.03.V07A.HDF5.dmrpp this successfully although the "/" is inside a variable name. I notice the variable name is twisted a bit but at least I can "ncdump -h" this successfully. I did a little more debugging inside the netCDF code with this file. The root->attributes inside the function buildglobalattrs doesn't include the variable attributes for this one. So it gets passed. I also notice the variables are treated as DAP2 Grids for the failed one. So somehow netCDF puts the Grid attributes inside the global attribute list and when it finds an attribute name contains "/", it correctly follows the netCDF naming conventions and issues an error. If you don't put Grid attributes in the global attribute list, the issue should be gone.
You are basically correct that there is an inconsistency with respect to '/'. The two datasets are encoded quite differently by the opendap server. In order to decide what the problem is, I need to refresh my memory about the algorithm used for DAP2. That will take some time, so you have to be patient.
In DAP4 fully qualified names are used, so it makes sense to me that the dap4:// protocol reference should work with ncdump
