NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi, Ansley -- On Oct 27, 2009, at 8:04 PM, Ansley Manke wrote:
I don't know about other OPeNDAP servers, but GDS won't allow a .dods request without any constraints.Hi all,I'm trying to follow this. Dennis and I have been discussing this same issue with some testing I've been doing, experimenting with linking Ferret with netcdf-4 and with accessing URL's with ncdump.If I understand what's been said on this thread, some servers issue an error message when the request appears to request the entire dataset.
The OPeNDAP libraries ignored such errors, but the netcdf-4 calls do not.The OPeNDAP ncdump client (ncdump linked with libnc-dap) did not issue the un-constrained request, so the error message is new with netcdf-4 calls.
If we put a prefix on the URL, then the ncdump (or Ferret or GDS or whatever) call can be made;
I just tested it with the prefix: ncdump -c "[fetchlimit=1]http://monsoondata.org:9090/dods/model"and I still get the error message "subset requests must include a constraint expression"
or perhaps changes can be made in the way the server is set up to change the situation.I would like to avoid patching the GDS or GrADS to use the DAP interface in netcdf-4, if possible.
I guess I'm not happy about having to tell users they need to add something in order to use URL's which have worked for a number of years, or about having to change application code so it recognizes and passes a prefix on through to the open-nc routine.
I agree completely.
Might there be a way to know that the intent is, say, just for a "ncdump -c" which is after all just going to read the coordinates, and not stop on the error?I think the un-constrained request from the netcdf-4 dap interface is risky. If it's a data set of any significant size, the request would be unreasonably large and bring the server and the client to a grinding halt.
In any case, the error messages available after "setenv OCLOGFILE" are highly useful.
YES!
This output received by Ferret is much more helpful than the error code alone. Can things be set so that the application can get this kind of message? Could the Warnings and Errors be separated so that we could get one and not the other?It's great that the GDS error message gets piped all the way back to the client. The warnings are a bit alarming, I agree it would be good to be able to filter those out.
This is the same thing that happens with GrADS and with 'ncdump -c' both programs fail when trying to download the coordinate data.yes? use "http://monsoondata.org:9090/dods/model" ...Error: :oc_open: server error retrieving url: code=0 message="subset requests must include a constraint expression"** unknown netCDF error code: -70 lat
--Jennifer
Ansley Dennis Heimbigner wrote:Jennifer Adams wrote:Hi, Dennis -- I'm sorry to pepper you with questions, but I think this is really important and I'm eager for the DAP interface in netcdf-4 to work well with GrADS and the GDS.No problem; I need all the feedback and bug reports and opinions I can get :-) I want to get this right.Requiring prefixes on OPeNDAP URLs is inconsistent with libnc-dap and a pretty significant change to the OPeNDAP user interface.Actually, libnc-dap has always supported the prefixes, although you probably never used them. I too would like to get rid of them and hopefully the defaults will be such that user rarely need them.Can configuration options such as [fetchlimit=1] be parsed from the user's .dodsrc file instead?This is an open issue here in the netcdf group. Historically, the use of environment variables or .rc files has been avoided in favor of various flag setting extensions to the interface.Also, if client-side cacheing is disabled, will that append the '? varname[constraints]' syntax to requests like 'GET model.dods'? -- JenniferYes, it will ask for a specific variable only and will do so using dap projection constraints. =Dennis Heimbigner _______________________________________________ netcdfgroup mailing list netcdfgroup@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
-- Jennifer M. Adams IGES/COLA 4041 Powder Mill Road, Suite 302 Calverton, MD 20705 jma@xxxxxxxxxxxxx
netcdfgroup
archives: