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

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_
============================================