Re: IOSP error

Needham, Sheila wrote:
> John,
>
> Sample Nimrod file attached.  Each file contains a series of header/data
> blocks; the headers are always 512 bytes, the data length varies; each
> block is preceded and terminated by a 4 byte integer length.
>
> I'm a bit confused about where the IOSP is loaded depending on how I
> access data.  When I run my client application on a remote file using
> HTTP like this:
>  
> NetcdfFile.open("http://localhost:8080/thredds/fileServer/main_global/ni
> mrod.data"); 
> I assume I'm loading the IOSP locally.  That gives the doradeiosp error
> and then goes on to work.

yes, local IOSP. are you loading using the NetcdfFile.registerIOProvider() or 
RuntimeConfigParser ?

it does look like im failing to put those first, which i will fix tommorrow. I 
will also make sure doradeIosp doesnt mistakenly claim this file.

> When I access via the thredds catalog like this:
>  
> NetcdfDataset.openDataset("thredds:http://localhost:8080/thredds/catalog
> /main_global/catalog.xml#main_global/nimrod.data")
> ...am I using the IOSP loaded by the TDS?
>
> Similarly if I try Opendap like this:
> ncfile =
> NetcdfDataset.openDataset("http://localhost:8080/thredds/dodsC/main_glob
> al/nimrod.data");
> ... Will I be using the client or server IOSP?

opendap uses the server IOSP stack.

the thredds factory (useing 
"thredds:http://localhost:8080/thredds/catalog/etc";) will use opendap if that 
works (server IOSP), and if it fails it may try using the HTTP server (loac IOSP).

no wonder your confused!

> Sorry if I'm a bit slow on the uptake!
>
> Thanks for your help,
> Sheila
>
>
> -----Original Message-----
> From: John Caron [mailto:address@hidden] 
> Sent: 27 February 2008 15:43
> To: Needham, Sheila
> Cc: Unidata netCDF Java Support
> Subject: Re: IOSP error
>
>
>
> Needham, Sheila wrote:
> > Hi John,
> >
> > I've finally got as far as testing my IOSP in THREDDS and I'm getting 
> > this error:
> >
> > ucar.atd.dorade.DoradeSweep$DoradeSweepException: java.io.IOException
> >         at
> ucar.atd.dorade.DoradeSweep.isDoradeSweep(DoradeSweep.java:510)
> >         at
> > ucar.nc2.iosp.dorade.Doradeheader.isValidFile(Doradeheader.java:48)
> >         at
> ucar.nc2.iosp.dorade.Doradeiosp.isValidFile(Doradeiosp.java:59)
> >         at ucar.nc2.NetcdfFile.open(NetcdfFile.java:441)
> >         at ucar.nc2.NetcdfFile.open(NetcdfFile.java:261)
> >         at ucar.nc2.NetcdfFile.open(NetcdfFile.java:231)
> >         at ucar.nc2.NetcdfFile.open(NetcdfFile.java:219)
> >         at ucar.nc2.NetcdfFile.open(NetcdfFile.java:207)
> >         at test.TestNetcdf.main(TestNetcdf.java:30)
> > Caused by: java.io.IOException
> >         at ucar.atd.dorade.DoradeSweep.findName(DoradeSweep.java:528)
> >         at
> ucar.atd.dorade.DoradeSweep.isDoradeSweep(DoradeSweep.java:507)
> >         ... 8 more
> >
> > It carries on to find my IOSP and completes successfully.  Can I 
> > change the order in which IOSPs are tested or disable the ones I know 
> > we're not going to use?
>
> Hi Sheila:
>
> I think the easiest thing is for us to fix the dorade iosp, which is
> mistakenly claiming your file. Can you send me a sample file?
>
> Also, if you are loading your IOSP at runtime, it should be coming
> first, before the statndara IOSPs. If not, I will fix that also.
>
> > ---
> > On a separate note, have you any thoughts on how to convert data to 
> > different output formats from the TDS?  For example, we might store 
> > data as NetCDF but want to retrieve it as GRIB1.  I was thinking along
>
> > the lines of an input service provider sitting between the stored data
>
> > and the CDM (as we've got now), and an output service provider between
>
> > the CDM and the client - but I'm not sure how this would fit with the
> TDS.
>
> The problem is that GRIB output is only suitable for gridded data. So
> writing a generic CDM -> GRIB output service is not possible. However,
> if you write a gridded data -> GRIB service, we could define a "GRIB
> output service" which one could configure into the TDS for specific
> datasets. 
>
> > We want to move away from the current situation where we have dozens 
> > of data formats and specific converters for each pair!
>
> Yes, thats the hope!
>
> > Thanks,
> > Sheila
> >
> >
> > ============================================
> > Sheila Needham  Senior Software Developer
> > Infrastructure Development Team   Technology
> > *Met Office*  Fitzroy Road Exeter EX1 3PB United Kingdom
> > Tel: +44 (0)1626 363489
> > E-mail: address@hidden _http://www.metoffice.gov.uk_ 
> > ============================================