Java netCDF-4 API

[John Caron]

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.
>