Re: Java netCDF-4 API

Hi Greg:

Greg Rappa wrote:
John,

Thanks for the quick response.

 > Are these adapters following the nj22 "IO Service Provider" interface?

When I first delved into the netCDF generation task, I opted to instantiate a NetcdfFileWriteable object and simply add attributes, variables and dimensions. Perhaps I'll go back now and look into using the IO Service Provider, as you
suggest.

The IOSP layer would be for reading your files. If you write one, you can access the files through nj22 without having to rewrite them into nectdf. Rewriting to netcdf-3 (and eventually netcdf-4) is then very easy. Of course, there are tradeoffs for this approach vs. rewriting.


 > We will eventually support writing netcdf-4 files, but the time frame
 > is unclear. Im hoping to have something in 3 months, but cant guarantee
 > it. In the meanwhile, have you experimented with writing netcdf-4 with
 > the C library? What kind of file sizes do you see over netccdf-3? File
 > reading/writing slower or faster? Can you send me any sample netcdf-4
 > files?

At first, I considered writing netCDF files with the C library, but decided to
stick with Java, figuring that Unidata would eventually support the
Java/netCDF-4 implementation. I was trying to avoid the file writer re-coding
effort from C to Java.  Perhaps in the interim, before the Java API is
available, I'll add a JNI layer to my application in order to use the C-langauge
netCDF API.

Before committing to netcdf-4 format, I would advise that you write some to 
make sure you get what you expect. (by way of disclosure, we are interested in 
such benchmarks for real-world cases).



I've attached a gzipped netCDF-3 file of a CONUS-sized VIL product containing a 5120-by-3520 one-byte grid, roughly 18 MB. It compresses down to 680 KB, good
justification for the HDF5 implementation with compression enabled!  The
metadata is a work-in-progress but I have managed to at least declare the grid in our desired projection: Lambert Azimuthal Equal-Area. File writing speed
really isn't an issue, it's the transport of these data files that has me
concerned about the file sizes.

If its only transport, perhaps gzipping netcdf-3 is a feasible solution for 
now??

I will have a look at the file....



Thanks,
Greg.