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.
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 David,Yeah, this has been an issue for some time (seems to have started on this list in 2003, http://www.unidata.ucar.edu/support/help/MailArchives/dods-tech/msg01910.html).
The underlying issue is that netCDF-3 doesn't understand String, it only knows char and arrays of char, and OPeNDAP knows String but not char. So, the mapping between netCDF-3 and OPeNDAP is a bit thorny. The current nc servers map char arrays to String arrays (so each String contains one character). The TDS maps char arrays into Strings. The problem is that the nc client library doesn't know how to map Strings back into char arrays just from the DDS/DAS because the length of Strings can vary. (The TDS contains some hints in the DAS, that is how the netCDF-java library knows how to deal with them.)
I don't know if this comes up anywhere else. But it will be an issue for any OPeNDAP dataset that contains String arrays. Do any of the other servers map things to String arrays?
Sorry I don't actually have any answers but since this is in some ways an issue for the TDS, I'll look into this some more.
Ethan David Wojtowicz wrote:
Is there any update on the problem below that I first reported in September? The short of it is that one can't do the following: dncump -h http://motherlode.ucar.edu:8080/thredds/dodsC/station/metar/Surface_METAR_20 060220_0000.nc It chokes when it hits string data in the file. You also end up with an error if you try to access any of the string data from the libnc_dap interface. If you copy the file locally, without going through DODS, it works fine. THREDDS is of limited value to me if you can't open the datasets with DODS-netcdf clients. ----- David Wojtowicz, Sr. Research Programmer, Sysadmin Dept of Atmospheric Sciences / Computer Services University of Illinois at Urbana-Champaign davidw@xxxxxxxx (217) 333-8390 -----Original Message----- From: owner-thredds@xxxxxxxxxxxxxxxx [mailto:owner-thredds@xxxxxxxxxxxxxxxx] On Behalf Of John Caron Sent: Thursday, September 22, 2005 4:26 PM To: David Wojtowicz; dods-tech@xxxxxxxxxxxxxxxx Cc: support-netcdf-java@xxxxxxxxxxxxxxxx; 'support-thredds' Subject: Re: 20050922:DODS/THREDDS confusion Hi David: The problem is that the opendap server ("DAP++ 3.5.2") uses this form for Strings: forecasttime: Array of Strings [record = 0..4][time_len = 0..20] * long_name: "forecast date and time" using the "translate a char into a String" method. However, the THREDDS server uses variable length Strings: forecasttime: Array of Strings [record = 0..4] * long_name: "forecast date and time" * DODS: o strlen: 21 o dimName: time_len using the "strlen Convention" to tell the client what the String lengths are. Does anyone on dods-tech know if the opendap-netcdf client library will support the latter?He has version "netCDF Client Library 3.5.2"Unidata Support wrote:------- Forwarded MessageTo: support@xxxxxxxxxxxxxxxx From: David Wojtowicz <davidw@xxxxxxxx> Subject: DODS/THREDDS confusion Organization: UCAR/Unidata Keywords: 200509221824.j8MIOEYJ003573Hi,I'm primarily using the Dataset Viewer to browse the catalog and locate DODS URL's that I access in my own applications via the latest OpenDAP libraries.2) If I locate an entry inside "Previous version OPeNDAP NetCDF Server" I can get a DODS URL like this:http://motherlode.ucar.edu/cgi-bin/dods/DODS-3.4.3/nph-dods/dods/ model/2005092215_ruc_211.ncI can do a "dncdump -h" on that URL and get the expected header info.... and also use this URL within my own programs to access the dataset.However, I'm reluctant to continue using that as the name "Previous version" implies that it's being replaced by something newer and is going to go away.The "new" entries such as under "NCEP Model Data (netCDF) " I get different OpeNDAP URLs that look like:http://motherlode.ucar.edu:8080/thredds/dodsC/model_nc/ ruc_211/2005092213_ruc_211.ncIf I pass this URL to "dncdump -h" I get output that is both incomplete and contains invalid data. Tried this with a number of other data files in the same area.The "NCDUMP" function in the Dataset Viewer program however, seems to work fine.Is this a different format/protocol? I'm using the latest available SDKs... "DAP++ 3.5.2" and "netCDF Client Library 3.5.2" that I downloaded from opendap.org and compiled myself under linux.I'm further frustrated by the fact that most of the documentation/ status pages that I find on www.unidata.ucar.edu haven't been updated in a while and don't reflect recent changes.David Wojtowicz, Sr. Research Programmer Dept of Atmospheric Sciences / Computer Services University of Illinois at Urbana-Champaign davidw@xxxxxxxx (217) 333-8390 --**************************************************************************** <Unidata User Support UCAR Unidata(303)497-8643 P.O. Boxsupport@xxxxxxxxxxxxxxxx Boulder, CO---------------------------------------------------------------------------- <Unidata WWW Service---------------------------------------------------------------------------- <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. ------- End of Forwarded Message
-- Ethan R. Davis Telephone: (303) 497-8155 Software Engineer Fax: (303) 497-8690 UCAR Unidata Program Center E-mail: edavis@xxxxxxxx P.O. Box 3000 Boulder, CO 80307-3000 http://www.unidata.ucar.edu/ ---------------------------------------------------------------------------
thredds archives: