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. If we put a prefix on the URL, then the ncdump (or Ferret or GDS
or whatever) call can be made; or perhaps changes can be made in the way
the server is set up to change the situation.
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. 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?
In any case, the error messages available after "setenv OCLOGFILE" are
highly useful. 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?
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
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'?
--Jennifer
Yes, 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/