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.
[Sorry to have this problem reported in multiple emails] Another reason why the CatalogBuilder should work as before: URLs like https://oceanwatch.pfeg.noaa.gov/thredds/catalog/Satellite/aggregsatBA/ssta/catalog.xml used to work, but now they fail because the dataset is actually in a remote thredds. Thus, someone can generate a starting url by crawling a thredds catalog by hand, but that url is invalid in catalogBuilder because it is (unbeknownst to the user) actually a dataset in a remote THREDDS. And CatalogBuilder just returns null, it doesn't say "I'm sorry Dave, I can't do that because the dataset is actually a remote dataset at ..." or anything useful. Please return the original capability of CatalogBuilder to properly deal with datasets in remote THREDDS. Thank you. On Thu, Jul 7, 2022 at 9:49 AM Bob Simons - NOAA Federal < bob.simons@xxxxxxxx> wrote: > I see now that simply removing the first part of the URL > https://oceanwatch.pfeg.noaa.gov/thredds/remoteCatalogService?catalog= > isn't a great solution. > Previously, the datasets in the remote catalogs appeared to be in the > local thredds > e.g., https://oceanwatch.pfeg.noaa.gov/thredds/dodsC/satellite/MPOC/1day > but removing the first part of the URL causes the datasets to have URLs in > the remote thredds > e.g., https://thredds1.pfeg.noaa.gov/thredds/dodsC/satellite/MPOC/1day > > That isn't good because the remote thredds may be a semi-private thredds > that the administrator would prefer not to have addressed directly (e.g., > because the url may change periodically, e.g., for load balancing). > > So it would be nice if netcdf-java worked as it used to, where catalogs > that point to remote catalogs still return datasets that appear to be in > the local THREDDS. > > Thank you for investigating. > > > > > https://thredds1.pfeg.noaa.gov/thredds/dodsC/satellite/MPOC/1day[end] > > On Thu, Jul 7, 2022 at 9:27 AM Bob Simons - NOAA Federal < > bob.simons@xxxxxxxx> wrote: > >> With both netcdf-java v5.5.2 and v5.5.3, the CatalogBuilder no longer >> seems to work with a remoteCatalogService catalog. This code worked before. >> >> Specifically, trying to get a catalog from a remoteCatalogService catalog >> returns a catalog that is null: >> thredds.client.catalog.Catalog catalog = (new >> thredds.client.catalog.builder.CatalogBuilder()).buildFromURI(new >> java.net.URI( >> " >> https://oceanwatch.pfeg.noaa.gov/thredds/remoteCatalogService?catalog=https://thredds1.pfeg.noaa.gov/thredds/catalog/Satellite/MPOC/catalog.xml";)); >> >> System.out.println(catalog == null); >> >> That prints "true". >> >> A null is not a useful response. If the URL is invalid for this method, >> then there should be an exception saying so, or more specifically solving >> the problem. >> >> I will solve the problem in my code by using the remote URL directly. >> Since this code used to work, it seems like the best solution is for you to >> have the CatalogBuilder switch to using the remote catalog's url. >> >> Can you please investigate and (if true) fix these problems? >> >> Thank you. >> >
netcdf-java archives: