Some quick comments about:
byte VIL(z_coordinate=1, y_coordinate=3520, x_coordinate=5120);
:_FillValue = -1b; // byte
:valid_min = 0b; // byte
:valid_max = -2b; // byte
:long_name = "Vertically Integrated Liquid";
:title = "Vertically Integrated liquid (VIL) product is a measure of liquid
water content based on data of a number of elevation scans";
:units = "kg m-2";
:scale_factor = 1.0f; // float
:add_offset = -0.0f; // float
:positive = "up";
:grid_mapping_name = "azimuthal_equidistant";
:latitude_of_projection_origin = "38.000000";
:longitude_of_projection_origin = "-98.000000";
:false_easting = "0.000000";
:false_northing = "0.000000";
these dont make sense:
:valid_min = 0b; // byte
:valid_max = -2b; // byte
and will confuse software (like nj22) trying to correctly interpret them
these will cause nj22 to convert to floats, which is costly with no benefits:
:scale_factor = 1.0f; // float
:add_offset = -0.0f; // float
these could easily be made into CF compliant, allowing geolocation by nj22:
:grid_mapping_name = "azimuthal_equidistant";
:latitude_of_projection_origin = "38.000000";
:longitude_of_projection_origin = "-98.000000";
:false_easting = "0.000000";
:false_northing = "0.000000";
im not sure if you have control over this format, so i wont go further unless
its useful....
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.
> 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.
