Re: 20050922:DODS/THREDDS confusion

• To: David Wojtowicz <davidw@xxxxxxxx>
• Subject: Re: 20050922:DODS/THREDDS confusion
• From: John Caron <caron@xxxxxxxxxxxxxxxx>
• Date: Mon, 20 Feb 2006 14:09:27 -0700

Hi David:

There seems to be an intermittent error, im trying to track it down.
Are you using the ToolsUI program to look at that file?

There may also be an independent error in the dncdump program, but first let me 
find out the server problem.

thanks for your patience....

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