Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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 yousuggest.
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 tostick with Java, figuring that Unidata would eventually support theJava/netCDF-4 implementation. I was trying to avoid the file writer re-codingeffort from C to Java. Perhaps in the interim, before the Java API isavailable, I'll add a JNI layer to my application in order to use the C-langaugenetCDF 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, goodjustification for the HDF5 implementation with compression enabled! Themetadata 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 speedreally 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.
netcdf-java archives: