NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
John,I have partly implemented NetCDF-Java support for rotated latitude/longitude GRIB2 files with the unusual NCEP GDS template 32769:
http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_temp3-32769.shtmlAlthough this is an unusual GDS, my investigations indicate that it is the same projection as GDS template 1 but defined by different GDS parameters. I am thus keen to reuse the existing implementation Grib2Gds.RotatedLatLon to reduce code duplication.
During implementation, I encountered some behaviour of GribIosp and Grib2Gds.RotatedLatLon that I do not understand:
(1) Grib2Gds.RotatedLatLon appears to make no transformation to the rotated coordinate system. The generated lat/lon will extend from la1/lo1 to la2/lo2 (the unrotated corners). What happened to the new rotated origin? I expected the rotated grid to centred on (0,0) if the southern pole parameters set the origin as the centre of the grid (not mandatory but a popular choice):
https://github.com/Unidata/thredds/blob/master/grib/src/main/java/ucar/nc2/grib/grib2/Grib2Gds.java#L535(2) The coordinate variables created in GribIosp for rotated longitude/latitude GRIB2 grids do not appear to conform to the CF Conventions as they lack rlat/rlon and standards_name grid_latitude/grid_longitude and do not contain multidimensional lat/lon as required. Instead they appear to contain a simple lat/lon as for an unrotated grid:
http://cfconventions.org/cf-conventions/cf-conventions.html#grid-mappings-and-projections(3) Rather than using GdsHorizCoordSys.isLatLon as for GRIB1, for GRIB2 files GribIosp uses GDS template range checks to decide if a grid is lat/lon. This seems to lack extensibility. What is the reason for this implementation choice, and can I change it?
https://github.com/Unidata/thredds/blob/master/grib/src/main/java/ucar/nc2/grib/collection/GribIosp.java#L240 https://github.com/Unidata/thredds/blob/master/grib/src/main/java/ucar/nc2/grib/grib2/Grib2Utils.java#L116Is anyone using NetCDF-Java support for GDS template 1 GRIB2 files? Does anyone have any sample files for GDS template 1 and known good NetCDF CF Conventions equivalents?
I suspect the NetCDF-Java implementation of GDS template 1 may be incorrect; if I am right, I intend to fix it as a side-effect of implementing support for GDS 32769. If I am wrong, please stop me now!
Kind regards, -- Ben Caradoc-Davies <ben@xxxxxxxxxxxx> Director Transient Software Limited <http://transient.nz/> New Zealand
netcdf-java archives: