Closed rsignell-usgs closed 7 years ago
@DennisHeimbigner Any thoughts on this Dennis? This seems very high priority.
Serious bad on my part. For some reason, I changed the set of characters allowed n a DAP name. In particular, characters that are legal according to the DAP spec were removed. So when one of this removed characters was encountered, it produced a parse error. In this case, the offending character was a single quote character in the name: Blackadar's_mixing_length_scale_hybrid
The reason it worked for java is because the escape character set is correct and different than the one in the netcdf-c dap code.
Branch dapescape.dmh will fix to re-insert those removed characters.
@DennisHeimbigner, at least you found the problem quickly!
Which version of netcdf was this bug introduced?
Do not know. And I sadly do not have the time right now to track it down.
@DennisHeimbigner , okay. Can you at least provide the URL of the code fix you describe?
I did not see a branch called dapescape.dmh
here and did not see a fork on your account.
Oops forgot to push the branch. I am attaching the changed file: oc2/daplex.c (in zipped form) daplex.zip
Fixed by pull request https://github.com/Unidata/netcdf-c/pull/573
I'm getting #573 merged into master now, travis is the bottleneck. @rsignell-usgs we are hoping to get a 4.5.1 maintenance release out within the next week. This fix will be included.
Reopening this issue so that it doesn't fall by the wayside if something happens with merging #573
Thanks @DennisHeimbigner for the fix. I backported that PR to the conda-forge package and everything is working as expected. (Looking forward a 4.5.1 release :wink:)
@WardF Mathworks has been waiting for a 4.5.1 release so they can fix Matlab's netcdf interface.
I notice that the 4.5.1 milestone was deleted.
Did you guys hit some serious problem?
We have had a big enough delta that I renamed it to 4.6.0; same release, bigger number. It will be out shortly and includes bug fixes and the new compression work Dennis did.
Sorry. Shortly means relatively soon, not later today. I’m hoping before I head in Christmas vacation.
Well, you know what :gift: I would like for Christmas, I guess. :stuck_out_tongue_closed_eyes:
This NCEI opendap endpoint on the new NCEI THREDDS server works in NJ ToolsUI 4.6.10, but fails in NetCDF 4.5 ncdump:
Dataset: https://www.ncei.noaa.gov/thredds/dodsC/namanl/201609/20160929/namanl_218_20160929_1800_006.grb.html
OPeNDAP URL: https://www.ncei.noaa.gov/thredds/dodsC/namanl/201609/20160929/namanl_218_20160929_1800_006.grb
Working in
ToolsUI
:Failing in
ncdump
:results in:
This is wrecking havoc on our modeling community. All they know is that the workflows they used to use in Matlab (which uses ncread, which uses netcdf c library) are failing on NCEI datasets that used to work (when the OPeNDAP endpoints were from Grads, before the recent move to THREDDS).
Please help us understand what the problem is so we can either:
Thanks!!