[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Serving local netCDF files though DODS

I am able to server local netCDF files from the current version of the Thredds server. I have been struggling to get remote files working, so my understanding may be flawed, but as far as I can tell, this is how things work.

Thredds uses a "service" to work out how to fetch your data. Each data set has a "service" which you specify by "name" which says how the data should be fetched. You can have a "NetCDF" serviceType for NetCDF data, or "DODS" for data fetched from a DODS server. The "base" for local netCDF files should point to a directory on your filesystem, including any trailing "/".

You need to :

* To specify the special service "this" as a DODS server (i.e. inform the DODS server about itself, for the purposes of aggregating local data sets later if need be)
* To specify a "service" for serving your local data, I called it "local" in this example
* Specify any number of other named services

Datasets may be aggregated or not as you please. The following example is a non-aggregated dataset. For non-aggregated datasets, you need to specify the "internalService" property to tell Thredds the name of the service you want to use for loading the data.

<!DOCTYPE catalog SYSTEM "http://www.unidata.ucar.edu/projects/THREDDS/xml/AggServerCatalog.dtd";>
<catalog name="Test DODS Aggregation Server Catalog" version="0.6"

name="Testing DODS Aggregation Server Catalog Top-level dataset"
dataType="Grid" serviceName="this"
<service name="this" serviceType="DODS" base=""/>
<service name="local" serviceType="NetCDF"

                <property name="internalService" value="local"/>
                <!-- -->
               <dataset name="Data Sets">
                  <service name="DISK" serviceType="NetCDF"
                 <property name="internalService" value="DISK"/>
                 <dataset name="Surface" urlPath="surface.nc"/>

I have also noticed that some of the XML tags have changed names from the examples - for example "serviceType" instead of "service". This doesn't appear to have been documented properly, but maybe I'm looking in the wrong places.

Also, if anyone has had success loading "NetCDF" resources remotely, please let me know! I'm trying to load

<dataset name="Home files foo">
<service name="HOME" serviceType="NetCDF" base="http://tennesssee.id.au/"/>
<property name="service" value="HOME"/>
<dataset name="Foo" urlPath="surface.nc"/>

without success.


Godin, Michael wrote:
I believe that Mike McCann is describing a bug in version 1.3 of the Thredds 
server.  I have xml that works fine in version 0.6, but which fails to serve 
NetCDF files in version 1.3, even though the catalog.xml file passes the 
validate test.  Using the automatic translation utility does not help either.
Mike Godin

Yuan wrote:

        McCann, Mike wrote:

                        -----Original Message-----
                        From: Yuan Ho [<mailto:address@hidden>]
                        Sent: Wednesday, October 27, 2004 9:29 AM
                        To: McCann, Mike
                        Cc: 'address@hidden'
                        Subject: Re: Serving local netCDF files though DODS

                        McCann, Mike wrote:


I am trying to serve local netCDF files through the agg
server and access

them through the DODS API. It is not working.

                        Have you installed a DODS server and link these netCDF 
files to this server? According
                        to this configure file the serviceType is DODS, you 
need a DODS server. AGG server is
                        based on DODS server, hope this will not confuse you.

                Hi Yuan,

                I am running this on a Win2k laptop and am not aware of another 
                netCDF server for this platform. I was lead to believe that the 
dodsC AS would perform the function of a DODS netCDF server.
                Is this not true? How can I serve netCDF files through DODS from
                my laptop?
                This is important for taking this technology on the road for
                presentations at workshops and conferences.
                Regarding confusion, I admit that I am confused by the examples
                presented at:
                Example 6 suggests that the AS can serve local netCDF files as
                DODS data sets.  (Replacing the "..." at the beginning of this 
                snippet with actual tags would be helpful.  Also, it'd be nice
                to be more explicit about the differences between examples 3 
and 6.)
        Ok, so what you need is a netCDF type service. I think your config is 
ok, but you confused
        the dataset name and urlpath, dataset name is only the one you want to 
see on browser, and the
        urlpath need to have the dataset real file name there.


                                Here is the contents of my 
dodsC/catalogConfig.xml file:


<catalog name="THREDDS - DODS Aggregation Server Catalog"
version="0.6" xmlns="<http://www.unidata.ucar.edu/thredds>; xmlns:xlink="<http://www.w3.org/1999/xlink>;>

<dataset name="AUVCTD mission netCDF files" serviceName="this">
<service name="this" serviceType="DODS" base=""/>
<service name="local" serviceType="NetCDF"

<dataset name="Non-Aggregated Netcdf Files"
dataType="Grid" serviceName="this">

<property name="internalService" value="local"/>
name="2004/2004029/2004.029.03/parosci.nc" urlPath="2004/2004029/2004.029.03/parosci.nc"/>


It validates and passes the debug test, yet when I click on
any of the DDS or DAS

links I get this in my browser:

kDODServlet ERROR:
dods.servlet.DODSServlet.getDataset(Ldods/servlet/ReqState; Ldods/servlet/GuardedDataset;

I don't see any helpful messages in the log files.

What am I doing wrong? Even some suggestions as to how I may do my own debugging
will be helpful.


Mike McCann Software Engineer
Monterey Bay Aquarium Research Institute
7700 Sandholdt Road
Moss Landing, CA 95039-9644
Voice: (831) 775-1769 Fax: (831) 775-1646

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.