Java netCDF-4 API

[John Caron]

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.
>