NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Nathan, 3) That is right. There's more detail on datasetScan and such at http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/v1.0.2/InvCatalogSpec.server.html Ethan Nathan Potter wrote: > > I have a third question: > > > > 3 --------------- > When looking at a thredds:datasetScan can one determine the catalog > access URL based on this: > > thredds:service/@base + thredds:datasetScan/@path + "/catalog.xml" > > > Example: On localhost:8080 we find this catalog: > > > <service name="tds" serviceType="OPeNDAP" base="/ncDODS/"/> > > <datasetScan location="/head/data" path="data" name="Test Data > Archive" serviceName="tds"> > <crawlableDatasetImpl > className="opendap.bes.BESCrawlableDataset" /> > <filter> > <exclude wildcard=".*" atomic="true" collection="true"/> > <include wildcard="*"/> > </filter> > <addDatasetSize /> > </datasetScan> > > So the catalog access URL would be: > > http://localhost:8080/ncDODS/data/catalog.xml > > ??? > > N > > > > > > > On Dec 30, 2008, at 10:42 AM, Nathan Potter wrote: > >> John, >> >> Point me at the crawler code, I'll look and see how it works with >> thredds:catalogRef elements. >> >> I guess I really have two questions: >> >> >> 1 ------------------ >> >> I am looking at the xlink:href attribute of the thredds:catalogRef >> elements. >> >> >> Would it be far to say that this example: >> >> <catalogRef xlink:href="CEOP/catalog.xml" xlink:title="CEOP" >> name="CEOP/"/> >> >> References a file relative to the parent catalogs position in the >> catalog structure? >> >> >> Example 1: >> So if the catalog containing this thredds:catalogRef was accessed >> using this URL: >> >> http://localhost:8080/thredds/data/catalog.xml >> >> Then the above catalogRef should lead you here: >> >> http://localhost:8080/thredds/data/CEOP/catalog.xml >> >> >> Example 2: >> And on the same server, this example: >> >> <catalogRef xlink:href="/toplevel/path/catalog.xml" >> xlink:title="catalog" name="catalog"/> >> >> Would lead here: >> >> http://localhost:8080/toplevel/path/catalog.xml >> >> No matter which catalog this thredds:cataogRef appeared. >> >> >> Example 3: >> And this example: >> >> <catalogRef >> xlink:href="http://motherlode.ucar.edu:8080/thredds/idd/satellite.xml >> " xlink:title="Motherlode" name="Motherlode"/> >> >> Would lead here: >> >> http://motherlode.ucar.edu:8080/thredds/idd/satellite.xml >> >> No matter which catalog this thredds:cataogRef appeared. >> >> Is that the way you see it working? >> >> >> >> >> >> 2 ------------------ >> >> Is there a place that describes how data access URL's are too be >> built from thredds:dataset elements ? >> >> My understanding is that it's like this: >> >> thredds:service/@base + thredds:dataset/@urlPath >> >> Is that a correct interpretation of the catalog semantics? So if >> we're on localhost:8080, and the service/@base is "/opendap/" then >> this catalog snippet: >> >> <service name="hyrax" serviceType="OPeNDAP" base="/opendap/"/> >> <dataset name="Datset with a compound service and multiply inherited >> services." ID="bears" urlPath="bears.nc"> >> <serviceName>hyrax</serviceName> >> </dataset> >> >> Would produce this base data access URL: >> http://localhost:8080/opendap/bears.nc >> and additional service related stuff would get added to that. >> >> Is that right? >> >> >> Thanks, >> >> Nathan >> >> >> >> >> On Dec 30, 2008, at 9:16 AM, John Caron wrote: >> >>> Hi Nathan: >>> >>> We dont have ready-made code that validates catalogs and follows >>> the catalog refs. However, we do have some generic catalog crawler >>> code, where you get callbacks to your own code to do whatever you >>> want. let me know if thats helpful... >>> >>> Nathan Potter wrote: >>>> Greetings, >>>> I have a question about validating the semantics of a THREDDS >>>> catalog. The attached catalog contains a number of >>>> thredds:catalogRef elements. The urlPath attribute for these >>>> should be able to be used to resolve the individual catalogs. Is >>>> there a validation for that similar to using the built in Catalog >>>> Validation service that come rolled in the TDS? >>>> I tested the attached catalog against the service at >>>> motherload.ucar.edu: >>>> http://motherlode.ucar.edu:8080/thredds/catalogServices?cmd=validate&catalog=http://ndp.opendap.org:8080/opendap/data/catalog.xml >>>> >>>> And it passed, but I don't imagine it attempted to check down the >>>> catalog hierarchy. >>>> Any ideas? >>>> Thanks, >>>> Nathan >>>> ------------------------------------------------------------------------ >>>> = = = >>>> Nathan Potter ndp at opendap.org >>>> OPeNDAP, Inc. 541.752.1852 >>>> ------------------------------------------------------------------------ >>>> _______________________________________________ >>>> thredds mailing list >>>> thredds@xxxxxxxxxxxxxxxx >>>> For list information or to unsubscribe, visit: >>>> http://www.unidata.ucar.edu/mailing_lists/ >> = = = >> Nathan Potter ndp at opendap.org >> OPeNDAP, Inc. 541.752.1852 >> >> > > = = = > Nathan Potter ndp at opendap.org > OPeNDAP, Inc. 541.752.1852 > > > _______________________________________________ > thredds mailing list > thredds@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ -- Ethan R. Davis Telephone: (303) 497-8155 Software Engineer Fax: (303) 497-8690 UCAR Unidata Program Center E-mail: edavis@xxxxxxxx P.O. Box 3000 Boulder, CO 80307-3000 http://www.unidata.ucar.edu/ ---------------------------------------------------------------------------
thredds archives: