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.
Hi Ben: I see you guys are making good progress on this. The question I never answered for myself is what is the relationship between ucar.unidata.geoloc.projection.RotatedPole which was contributed for CF: /** * Rotated-pole longitude-latitude grid. * * This is probably the same as rotated lat lon, using matrix to do rotation. * Follows CF convention with "north_pole lat/lon", whereas RotatedLatLon uses south pole. * * @author Robert Schmunk * @author jcaron */ and ucar.unidata.geoloc.projection.RotatedLatLon which was contributed for GRIB data: /** * Grib 1 projection 10 and Grib 2 projection 1. * * The Rotated Latitude Longitude projection algorithms that are coded * here were given by Tor Christian Bekkvik <torc@xxxxxx>. The rotated * lat/lon projection coordinates are defined in the grid file that * need to be converted back to unrotated lat/lon projection coordinates * before they can be displayed. The X/Y axis only makes sense in the rotated * projection. * * @author Tor Christian Bekkvik <torc@xxxxxx> * @since Nov 11, 2008 */ Some of your questions answers are probably lurking in the difference between the two. John PS: I presume youve given us some test GRIB files using template 32769 to add to our unit tests? On Thu, Apr 14, 2016 at 4:15 PM, Ben Caradoc-Davies <ben@xxxxxxxxxxxx> wrote: > FYI I have submitted a pull request (and Christian found some test > failures in the Unidata suite): > https://github.com/Unidata/thredds/pull/531 > > Kind regards, > Ben. > > > On 14/03/16 14:23, Ben Caradoc-Davies wrote: > >> 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.shtml >> >> Although 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#L116 >> >> >> Is 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 mailing list > netcdf-java@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/
netcdf-java
archives: