Iain, the GeoTools NetCDF reader does not support multidimensional NetCDF coordinate variables. You can use one-dimensional rlon and rlat like these here (lon/lat are ignored): http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/ch05s06.html
Support was merged onto master and 15.x ten days ago (GEOT-5428 as you noted): https://github.com/geotools/geotools/pull/1205 Now the tricky question (and developer rant): Is this for the northern or southern hemisphere? If northern, stop here, and enjoy the working implementation. The GeoTools NetCDF reader CF rotated pole implementation does not support grid origins in the southern hemisphere because the CF attribute used for the third rotation angle is poorly defined and not even implemented in, for example, NetCDF-Java projections. Without a well-defined third angle, the CF rotated pole is ambiguous. A grid with origin at longitude -106 degrees East and latitude 54 degrees North is a CF rotated pole grid with north pole at longitude 74 degrees East and latitude 36 degrees North. Unfortunately, so is a grid with origin at 74 degrees East and -54 degrees North. How can any client consuming NetCDF files resolve this ambiguity when all it has is the north pole? See the Rotated Pole section: http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/apf.html ****** Map parameters: grid_north_pole_latitude grid_north_pole_longitude north_pole_grid_longitude - This parameter is option (default is 0). ****** That is all the documentation there is. We have to guess the rotation order, but are not even told the rotation sense of the last angle. The name does not make sense to me. I have never seen it used. Reading that documentation, would you know what to include in a southern hemisphere CF rotated pole NetCDF file? Now see, for example, the lack of support for a third angle in the NetCDF-Java RotatedPole class: https://github.com/Unidata/thredds/blob/master/cdm/src/main/java/ucar/unidata/geoloc/projection/RotatedPole.java Thirdly note that the author of this class is also an author of the CF Conventions. This poor definition even causes unresolved confusion on the mailing list for the CF maintainers (the aforementioned author seeking information on even the first two angles): http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2012/055525.html To get southern hemisphere CF rotated pole support in the GeoTools NetCDF reader requires an attribute to define the third angle of rotation. This attribute needs to be defined with both documentation and examples, not to mention widely used by implementations. Note that the GeoTools RotatedPole implementation does not suffer from these problems because it defines the projection in terms of the latitude and longitude of the origin, not the north pole: https://github.com/geotools/geotools/blob/master/modules/library/referencing/src/main/java/org/geotools/referencing/operation/projection/RotatedPole.java This does not help resolve the ambiguity in the CF conventions. I wish CF would drop the north pole representation of rotated pole and support a grid origin representation, that is, the same projection specified with the grid origin latitude/longitude and an implied third rotation angle of zero (or show me one use case where is it not zero). In my opinion, the GeoTools RotatedPole implementation does it right by choosing this representation. Kind regards, Ben. On 19/06/16 22:42, Iain Matcham wrote: > Just found [GEOT-5428] Support NetCDF rotated pole projection... I think > this answers my question. Thanks > > > On 19/06/2016 10:11 p.m., Iain Matcham wrote: >> Hi all >> >> We've got a bunch of netcdf files that we are trying to read with >> geotools following the instructions here: >> http://docs.geotools.org/latest/userguide/library/coverage/multidim.html >> >> Most of the files cause an exception in the NetCDFReader constructor >> (java.lang.IllegalStateException: Unable to create envelope for this >> dataset). We have tracked this down to the netCDF files using a rotated >> grid instead of a cartesian grid. The upshot of this is that the files >> define lat/lon as a secondary lookup (2-d) instead of as a linear (1-d) >> variable. However NetCDFGeoreferenceManager reports these as >> "unsupported axes", with the result being that NetCDFReader finds no >> lat/lon axis and throws the above exception. >> >> I'm assuming that this is by design but wondered if am I missing >> something obvious? >> >> Assuming that I am not, the methodology of creating a rotated grid >> appears to conform to the CF-convention specs and we have examples of >> these files from at least two different software origins - all of which >> implies that they are being created correctly to spec. Bearing this in >> mind is there any interest if we were to extend gt-netcdf to handle >> these files? And/or is there a good reason why we shouldn't try to do >> this that anyone knows of? >> >> Thanks :) >> >> Iain -- Ben Caradoc-Davies <[email protected]> Director Transient Software Limited <http://transient.nz/> New Zealand ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohomanageengine _______________________________________________ GeoTools-GT2-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
