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.
> 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.
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.
Thanks,
Greg.