Re: 20050922:DODS/THREDDS confusion

Hi David,

Yeah, this has been an issue for some time (seems to have started on this list in 2003,

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.


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

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

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

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

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: model/

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: ruc_211/

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 and compiled myself under linux.

I'm further frustrated by the fact that most of the documentation/ status pages that I find on 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             

  • 2006 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: