Re: [thredds] inconsistent catalog hierarchy with catalogRef

Hi Doug,

I'm not surprised you are seeing that behavior with getProxyDataset().
Since a catalogRef is a substitute for a dataset (in both the XML and
the thredds.catalog classes), the reference must in some sense resolve
to a dataset. Unfortunately, a catalog is not a substitute for a dataset
nor is the mapping to a dataset always straight foward (e.g., a catalog
is not required to have a 'name' attribute, nor is it required to
contain a single, top-level dataset). So, I think what you are seeing is
the workaround we came up with to deal with this not always clear situation.

Given all that, it doesn't necessarily fall out that getDatasets() would
display the same behavior as getProxyDataset(). Though I also don't
think it is completely clear that it shouldn't.

Does that clarify why catalogRefs behave the way they do?  And, if so,
can you make this model work for what you're trying to do?


On 10/5/2011 9:31 AM, Doug Lindholm wrote:
> I am trying work with a catalog as a DAG of datasets. When I get the
> children of a catalogRef node, I get different behavior depending on how
> many datasets are in the referenced catalog. If there is only one
> dataset, then it is returned as the sole member of the List. If the
> catalog has more than one dataset, I get the catalog itself alone as a
> dataset in the List. Using getProxyDataset() has the same problem.
> Is this a "feature"? Between this, and my inability to use "name" or
> "alias" (earlier email), the API is making it hard to do what I want
> with the catalogs.
> Thanks,
> Doug
> P.S. I'm using a recent 4.2 release of NetCDF-Java.

  • 2011 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the thredds archives: