Hi Ben, The plot thickens!
Firstly thanks for that run-down. Glad to see that I am not the only one struggling with the CF-convention Secondly, after reading your email and more reading of the convention (and not doing it late on a Sunday night) I realise what you probably knew from the start that what I have is not rotated-pole at all, but multidimensional NetCDF coordinate variables (ala the link you supplied and also http://cfconventions.org/cf-conventions/cf-conventions.html#_two_dimensional_latitude_longitude_coordinate_variables ) which as your have confirmed aren't supported. So I guess we're back to the first question which is is there interest in supporting these and/or any reason political or otherwise that I shouldn't dive in and try and make gt-netcdf support them? Thanks! Iain On 20/06/2016 12:21 a.m., Ben Caradoc-Davies wrote: > 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 > -- Sent from my ZX80 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ 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
