Re: Java netCDF-4 API

• To: Greg Rappa <gregr@xxxxxxxxxx>
• Subject: Re: Java netCDF-4 API
• From: John Caron <caron@xxxxxxxxxxxxxxxx>
• Date: Fri, 01 Jun 2007 10:53:00 -0600

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.

• References:
  • Re: Java netCDF-4 API
    • From: John Caron