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.
