I am answering this question for Ward because I am the opendap person here at Unidata. In any case, the problem is that the columbia server is known to produce incorrect DAP2 responses. That is what is happening here. If you paste the following URLs in your web browser, you can see the problem. First, ask for the full DDS: http://iridl.ldeo.columbia.edu/SOURCES/.Models/.NMME/.NASA-GMAO/.MONTHLY/.sst/dods.dds You will see that the Dataset {...} is named MONTHLY. Next, ask for a subset of the DDS: http://iridl.ldeo.columbia.edu/SOURCES/.Models/.NMME/.NASA-GMAO/.MONTHLY/.sst/dods.dds?M,Y,L,X,S You will see that the name of the Dataset{...} has been changed to sst. This is incorrect and causes netcdf to produce an error. There are other known problems with the Columbia server, so introducing a hack to get around this probably will just make you run up against other problems. I will try to add such a hack, but it won't happen soon. =Dennis Heimbigner Unidata =Dennis Heimbigner Unidata Ticket Details =================== Ticket ID: XXI-796914 Department: Support netCDF Priority: Normal Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.