OPeNDAP

See our web page What is the OPeNDAP software? page.

Available OPeNDAP servers are listed on our "Available OPeNDAP Servers" web page.
If your data is in a format for which an OPeNDAP server has already been written, simply download the appropriate server and install it on your machine. (See the User's Guide for details on how to install a server.)

If your data is not in a format with an existing server, you have two options. First, you can describe your data using the FreeForm data description language. Once you can describe your data with FreeForm, you can use the FreeForm server to make your data available. The second option would be to write a new server for your data format. The difficulty of this task would depend on the complexity of your data format. For developing a server in C++, see the Programmer's Guide and the Programmer's Reference and the tutorial Writing a Server for more information. For developing a server in Java, see the OPeNDAP Java JavaDocs. Please contact us at support@unidata.ucar.edu to discuss the options before you begin.

The data of OPeNDAP server's response is encoded using the XDR standard (eXternal Data Representation), and packed into the second part of the response document. For more information on XDR, see Internet RFC 1014. For further details, see OPeNDAP Programmer's Guide Section A.1.3.

See our "Available OPeNDAP Servers" web page.

Available OPeNDAP clients are listed on our "Available OPeNDAP Clients" web page. Many of the available clients come OPeNDAP enabled. Several of them need to be relinked with the OPeNDAP libraries.

Any application that can dereference a URL can be used as a simple OPeNDAP client. For instance, a standard web browser like Netscape or Internet Explorer can be used to look at various aspects of a OPeNDAP dataset. See our description of how to access OPeNDAP data with a browser.

Several spreadsheet applications (e.g., MS Excel and the StarOffice spreadsheet) can also be used as clients. They still do not have any specific knowledge of the special capabilities of the servers but are more data savvy than completely genereic Web clients. See our description of how to access data from an OPeNDAP server with a spreadsheet.

See our "Available OPeNDAP clients" web page.

A few possibilities:

1. Run ident on a particular program. This will give you the RCS $Id $ information for the pieces of software that make up that program.
2. For checking the version of a server, see the question How do I find a server's version?.
3. In Matlab or IDL run loaddods with the '-V' option.

See our current Software Downloads web page.

The major change in the core software from version 2.22 to 3.0 is the addition of several new data types (Int16, UInt16, and Float32). While old servers will continue to work fine, old clients (those built with core 2.22 or before) will not be able to process the new data types. However, they will work fine if none of the new data types are returned.

This problem can be solved by upgrading to the latest version of the client you are using. You can check on the version of the server you are accessing in several ways.

Here's an example of the output old clients will display when handed data in one of the new data types (this example is from loaddods in Matlab):

      >> loaddods('http://dcz/etc/nph-ff/data/ff/test1.dat')

      Reading: http://dcz/etc/nph-ff/data/ff/test1.dat
        Constraint: 
      In the dataset descriptor object:
      Expected a varaible declaration
      (e.g., Int32 i;). Make sure that the
      variable name is not a reserved word
      (Byte, Int32, Float64, String, Url
      Structure, Sequence or Grid - all
      forms, byte, Byte and BYTE, are the same)

      Could not parse data DDS.
      ??? 

      Error in ==> /usr/local/DODS/src/writeval-2.23/loaddods.mexsol
    

The major change in the core software from version 2.22 to 3.0 is the addition of several new data types (Int16, UInt16, and Float32). While old servers will continue to work fine, old clients (those built with core 2.22 or before) will not be able to process the new data types. However, they will work fine if none of the new data types are returned.

This problem can be solved by upgrading to the latest version of the client you are using. You can check on the version of the server you are accessing in several ways.

Here's an example of the output old clients will display when handed data in one of the new data types (this example is from loaddods in Matlab):

      >> loaddods('http://dcz/etc/nph-ff/data/ff/test1.dat')

      Reading: http://dcz/etc/nph-ff/data/ff/test1.dat
        Constraint: 
      In the dataset descriptor object:
      Expected a varaible declaration
      (e.g., Int32 i;). Make sure that the
      variable name is not a reserved word
      (Byte, Int32, Float64, String, Url
      Structure, Sequence or Grid - all
      forms, byte, Byte and BYTE, are the same)

      Could not parse data DDS.
      ??? 

      Error in ==> /usr/local/DODS/src/writeval-2.23/loaddods.mexsol
    

There are several ways to publicize a dataset, depending on the dataset and the community for which it is relevant.

• Register the dataset with the OPeNDAP project. Currently (June 2003),
  • go to the web site: http://unidata.ucar.edu/packages/dods
  • go to the "Datasets" pull-down menu at the top of the page
  • on that menu, go to "NVODS DODS Dataset" item. This will bring up the NVODS DODS Datasets list of known datasets.
  • at the top of that page, under the title, click on "Click here to submit a dataset" This will bring up a form asking for the basic information.
  • Fill out the form and submit it.
  • If there is other information you would like to provide to potential users, contact user support at support@unidata.ucar.edu
• OPeNDAP datasets automatically provide web pages to access the data. The page is basic, and provides no special information about the dataset beyond the variables in it. The next step in providing intelligent access for users is to
  • Create a web page that describes the data and provides access to the data through OPeNDAP. Examples of such pages are given on the NVODS site: http://nvods.org Click on the "Data Access Routes" button and go down the page to "Individual Data Provider Sites". Examples of pages devised and served by various data providers are given there. Once you have created and served such a page,
  • let us know at: contact@nvods.org and we will add your page to the list if is appropriate to NVODS list. Make sure that the web page you created provides direct OPeNDAP access to the dataset.
• We will work with you to write an appropriate news release to broadcast on the DODS, NVODS, and OPeNDAP web sites.
• OPeNDAP is a partner in the DODS (Earth Science Information Partner) in the ESIP Federation. We will work with you to write an "ESIP Nugget" to send to the Federation for their publicity machine. See esipfed.org for more information about the Federation.

For a given URL (e.g., http://test.opendap.org/dap/data/nc/coads_climatology.nc) and a given variable in that data set (e.g., SST), you would ask for a those data to be returned as ASCII using the following:

http://test.opendap.org/dap/data/nc/coads_climatology.nc.ascii?SST.

Note that you can take the base URL (http://test.opendap.org/dap/data/nc/coads_climatology.nc) and append '.html' to it and get a web page that provides a way to see the names of the variables in a data file, a way to build up more complex constraints interactively and to get those data in several different formats, including ASCII and NetCDF, from any recent DAP server such as Hyrax.

Another way to get data as a NetCDF file is to use a client that can access OPeNDAP data and knows how to output netCDF files. A simple example is the NCO (NetCDF Operators) package like this:

ncks http://test.opendap.org/dap/data/nc/coads_climatology.nc?SST out.nc

The NCO package supplies various command line tools for manipulating netCDF files and can be made OPeNDAP aware. See our "Available OPeNDAP Clients" web page for more information on NCO.

Notes:

• NCO tools can also be used to dump data in ASCII (like the OPeNDAP '.asc' extension) or IEEE binary format.
  
• In this example, the client expects to be passed a DAP URL, so the response format component is not used (i.e., coads_climatology.nc is used with a DAP-aware client like NCO, while coads_climatology.nc.ascii is used with a browser that does not contain special code to process the DAP URL).

See our Build Procedures? web page.

If your application accesses netCDF data through the standard netCDF library, it should be fairly straight forward to relink it with the OPeNDAP enabled netCDF library. First off, you will need some OPeNDAP libraries: the third-party-packages libraries; the OPeNDAP core (DAP) libraries; and the OPeNDAP netCDF library (see the Note below for some comments on library and compiler compatibilities). Second, you need to link your application with these libraries. This should involve adding several library flags to your normal compiling/linking commands. In particular:

• Instead of '-I/usr/local/netcdf/include' use the results of ncdap-config --cflags
• Instead of '-L/usr/local/netcdf/lib' and '-lnetcdf' use the results of ncdap-config --libs

For instance,

• OPeNDAP libnc-dap 3.7.4 release

   g++ -c -o sample.o `ncdap-config --cflags` sample.c 
   g++ -g -o sample sample.o `ncdap-config --libs` 	 

Note: We have found that using our pre-built binary versions of the libraries for relinking with your application can be problematic. The reason is that the compiler used to compile your application must match the compiler used to build the OPeNDAP libraries (often the version of compiler is important, too). For this reason, we generally suggest that you build the OPeNDAP libraries from source using the compiler you use to build your application.

We are using the GNU compilers (GCC 4.0.1 as of 22 Jul 2009). So, if you are using the same compiler and would like to try linking with our pre-built binaries, please let us know if you successfully link to our binary releases.

There are several possible ways to link your Fortran program with the DODS netCDF library. The libraries you must specify in the linking step depend on how you compile and link your program.

If linking with g++, you must specify '-lg2c' to make sure you link with the GNU Fortran libraries. For example,

 g77 -g -c `ncdap-config --fflags` sample.f 
 g++ -g -o sample sample.o `ncdap-config --flibs`

If you link with g77, use '-lstdc++' to include the C++ library. If you link with gcc, use '-lstdc++ -lg2c', to link with both the C++ and Fortran libraries. (You can compile your program with gcc, g++, or g77.)

If you are not using the GNU Fortran compiler, you will more than likely have to build the DODS netCDF library yourself. Also, if you link with g++, you will need to specify the libraries specific to your Fortran compiler. On the other hand, if you link with your Fortran compiler, you will need to specify the GNU C++ library, i.e., '-lstdc++'. To build the DODS netCDF library yourself, please take a look at the FAQ " How do I build the netCDF Fortran jackets?" and look for suggestions on building for your compiler (be sure to look in the non-DODS netCDF INSTALL file).

As you may have guessed, we stick with the GNU compilers when building our binary releases, generally from GCC 4.0.1 (as of 22 Jul 2009). Here are the environment variables we set:

• CC=gcc
• CXX=g++
• FC=gfortran
• FFLAGS=-g
• CPPFLAGS=-Df2cFortran

I believe our standard binary release should work for you if you are using g77, f2c, or fort77 (which uses f2c). This may work for other compilers as well. Please let us know if you successfully link to our binary releases with other compilers.

The main problem here is that, even though no Fortran is compiled while building the netCDF library, you must specify a working Fortran compiler to get the Fortran jackets. More to the point, you must specify the compiler that you will be using on your Fortran code. Since every Fortran compiler is different, the C code (the netCDF Fortran jackets) needs to be configured properly to allow communication with the Fortran code (your application).

So, this means that your netCDF library has to have been built with the same Fortran compiler you use to build your Fortran code. The DODS provided binary releases are built with the GNU compilers (gcc, g++, and g77), generally from GCC 2.95.2 (as of 11 Oct 2000). So if you are using a different Fortran compiler, you will need to build the DODS netCDF client library yourself.

As with the non-DODS netCDF package, you should "[s]et the environment variables CPPFLAGS, CC, CFLAGS, FC, FFLAGS, CXX, and CXXFLAGS (and perhaps LIBS) to represent [your] environment." The documentation (i.e., the INSTALL file) for the non-DODS netCDF package gives environment setups successfully used for a variety of platform/compiler combinations.

Below are the settings we have used with the DODS netCDF client library. If you need to build it for a different compiler, take a look at the INSTALL file mentioned above. If you have success with other Fortran compilers, please let us know so we can list it here.

• GNU Fortran
  • CC=gcc
  • CXX=g++
  • FC=gfortran
  • FFLAGS=-g
  • CPPFLAGS=-Df2cFortran
  Also good when using f2c (or fort77 on Linux).
• NAG f90
  • CC=gcc
  • CXX=g++
  • FC=f90
  • FFLAGS=-g
  • CPPFLAGS=-DNAGf90Fortran

Now for linking your Fortran code to these libraries, see our FAQ " How do I link my Fortran program to the DODS netCDF library? "

1. As is standard practice for OS/X, I replaced etc/config.guess and config.sub with /usr/libexec/config.guess and /usr/libexec/config.sub. This allows configure to correctly identify the platform as powerpc-apple-darwin5.5. I believe that the latest versions of autoconf come with config.guess/.sub files that handle OS/X properly so this should be easy to fix.
2. The gcc version test in the dap and nc3 configure scripts fails for Apple's modified gcc, because "gcc -v" gives the following output: Reading specs from /usr/libexec/gcc/darwin/ppc/2.95.2/specs Apple Computer, Inc. version gcc-934.3, based on gcc version 2.95.2 19991024 (release) The regexp gets stuck on the "." in "Inc.", and GCC_VER ends up set to: Apple Computer, I. version gcc-934.3, based on gcc version 2.95.2 19991024 (release) My quick fix for this was to comment out the error message in the case statement and instead set GCC_VER = `gcc --version`, which gives the following output: 2.95.2 I am not knowledgeable enough with autoconf to say how the test should be modified to be portable though..
3. I commented out the definition of HAVE_APPKIT_APPKIT_H in include/w3c-libwww/wwwconf.h. I have no idea why or what this is used for. I will investigate further if you don't know either.
4. I commented out line 974 of util.cc: xdf_destroy(xdr); The compiler was giving a "wrong number of arguments" error". I couldn't figure it out so I just commented out the line. I expect this introduced a memory leak so I we will have to figure out a better solution."
5. Since I was working with the 3.2.1 release and not the current SVN sources, I commented out various references to libdap++-gui in the dap and nc3/ncdump makefiles.
6. I had to run ranlib on lib/libwww.a. There was a file called "__.SYMDEF SORTED" which looks like it was supposed to be the symbol table for libwww sitting in the lib/ directory, so perhaps the ranlib command line didn't work quite right the first time. At this point libdap++.a and libnc-dods.a both built successfully.
7. The linker reported unresolved symbols for add_connect(NCConnect), del_connect(NCConnect), and a few other members of the Connections template. According to some messages on the web, there are template instantiation bugs in Apple's gcc, and the best fix they had found was to include the instantation as a separate object file. So I added "../inst.o" to the link line for dncdump and lo and behold, it worked.

See our DODS Supported Platforms page.

Yes, we have ported several of the DODS clients to Windows and they are available as a beta release. Please take a look at our Windows Port page.

See the notes on SGI issues.

To build the Matlab server, your entire DODS build (actually, just dap, packages, and ml-dods) must be in the same architecture as the Matlab libraries (o32/mips2 or 64/mips4). We haven't yet succeeded at building all of DODS in either of these architectures. Here are our main problems:

• currently, gcc does not support o32 and
• we've run into some trouble linking 64 bit objects (problem with linker setup?)
• we haven't had time to work on this problem

To build the Matlab command line client, build in the same architecture as the rest of your DODS build. If that architecture does not match the architecture of the Matlab libraries (o32/mips2 or 64/mips4), the linking of loaddods.mex* will fail. Because loaddods.mex* is the only piece of the Matlab client that links to the Matlab libraries and it does not link to the DODS libraries, it can be built in the architecture of the Matlab libraries even though the rest of DODS is not. To build loaddods as either o32/mips2 or 64/mips4:

• Note: gcc does not support '-mabi=o32' but will build '-mabi=64'. However, SGIs cc supports both '-o32' and '-64'.
• edit Makefile
  • if using cc, add '-o32' or '-64' to CFLAGS;
  • if using gcc, add '-mabi=64' to CFLAGS;
  • remove '-gstab' from CFLAGS; and
  • change CC to 'cc' or leave as 'gcc';
  • make sure LDFLAGS points to the correct Matlab library (in case you have both architectures installed on your machine)
• remove (or rename) loaddods.o, variable.o, queue.o, extend.o, error.o, MLVars.o (new as of 3.1.4), and process_values.o (new as of 3.2.x);
• run '$MAKE loaddods'.

There are several ways to test a DODS server. One of the simplest ways is to use any web browser to look at a dataset. For a description of how to do this, see our description of how to access DODS data with a browser.

You can also test out a server by using the 'geturl' tool. It should be in your $DODS_ROOT/bin directory. To use 'geturl', give it the -d, -a, or -D option and the URL of your dataset. For instance,

• geturl -d http://test.opendap.org/dap/data/nc/fnoc1.nc

Yet another way to test and debug a server is to directly connect to the HTTP server. Thus bypassing *all* interpretation of the return data stream, both from the DAP and the libcurl (HTTP) library. Here's the procedure. Type the following, making the substitutions for the server/URL you want to debug:

• telnet <host with server> 80 (assuming the server is running on port 80, substitute the correct port otherwise).
• GET <URL fragment following the hostname> HTTP/1.1
• Host: <hostname>
• <blank line>

Following the blank line you will see the response from the server, including the response headers.

What's going on here? This technique uses telnet to communicate with the HTTP daemon. The '80' causes telnet to use port 80 (the port normally used for HTTP). The first line instructs the HTTP daemon that it should GET the named document (the path used for the second argument is relative to the server's DocumentRoot) and use HTTP/1.1. Following the GET line there are one or more HTTP/1.1 headers which supply additional information to the server. HTTP/1.1 only requires that the Host: header be present. There are other request headers you can use. Consult the HTTP/1.1 specification.

Here is an example. The matching URL is http://dodsdev.gso.uri.edu/dods-test/nph-dods/data/nc/fnoc1.nc.dds.

        [jimg@comet jimg]$ telnet dodsdev.gso.uri.edu 80
        Trying 198.116.10.229...
        Connected to dodsdev.gso.uri.edu.
        Escape character is '^]'.
        GET /dods-test/nph-dods/data/nc/fnoc1.nc.dds HTTP/1.1
        Host: dodsdev.gso.uri.edu

        HTTP/1.0 200 OK
        XDODS-Server: DAP/3.4.2
        Date: Thu, 08 Jul 2004 17:01:59 GMT
        Last-Modified: Mon, 15 Apr 2002 22:49:39 GMT
        Content-type: text/plain
        Content-Description: dods_dds

        Dataset {
            Int16 u[time_a = 16][lat = 17][lon = 21];
            Int16 v[time_a = 16][lat = 17][lon = 21];
            Float32 lat[lat = 17];
            Float32 lon[lon = 21];
            Float32 time[time = 16];
        } fnoc1.nc;
        Connection closed by foreign host.
        

A few things to think about if your server isn't working:

• Check the permissions on your CGI scripts. They must have execute permission.
• If you are using a FreeForm server, see the question Why can't I get my FF server to serve my data?

Append `.ver' to a DODS URL. Or you can use `version' as the dataset name to get the version of a server without knowing any of the data file names.

returns an XML document that describes the server's software components and their versions in addition to the DAP protocol versions supported by the server. Older servers return a plain text document with less information.

See our web page About Data Security page.

OPeNDAP server software resides on the same computer (in general) as the data being served. The OPeNDAP server will use some lower-level web server software (e.g., Apache Server or Tomcat) to make the actual connection to the Internet. Most web server software creates and maintains a log file of all the incoming (http, e.g.) requests, and some indication of the success and/or failure mode of the response. The log files are often in a standardized form but are individually configurable by the system administrator.

Most sites that are interested in the usage of their OPeNDAP server(s) have developed scripts they run, typically once per month, to derive "metrics" of the usage of their server. These "metrics" might include: number of hits, number of successful hits, number of repeat users, and volume of data delivered.

A few details for Linux or unix machines running an Apache web server. A typical place to look for the web server logs is /usr/local/apache/logs but the actual location depends on how and where the server was installed. Check with your system administrator for the specifics on your machine.

You can find more information on Apache's server software at http://www.apache.org, including more information on log files.

There are also freeware log analysis packages available that could be useful. For instance, you can check out Analog logfile analysis at: http://www.analog.cx/

You are under no obligation to report your OPeNDAP server usage statistics to the OPeNDAP project. However, if you are willing to share this information, it will help us direct future software development efforts more effectively.

For the OPeNDAP C++ servers, you can enable the sharing of this information when you install your servers with the installServers script. When the install script asks about gathering access statistics, answer yes ("y") and provide the additional information requested. Your servers usage statistics will only be accessible by the local host (your machine) and the official OPeNDAP machine.

Your server has one or both of the following (easy to fix) problems. The cache directory is too small and/or your server cannot find gzip. If the cache directory is too small then files will be purged from the cache too soon resulting in a huge performance degradation. If your server cannot find gzip, it won't be able to decompress files before serving them.

When the OPeNDAP software is used to serve compressed files (e.g. files compressed using gzip), the files are first decompressed and then stored in a cache; data served are read from those cached files. The location of the cache directory is /usr/tmp by default. This can be changed by editing nph-dods and changing the value of $cache_dir. The software is set by default to limit the size of this directory to 50 MB. However, if you're serving large files, or are experiencing a large volume of traffic, you should increase this. To do so, edit the value of of the second parameter to 'purge_cache()' on line 125 of nph-dods. The cache size is given in MB, so changing the 50 to 100 would increase the cache size from 50MB to 100MB. Finally, the decompression software uses the gzip program to do its work. If your computer does not have the gzip program in its /bin directory you'll need to edit the DODS_Cache.pm so that the correct version of gzip is used. Look in that file for "/bin/gzip" and replace that text with the correct pathname. To figure out where gzip is on you computer, type 'which gzip' in a shell.

Here are a few suggestions for troubleshooting your FF server:

1) First, test that your format files are defined properly and that it fits your data files by running chkform on them. You can also check that your data is being interpreted as you desire by running newform. Both chkform and newform are FreeForm tools that come with the DODS FreeForm Server distributions. (They should be located in the bin/ directory of your distribution.)

So that newform can display your data, you will need an 'ASCII_output_data' section in your format description file. Like this:

ASCII_input_data "test"
Time 1 10 double 4
Test 12 33 enote 20

ASCII_output_data "test"
Time 1 10 double 4
Test 12 33 enote 16

2) If you are serving ASCII data, pay attention to the whitespace in your data files.

• FreeForm will gag if whitespace extends beyond the line length determined by the format description. For instance, if the format descriptor fits
  • '34.523 1.45'
  FF will give an error on
  • '34.523 1.45 '
• There needs to be whitespace filler if the data in a line doesn't cover the entire format. For instance, if the format descriptor fits this data
  • '34.456 234.456'
  FF will die on this data
  • '34.456 234.45'
  but will not die on
  • '34.456 234.45 '
• The enote type doesn't seem to work quite like that. For instance, if the format fits
  • '34.456 2.34e-2'
  FF will die on
  • '34.456 2.3e-2 '

As of September 2003

The Matlab OPeNDAP Server was written when Matlab 4 was current. The server supports all of the data types Matlab supported at the time. The server was never updated to handle the newer data types (structures and cell arrays, e.g.) because there was no demand for that capability. So, when the current server encounters variables of the newer types in a file, it chokes.

The level of interest in adding these capabilities is currently unclear. If anyone is actively interested in these capabilities, please let us know at support@unidata.ucar.edu. The best way to move forward with this activity would be to find a champion for the Matlab server who can drive the development effort. We can provide them with as much help as they need, although experience with C++ would be required. If no one comes forward we can add it to our schedule but we're booked pretty tight for the next six months.

If you know of someone who might be interested in working to expand the capabilities of the Matlab server, please have them contact us at support@unidata.ucar.edu.

When I start my Aggregation Server, I get the following:

DEBUG: AggServer: CatalogServlet copy 
/usr/local/jakarta-tomcat/webapps/thredds/initialContent/dodsC/ to 
/usr/local/jakarta-tomcat-4.1.27-LE-jdk14/content/thredds/dodsC/ (04-04-19
10:57:08 )
DEBUG: AggServer: catalog config 
</usr/local/jakarta-tomcat-4.1.27-LE-jdk14/content/thredds/dodsC/catalogConfig.xml>
is not valid (04-04-19 10:57:09 )

From: Tony Jolibois <tjolibois at cls.fr>

The error didn't come from the catalog itself, but from the network configuration of my computer. In the configuration catalog of the AS server, there are some http URLs:

<!DOCTYPE catalog SYSTEM "http://www.unidata.ucar.edu/projects/THREDDS/xml/AggServerCatalog.dtd"> 
<catalog name="MERCATOR DODS Aggregation Server Catalog" version="0.6" 
      xmlns="http://www.unidata.ucar.edu/thredds" 
      xmlns:xlink="http://www.w3.org/1999/xlink"> 

My environment was this: I have a firewall, and my computer was not open to Internet, so it could not connect to the two sites http://www.unidata.ucar.edu and http://www.w3.org. I tested the local copy of AggServerCatalog.dtd and InvCatalog.0.6.dtd but it didn't work.

After opening the connection to these two URLs at the firewall, all works fine now.

Conclusion: if your computer cannot connect to these sites, you won't be able to run an Aggregating server.

Thanks Tony for tracking this down and providing this FAQ!

The ASCII and HTML responses are generated by accessing the server using the URL (a future version of the server may use a different design; this is true for version 3.4 and may be true for some later versions). If you are serving data behind a firewall which uses NAT for address traslation, the DNS lookup for the host name can fail.

Greg Miller from the USGS tracked down this problem and came up with a solution:

I am behind a firewall that uses NAT translation, so if it was relying on DNS to find the address, it would fail. I checked my host file and discovered that Red Hat maps the server name into the loopback address and not the IP address of the ethernet interface. I corrected the host file, and everything works fine.

Thanks Greg!

Make sure your DODS_ROOT environment variable is set properly. It should points towards the DODS top level directory. For instance, if you expanded the DODS binary release tar file in /usr/local, set DODS_ROOT to "/usr/local/DODS".

If you are running the GUI from within the $DODS_ROOT/bin/matlab-gui directory, make sure PATH includes the current working directory (i.e., '.').

If you get a message in Matlab that the function/file 'inputdlg' cannot be found, go to $DODS_ROOT/bin/matlab-gui/ and copy inputdlg.tpl to inputdlg.m.

• The OPeNDAP C++ implementation contains a DAP API/library and CGI dispatch framework.
• The OPeNDAP Java implementation contains a DAP API and servlet framework
• The GrADS DODS Server (GDS) includes a Java servlet framework for developing OPeNDAP servers.

• The OPeNDAP C++ implementations DAP API/library can be used to develop OPeNDAP clients.
• The OPeNDAP Java implementations DAP API can be used to develop OPeNDAP clients.
• The OPeNDAP C++ implementations netCDF client library is an OPeNDAP enabled version of the netCDF interface.
• The Unidata netCDF Java library is OPeNDAP enabled "out of the box" and includes OPeNDAP specific extensions for dealing with OPeNDAP data types that don't fit in the netCDF data model

OR
The URLs for all the datasets I serve stopped working when I upgraded my server software to 3.2. What is going on and how do I fix the broken URLs?
What is the problem?

As of DODS (C++) version 3.2, the DODS servers are accessed through "nph-dods" instead of "nph-nc", "nph-hdf", etc. (For more details on why this change was made, see below.) This means that, once a pre-3.2 server is upgraded to 3.2, all the old DODS URLs no longer work. That is, unless there is a fix put in place.

Some Possible Fixes

1. copy nph-dods to old locations, e.g., 'cp nph-dods nph-nc'
2. symbolic links, e.g., 'ln -s ./nph-dods nph-nc'
3. if using apache server, add some ScriptAlias directives to the configuation of web server. E.g., currently, you probably have a line in your configuration file like: 'ScriptAlias /cgi-bin/ /usr/local/apache/cgi-bin/'. Add another line something like 'ScriptAlias /cgi-bin/dods/nph-nc /usr/local/apache/cgi-bin/dods/nph-dods'

Support in the install scripts (i.e., 'installServers')

The 'installServers' script will make copies of nph-dods in the old locations if the installer desires. It isn't pretty but it will do for a temporary solution.

Once version 3.3 comes out, the install scripts will stop supporting this behavior. Copying nph-dods (or any of the solutions mentioned above) will still work; it is only the install scripts that will stop supporting these patches.

Recommendation

We recommend that all server sites that are upgrading from pre-3.2 servers use one of the above mentioned patches (while planning on dropping support for the old form of URLs at some point in the future). NOTE this doesn't apply to new servers just starting with DODS 3.2

When DODS 3.3 comes out, its server installation scripts will no longer support these patches. So, we recommend that server sites use 3.3 as the deadline for support patch start publishing the new URLs immediately; notify your users that the old form of URLs will be dropped at some point in the future; We therefore re retiring the old until DODS 3.3 is available; begin alerting your users that the old URLs will not be available in the future; and remove patch once you upgrade to DODS 3.3

More on change to nph-dods

One of the new features in DODS (C++) version 3.2 was to reorganize all the different servers to have a single point of access. Pre-3.2 servers had a seperate CGI script (e.g., "nph-nc", "nph-ff", "nph-hdf") for each type of DODS server. If a single site served different types of data, users had to know which datasets corresponded with which server. A mismatch between server type and data type resulted in an error.

Version 3.2 servers present a single entry point, the CGI script "nph-dods" automatically (with the help of a dods.ini file) routes requests to the appropriate server software.

What is the problem?

Using geturl, a 3.2 client can read compressed responses from both 3.2 and 3.4.

Using geturl, a 3.4 client can read compressed responses from 3.4 but not 3.2.

Uncompressed responses work without any problems.

Recommendation

The problem is that 3.2 servers return garbled compressed responses. The 3.2 clients, due to a separate problem, don't ever ask a server for a compressed response, so the problem with the responses didn't show up.

When a 3.2 server sends a compressed response, the compressed body winds up preceding the response headers. This results in a response that is too garbled for libcurl to understand.

The fix for the 3.2 servers (introduced in 3.4.0) is to call flush() after the headers, but before the body data, are written.

Why the problem exists: I think this problem shows up because compression is handled by having the body data filtered through a sub-process. The headers are written to a FILE* and then the output of the sub-process is tied to that same FILE*. However, it may be that by using dup2() what is actually happening is that two FILE* are accessing oe underlying file descriptor. By using a flush() call we can synchronize the two writes; without it the xdr calls seem to write data that 'wins the race' (maybe because they are calling flush()?).

What to do about reading from the 3.2 servers?

1) Compression is off by default; warn users about the problem. Tell them how to ask a server its version.

2) Encourage people to upgrade their servers. Explain that a bug will prevent optimal use.