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

RE: Proposed new specification for THREDDSS Catalogs


Those suggestions sound reasonable.  Probably the easiest thing would be for us 
to modify our ESML data browser app to somehow use the THREDDS client 
libraries.  One way to do this and bridge the C/C++ to Java gap might be for us 
to write service wrappers around the THREDDS functionality in order to utilize 
them from whatever language.  I haven't looked at the THREDDS client libraries 
but I wouldn't think that a simple example would be too difficult.  We'll 
discuss the possibility here, unless someone else has a better suggestion.


-----Original Message-----
From: John Caron [mailto:address@hidden
Sent: Thursday, April 01, 2004 1:21 PM
To: Keiser, Ken
Cc: address@hidden; Ramachandran, Rahul; Conover, Helen;
Graves, Sara
Subject: Re: Proposed new specification for THREDDSS Catalogs

Keiser, Ken wrote:

>Some nice new features in this spec, especially in the services area.  A 
>couple of observations based on our use.
>(1) There is still not a "swath" dataType - as opposed to "grid" or "image".  
>Maybe we're the only ones using swath so its not a community issue, but 
>thought I would mention it.
The dataType enumerations have been completely neglected, and 
practically undefined. I have never quite understood the difference 
between HDF-EOS "grid" vs "swath" : is the grid type regularly spaced, 
and the swath not? I am not even sure of the practical distinction 
bewteen "Image" and "Grid". So the first step is to start defining what 
these data types are. Any help from this group would be appreciated. My 
inclination would be not to try to do much in this 1.0 version, but to 
try to do something significant for the 1.1 version.

In the meanwhile, I will add Swath as an official DataType. You are also 
free to create new types using any string ( the catalog will validate, 
but give a warning).

>(2) Obviously we are always looking at ways to facilitate the use of ESML 
>definitions.  I looked through the spec trying to figure out where it might 
>fit best.  I guess one place might be as a serviceType for the service element 
>if there could then be an associated URL for the description file.  Another 
>thought was in the metadata element, or maybe a combination of the two - in 
>other words a serviceType of ESML which could then trigger an application to 
>look at an associated metadata element for the necessary links.  It might be 
>appropriate as a type in dataFormat where there is a list of known formats and 
>the use of ESML there could essentially make that list extensible to less 
>known formats that could be defined by an ESML description.
>Those are suggestions, but I'm sure you guys can better see where it would fit 
>best based on your conceptual view of the catalog if there is any interest.
Thats a really interesting question and all the above seem possible.

My first inclination would be that the dataset URL point to the esml 
file itself, and we add ESML as a known dataFormatType. Whats not clear 
is how to access the binary file remotely. Does ESML allow to specify 
remote acccess to the binary file? If not, this solution would only work 
for local files.

Another way would be that the dataset URL point to the binary file, and 
the ESML file is pointed to be a metadata element XLink (or be included 
directly in the catalog).  In this way the binary file could be of 
serviceType FTP or HTTP, or any other bulk transport, and so be remotely 
accessible. In that case, I guess the dataFormatType might still be 
ESML, so that the client knows to find the ESML file and use it to read 
the binary file. Also possible is that the presence of  an ESML metadata 
element alone tells the client to use the ESML file.

So sounds like adding ESML as a dataFormatType is useful in either case.

It would be great to try this out, and see what would work best. But we 
dont have an ESML-enabled client to test it. Possibilities include:

1. If you had a Java library for ESML we could add ESML reading to our 
java-based clients.

2. If we had a C library for THREDDS, you could THREDDS-enable one of 
your ESML clients.

The only other thing i can think of is to serve ESML files through DODS, 
which would hide all the ESML stuff behind the DODS API, so it wouldnt 
be much of a test of THREDDS/ESML.

Any thoughts?


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.