This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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 yousuggest. > 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.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. Thanks, Greg.