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

Re: Serving local netCDF files though DODS



Tennessee James Leeuwenburg wrote:

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"
xmlns="http://www.unidata.ucar.edu/thredds";
xmlns:xlink="http://www.w3.org/1999/xlink";>
<dataset
name="Testing DODS Aggregation Server Catalog Top-level dataset"
dataType="Grid" serviceName="this"
>
<service name="this" serviceType="DODS" base=""/>
<service name="local" serviceType="NetCDF"
base="file:///data/"/>


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


yes, this all seems right.

the complication arises because you need to specify both an external (how your user accesses it) and an internal (how you ie the AS accesses it) URL for a file. We are going to try to make it easier in the next version.


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.

probably right, sorry for the lousy documentation !! Maybe I should put it on a WIki and let people fix it for me? ;^)



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"/>
</dataset>

http://tennesssee.id.au/serface.nc URL invalid


without success.

Cheers,
-Tennessee

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

i dont think i saw this message from Mr. Godin (??!!) or maybe i lost it.

Michael : go to http://server:8080/thredds/dodsC/debug and try the "show Access URLS" page. thats a good debugging tool for these problems.
the internal URL it shows you should be valid; sometimes the number of slashes after the "file:" is a problem.





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.