Keiser, Ken wrote:
John,
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?
thanks!
