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

Re: difference in new XML standard

On Friday 27 January 2006 21:40, John Caron wrote:
> Ethan Davis wrote:
> > Hi Bjørge,
> >
> > Bjørge Solli wrote:
> >> Hi, I'm hoping John or someone else can answer this.
> >>
> >> I'm trying to get my old urls to look as much alike as possible as
> >> before when using aggregation in the catalog file, and migrating from
> >> the 0.6 xml-standard to 1.0.1. (thredds 2.0b to 3.6)
> >>
> >> My old service-tag looked like this:
> >> <service name="TOPAZ" serviceType="OpenDAP"
> >> base="http://nerscweb.bccs.uib.no/nersc/nph-dods/mersea-ip/arctic/mersea
> >>-class1/" />
> >> which made the url look like this:
> >> http://topaz.nersc.no/thredds/dodsC/mersea-ip-topaz-class1-arctic-b20051
> >>102.html
> Since url = service.base + dataset.urlPath, I would have expected that the
> url would have to start with
> http://nerscweb.bccs.uib.no/nersc/nph-dods/mersea-ip/arctic/mersea-class1/
> so i guess the service you are showing is the internal server base.

Nope, the nerscweb.uib.no-server is an internal only server where all the 
netcdf-files are stored (actually it's at the nearby parallell computer lab, 
since we don't have the disk space to store all our data). The topaz.nersc.no 
is our public server, when thredds gets asked for some data, it really only 
work as an aggregator of the data on the other (nerscweb) server. This is why 
I cannot use the new nice scan features in thredds, since afaik these can 
only work on local filesystems.

Or did I misunderstand you now?

> >> My new xml-file I today noticed makes a url like this(not online yet):
> >> http://topaz.nersc.no/thredds/dodsC/topaz/mersea-ip-topaz-class1-arctic-
> >>b20051102.html
> >>
> >> (notice the 'topaz')
> >>
> >> The service tag that makes such links look like this:
> >>  <service name="TOPAZ" serviceType="OpenDAP" base="/thredds/dodsC/">
> >>   <datasetRoot path="topaz"
> >> location="http://nerscweb.bccs.uib.no/nersc/nph-dods/mersea-ip/arctic/me
> >>rsea-class1/" />
> >>  </service>
> In the TDS case, the url has to start with /thredds/dodsC/, so that the
> right servlet gets called. Then the datasetRoot.path gets stuck in there,
> so that we can find the datasetRoot and map to its location. So the url has
> to start with
>  /thredds/dodsC/topaz/
> then comes the rest of the filename, presumably
>  mersea-ip-topaz-class1-arctic-b20051102
> if you want to match
> http://topaz.nersc.no/thredds/dodsC/mersea-ip-topaz-class1-arctic-b20051102
> the problem is that theres no dataset root path, so no way to map to the
> root.
> So I guess the answer is no, theres no way to reproduce that url, sorry.

Not a big problem, I actually think this is a good idea, but the old system 
had it like this so I just wondered. We only have two (known) servers that 
use our data that have to be reconfigured for the new urls.

> >> I've tried setting the path to "", "/" and ".", but none of them work.
> >>
> >> Should I consider this a lost case, or is there some way to get the
> >> old url back?
> >
> > If your three tries ("", "/", ".") don't work, I suspect the TDS does
> > not support the type of URL you are trying to recreate. The path
> > basically is an ID for mapping a URL to a datasetRoot or datasetScan.
> > The idea of an empty path (kind of a default datasetRoot) didn't come
> > up. I don't think there is a reason it couldn't be implemented. However,
> > I do know there are lots of places in the code that make sure the path
> > doesn't start with a slash ("/") and others that assume it is a
> > non-empty string.
> >
> > Unfortunately, I don't know of a mod_rewrite equivalent in the servlet
> > world.
> >
> > Ethan

Thankyou for the answers I needed.

Bjørge Solli - Office:+47 55205847 cellph.:+47 91614343
Nansen Environmental and Remote Sensing Center - Bergen, Norway
http://www.nersc.no Reception: +47 55205800
Dept.: Mohn-Sverdrup Center for Global Ocean Studies 
       and Operational Oceanography

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.