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 Message
To: support@xxxxxxxxxxxxxxxx
From: David Wojtowicz <davidw@xxxxxxxx>
Subject: DODS/THREDDS confusion
Organization: UCAR/Unidata
Keywords: 200509221824.j8MIOEYJ003573
Hi,
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.nc
I 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.nc
If 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. Box
support@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/
---------------------------------------------------------------------------
