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

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.