-
Notifications
You must be signed in to change notification settings - Fork 263
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
IRI data library opendap error from 1.4 to 1.5 #1041
Comments
Nothing has changed in the python interface that would affect this. You probably have linked a different version of netcdf-c. Can you print |
I should tell my admin who is installing jupyterhub to use libnetcdf=4.6.2 in the yml file? Or something else? (I am very new to this.) |
Here's what ncdump tells me: jeff-whitakers-imac-9:~/python/netcdf4-python.git] jsw% ncdump -h http://iridl.ldeo.columbia.edu/SOURCES/.Indices/.soi/.c8110/.anomaly/T/%28Jan%201979%29/VALUE/dods Error 404: Page Not FoundError line: 80 anhtmlserverefize 64000000 defreError on line 0 of stdin: interpreter thinks " .from" not defined
1000 ncdump: http://iridl.ldeo.columbia.edu/SOURCES/.Indices/.soi/.c8110/.anomaly/T/%28Jan%201979%29/VALUE/dods: http://iridl.ldeo.columbia.edu/SOURCES/.Indices/.soi/.c8110/.anomaly/T/%28Jan%201979%29/VALUE/dods: NetCDF: file not found Looks like a server-side issue to me, or an incorrect URL. |
I get
Of course, my ncdump is ancient.
|
I would suggest asking on the netcdf-c [issue tracker] (https://github.com/Unidata/netcdf-c/issues) why ncdump works for this URL for older versions of the netcdf-c, but not for 4.7.x. |
Thanks I will do that! (I am assuming that I should close this issue since it is a netcdf-c issue?) |
See here: |
re: Github issue Unidata#1832 and Github issue Unidata/netcdf4-python#1041 Handling of URL escape sequences for some servers (e.g. http://iridl.ldeo.columbia.edu) appears to be somewhat non-standard. In particular, certain characters need escaping that other servers do not. Fortunately, the changes should also work existing other servers.
re: Unidata#1876 and: Unidata#1835 and: Unidata/netcdf4-python#1041 The change in PR 1835 was correct with respect to using %20 instead of '+' for encoding blanks. However, it was a mistake to assume everything was unencoded and then to do encoding ourselves. The problem is that different servers do different things, with Columbia being an outlier. So, I have added a set of client controls that can at least give the caller some control over this. The caller can append the following fragment to his URL to control what gets encoded before sending it to the server. The syntax is as follows: ```` https://<host>/<path>/<query>#encode=path|query|all|none ```` The possible values: * path -- URL encode (i.e. %xx encode) as needed in the path part of the URL. * query -- URL encode as needed in the query part of the URL. * all -- equivalent to ````#encode=path,query````. * none -- do not url encode any part of the URL sent to the server; not strictly necessary, so mostly for completeness. Note that if "encode=" is used, then before it is processed, all encoding is turned of so that ````#encode=path```` will only encode the path and not the query. The default is ````#encode=query````, so the path is left untouched, but the query is always encoded. Internally, this required changes to pass the encode flags down into the OC2 library. Misc. Unrelated Changes: * Shut up those irritating warning from putget.m4
In version 1.5.4
fails and gives the error:
In version 1.4.2 it does not.
The text was updated successfully, but these errors were encountered: