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.